Pull to refresh

Comments 45

А это всё в виртуалках или контейнерах? Есть ли сравнение скорости работы Bitrix в виртуальной машине и контейнере?
Все в контейнерах. Согласно моим тестам, разницы нет.
Спасибо большое за тестирование — очень интересные результаты!
Преимущество контейнеров перед ВМ скорее в плотности — ожидается больше инстансов битрикса на один физический сервер. Есть ли у Вас возможность померять именно плотность?
К сожалению мы не размещаем клиентов очень плотно друг к другу. Это главная суть нашей работы сейчас, давать максимально комфортные условия для наших клиентов. Но на тестовом окружении будем пробовать. Буду стараться написать об этом в одной из следующих статей.
Похоже на то, что вы в производительность файловой системы уперлись (Толи на уровне драйвера, толи гдето в конфигах самой системы/ядра).
У меня похожее было — По умолчанию Proxmox пользует LVM, на котором производительность дисков падает в 2-3 раза (Лично у меня). Когда переделал всё на Raw (файлом на ext4 Разделе) — Падение составило около 5% для KVM и около 2% для lxc
* Тестил на SSD Intel 320 series (180GB)
Мы использовали ZFS, он не очень быстр увы. Но его плюсы в другом.
Кстати ZFS рекомендовали сами разработчики Proxmox как самый быстрый вариант работы с диском.
Proxmox 4.1
SSD в RAID10

Виртуалка:
CPU 2 ядра
RAM 2GB
Centos 7
Nginx как фронтенд и для отдачи статики
Apache 2.2.15
PHP 7
Opcache
MariaDB
BitrixEnv

image

впервые видел 200 попугаев

Да, отличный результат показывает php70. А не поделитесь конфигурацией железа и и служб? очень интересно посмотреть на ваш вариант
Сервер (аренда):
CPU: Intel® Xeon® CPU E31275 3.40GHz (Cores 8)
Memory: 32GB ECC
4 х 240GB SSD (Intel 520 Series) в Software RAID10
Канал Ethernet в 1Gbps
рабочая директория в ext3

настраивал год назад, аптайм 100%.

Виртуалка:
KVM
внутри стандартное окружение BitrixEnv, без тюнинга с моей стороны (кроме БД, немного правил кэш, но это не суть)

Зачем вам такие большие журналы? В рамках сториджа можно считать что чянки у вас маленькие и им столько не требуется.

У нас осталось по 2 диска SSD на каждой ноде, нужно куда то использовать. Боевой кластер будет увеличиваться, возможно лишним не будет. Так или иначе, других идей для применения этих дисков у меня нет

Ок. Проверяли high availability на базе сториджа? Это когда ВМ с одной ноды переезжает на другую ноду при падении первой.

Да я понял о чем вы. К сожалению пока что нет. Если често — опасаюсь пока что :)

Мы тоже тестировали Proxmox 4 + LXC + ZFS / Loop / Directory (ext4).
Cравнивали с Proxmox 3.4 + OpenVZ +SimFS (ext4).
Pезультаты не впечатлили.


В версии 4.1 было отвратительное проседание производительности до 20% на сопоставимой конфигурации — ФС в директории.
Причем случайное, т.е. разброс по тестам был 10%.
Например, пустой контейнер с MySQL сервером на тестах sysbench проседал на 20-25% по сравнению с базовой системой.
ZFS была адовым тормозом — файловые операции просаживались в 3-4 раза.
С сжатием и без. Под arc выделяли 4Гб памяти.


В версии 4.4 починили FileIO — уменьшились задержки, скорость FileIO почти сравнялась с базовой системой.
Тут ZFS уже не тестировали.
И MySQL всё так же проседает. Примерно на 15-17%.


Пробовали на железе: "стандартный" сервер на hezner — EX-40-SSD.
И сравнивали с Proxmox 3.4 на соседнем EX-40. Без SSD! Что еще больше разачаровало.


Так что пришлось остаться на Proxmox 3.4. Он хотя бы предсказуемо себя ведет.
От Virtuozzo пока отталкивает отсутствие web-панели.
Посмотрим что будет, когда поддержка Wheezy закончится.

WEB панель есть.
https://virtuozzo.com/products/devops/
$150 в месяц это за каждый сервер кластера?
Please contact us for details and the pricing options for larger deployments.

Вот это раздражает.
И 150кц в месяц крутовато.


И как получить тестовую лицензию?
<ворчун mode on>Там пустое белое поле вылазит при клике на "Get blah-blah", без надписей.
Что вводить то? Ну кто так делает!<ворчун mode off>

Веб-интерфейс называется Virtuozzo Automator и устанавливается на любой CentOS-based контейнер или виртуальную машину. Описание установки. Это новая сильно обновленная версия (новый дизайн, новая консоль и тд) того, что называлось Parallels Virtual Automation.
Virtuozzo DevOps — немного другое. Это продукт для создания PaaS или автоматизации DevOps на базе Jelastic.
К сожалению, работой Automator не доволен. Масса проблем, делают работу с ней практически не возможными.
Да, должен признать, что там пока что довольно много багов. А есть какие-то замечания/предложения по юзабилити и юзкейсам? Может быть какие-то фичи/настройки непонятны или требует доработки?
На данный момент 2 блокирующих для меня проблемы:
При миграции виртуальных машин, машина остается в списке слева на исходной ноде в выключенном состоянии, а на новой не появляется. http://screencloud.net/v/lA06

При любом редактировании сетевых настроек виртуальной машины, они не сохраняются ссылаясь на ошибку. При этом из консоли все работает прекрасно. http://screencloud.net/v/zK6E

Третий плохой баг, живая миграция так и не заработала, так что мы делаем выключение, миграцию, включение. Это особенно никого не аффектит но тем ни менее…

1) Да, есть такой баг. Обязательно починим в апдейте 1 в середине февраля.
2) Не встречали — можете описать сценарий подробнее?
3) Допускаю, что было что-то такое в версиях от начала декабря — сейчас либо починили, либо само исправилось)
Вот он пожалуй один из самых критичных.
Кстати вопрос, почему не внедрите lx4 сжатие для данных Cloud Storage?
С обывательской точки зрения это должно так же ускорить репликацию и запись данных на чанки, так как их будет просто меньше? А потребители смогут экономить свое пространство массива
Спрошу у storage команды, так как сам мало понимаю, с чем едят lz4;)
Напишите пожалуйста что скажут. Очень интересно
Мне показалось, что pva переделали в Virtuozzo DevOps. :/ Сам себя обманул. Спасибо.
У меня аналогичные эмоции :)

У меня эмоции скорее такие:


  • смогут запилить LXC до уровня OpenVZ или нет?
  • переходить всё равно придется, но какой ценой?

Поэтому к печали добавляется немного обреченности ¯\_(ツ)_/¯

Кто знает:) мы свой выбор сделали в пользу VZ
> запилить LXC до уровня OpenVZ

То есть нужно испортить LXC работу с памятью, сделать падучим и так далее? А может не надо?
А вы когда последний раз VZ использовали? Судя по комментарию в то время, когда там были UBC или LSM.
Старался вспомнить точно, что бы не соврать. Выходит год 2009, после этого я закопал те OpenVZшные тазы, что мне достались и не хочу выкапывать этот ужас летящий на крыльях ночи, ибо есть чудесный LXC который просто работает.
Понятие «работает» у всех разное. В случае с OpenVZ доступ к контейнеру можно отдать кому угодно. В случае с LXC этого сделать нельзя, потому что пользователь в контейнере довольно легко может положить всю ноду. Если вам нужен chroot для запуска отдельного окружения, то LXC легко справится с этой задачей. Если вы хотите отдавать доступ к контейнеру в третьи руки, то LXC вам не подходит.

В 2009 году в LXC работы с памятью просто не было, там и сегодня не все так хорошо. В OpenVZ в то время использовались UBC, которые действительно вызывали много вопросов у пользователей. Сегодня схема работы с памятью совсем другая и она сильно приближена к обычно системе. У контейнера есть два лимита на память и на своп.
Обратите внимание, что я не говорю про LXC в те годы, тогда его просто не было.
Но OpenVZ тогда заставил меня закопать ваши контейнеры на ближайшем огороде.

Я в профиле видел, что вы — разработчик OpenVZ, я готов вам поверить и даже потестировать для себя, как замену LXC ваши контейнеры, если мне будет возможность использовать дистрибутивное ядро Ubuntu 16.04 с патчами приходящими через canonical-liveptach.

Вот на данный момент я использую LXC на личном проекте, где у меня по тазам разведены разные веб-сервисы и отдельно общий мускуль. Я готов и хочу посмотреть можете ли вы мне их заменить. Я получу обновления ядра без ребутов? Я получу изоляцию на том же уровне?
Через livepatch можно делать относительно простые изменения, которые не затрагивают изменения структур данных. Да и ядра для убунты нет.
Для вашего примера, LXC более чем достаточен. OpenVZ используется, когда действительно нужна изоляция контейнеров друг от друга, когда контейнеры отдаются в третьи руки, а в этом случае базовый дистрибутив играет уже второстепенную роль.
Спасибо, понял.
На самом деле, если вы говорите, что беда с памятью давно изжита, то посмотрю для общего представления, когда будет тестовый полигон. При моей любви к LXC в качестве тазов и к виртуалкам на KVM надо представлять что же ныне дает OpenVZ. Спасибо за ваши пояснения.

В продолжение печалей:


На форумах пишут, что есть проблемы с LXC из-за того, что значения в namespace-ах обновляются рекурсивно по каждому чиху, с "нижнего" уровня (контейнер) до базового.
Все ждут, когда LXC2 в ядре доделают. Обещают избавиться от этого безобразия.


Если в 4.1 вроде были проблемы с получением лимитированных значений памяти, процессора (htop видел всю память), то в 4.4 это точно починили.


И ZFS в Linux прикручен с костылями прослойками от Solaris.
Свой кеш, свое управление памятью. Соотв. эта память отрезается от доступной процессам.
Сделано интересно, но на рабочем сервере пока запускать страшно.

Я так же пробовал замерить скорость на KVM виртуальной машине поверх Proxmox и LXC. Результат такой же как и на LXC. Те проблема глобальная для всего продукта
А в чем именно проблема удалось понять? Как воспроизвести? У нас очень много серверов в хецнере и мы тоже используем проксмокс. После апгрейда разницу не заметили (но и не исказли особо, главное что наши приложения с тойже скоростью что и раньше работают).

Если приложения не особо много пишут на диск, особенно без случайного доступа — то проседаний сильных не должно быть.

Кое что мы описали в статье. Что касается скорости, то основные проблемы с дисковой подсистемой, она стара работать гораздо медленнее
Уважаемый автор, не покажете cat /proc/cpuinfo на хост-машине proxmox? Производительность в попугаях у битрикс очень сильно зависит от того, в каком режиме работает CPU. Для центос, к примеру, необходимо изменить активный профиль в /etc/tuned/active_profile
И может быть я открою секрет, но самым важным параметром в количестве попугаев для тестов битрикс является «Среднее время отклика», а он, в свою очередь, очень сильно зависит от частоты, на которой в данный момент работает CPU.
Не могло оказаться так, что у proxmox cpu работает в режиме «powersave» с пониженной частотой, а Virtuozzo дефолтно использует режим работы «performance»?
Внутри виртуальной машины следущая картина:

processor: 3
vendor_id: GenuineIntel
cpu family: 6
model: 44
model name: Intel® Xeon® CPU E5620 @ 2.40GHz
stepping: 2
microcode: 0x15
cpu MHz: 2401.000
cache size: 12288 KB
physical id: 0
siblings: 8
core id: 10
cpu cores: 4
apicid: 20
initial apicid: 20
fpu: yes
fpu_exception: yes
cpuid level: 11
wp: yes
flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl
vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt lahf_lm ida arat epb dtherm tpr_shadow vnmi flexpriority ept vpid
bogomips: 4799.89
clflush size: 64
cache_alignment: 64
address sizes: 40 bits physical, 48 bits virtual
power management:
Да, тогда возможно, что заметно влияет и файловая система. Так как, в свое время при тестах, даже изменение попугаев mysql от сотен до тысяч незначительно влияли на итоговую оценку.
Only those users with full accounts are able to leave comments. Log in, please.