Comments 42
Отличная статья :)
Очень страшно от хостера видеть такой комментарий!:)
Все предложенные способы конечно могут увеличить производительность, но за это приходится чем-то платить.
Если мы отключаем O_DIRECT / fsync в контейнере, то клиент имеет шанс потерять данные.
Оверкоммиты по памяти и процессору конечно уже не столь деструктивны, но и это может негативно сказаться совместном исполнении нескольких контейнеров внутри одной машины.
Все предложенные способы конечно могут увеличить производительность, но за это приходится чем-то платить.
Если мы отключаем O_DIRECT / fsync в контейнере, то клиент имеет шанс потерять данные.
Оверкоммиты по памяти и процессору конечно уже не столь деструктивны, но и это может негативно сказаться совместном исполнении нескольких контейнеров внутри одной машины.
Само по себе отключение O_DIRECT *не может* привести к потере данных.
Гарантированно на диск данные попадают только после успешно выполненных fsync()/fdatasync().
И они нужны вне зависимости от того, как писались данные (через кэш или напрямую).
Гарантированно на диск данные попадают только после успешно выполненных fsync()/fdatasync().
И они нужны вне зависимости от того, как писались данные (через кэш или напрямую).
Не спорю, именно поэтому написал их вместе:)
Кстати если мы отключаем O_DIRECT, а внутри у нас какая-то умная база данных, которая делает свой кеш данных в памяти вместо page cache, то на деле у данные могут хранится в двух копиях. В кеше программы и page cache. При этом, вытесняя что-то полезное из page cache можно так же навредить и уменьшить производительность других контейнеров и упереться в диски на случайное чтение.
Аффинити по NUMA-нодам правда даёт снижение latency к памяти, но возможны ситуации когда процессорного времени одного сокета начинает не хватать, и тогда контейнер, который съедает всё процессорное время на numa-ноде, будет очень сильно мешать другим контейнерам на той же numa-ноде.
Польза будет в том случае, если мы упираемся в latency RAM, но не в процессорное время.
Кстати если мы отключаем O_DIRECT, а внутри у нас какая-то умная база данных, которая делает свой кеш данных в памяти вместо page cache, то на деле у данные могут хранится в двух копиях. В кеше программы и page cache. При этом, вытесняя что-то полезное из page cache можно так же навредить и уменьшить производительность других контейнеров и упереться в диски на случайное чтение.
Аффинити по NUMA-нодам правда даёт снижение latency к памяти, но возможны ситуации когда процессорного времени одного сокета начинает не хватать, и тогда контейнер, который съедает всё процессорное время на numa-ноде, будет очень сильно мешать другим контейнерам на той же numa-ноде.
Польза будет в том случае, если мы упираемся в latency RAM, но не в процессорное время.
Конечно, в случае O_DIRECT нет одного универсального, подходящего всем решения. Поэтому и дана ручка, позволяющая настраивать его поведение (в том числе индивидуально, для каждого контейнера). Для того и статья, чтобы про ручку знали :)
Согласен с тем, что аффинити по NUMA-нодам в случае оверкоммита по CPU, может сделать только хуже, про это в статье тоже есть предупреждение ;) Это, скорее информация для тех, кто оверкоммитить не собирается, но кому нужно выжать максимальную производительность из машины, при этом изолируя компоненты системы в разных контейнерах.
Согласен с тем, что аффинити по NUMA-нодам в случае оверкоммита по CPU, может сделать только хуже, про это в статье тоже есть предупреждение ;) Это, скорее информация для тех, кто оверкоммитить не собирается, но кому нужно выжать максимальную производительность из машины, при этом изолируя компоненты системы в разных контейнерах.
С page cache у OpenVZ вообще все плохо, фича по его изоялции есть (ubc.pagecache_isolation = 0), но по дефалту не включена нигде — даже в коммерческом продукте ;)
Уже включена =)
Не лучшая идея, это серьезно увеличивает потребление памяти и вызывает проблемы в случае, когда памяти достаточно и она еще могла бы быть использована под кэш и ускорение впски. А в этом случае кэша не будет и будет долбаться дисковая система.
Это плохое решение данной проблемы. Хорошее — аналог ZFS/L2ARC.
Это плохое решение данной проблемы. Хорошее — аналог ZFS/L2ARC.
Да, я читал ваши комментарии на других ресурсах. Но как я понял вы сами хотели эту «фичу» по дефолту изменить. Что же изменилось за год?
Никаких подвижек, мы её не используем по причине означенных проблем :( Саппорт || также не может сказать однозначно о оверхеде и серьезных доводах за и против данного флага.
Народ требовал — сделали, народу не нравится — в следующем релизе удалят. Все ОК =)
Народ требовал изоляцию с умом, а данная реализация мягко говоря не айс =)
Кстати, нашел тут тикет товарища: bugzilla.openvz.org/show_bug.cgi?id=2823, попросил дать комментарии в нем. У нас вроде такой проблемы не было, но надо проверить внимательно… Займемся.
Это зависит от диска, точнее от его кеша.
Еще как страшно.
Если уж хостер соглашается с необходимостью ребутить машины ради минорных улучшений производительности — нафиг он такой нужен.
(обычно же как все происходит: падение системы, падение системы после правок на скорую руку, запланированный ребут; спонтанный незапланированный ребут на тему «все равно все падало, давайте это зафиксим» — ересь полная)
Если уж хостер соглашается с необходимостью ребутить машины ради минорных улучшений производительности — нафиг он такой нужен.
(обычно же как все происходит: падение системы, падение системы после правок на скорую руку, запланированный ребут; спонтанный незапланированный ребут на тему «все равно все падало, давайте это зафиксим» — ересь полная)
Атата, а про --numa не указали, кто оплачивал доработку и открытие фичи! :)
Еще стоило бы добавить, что для грамотного балансинга нужно написать свой демон, который будет переносить контейнеры с одной NUMA ноды на другую. В PCS он есть — numabalanced.
По поводу O_DIRECT и FSYNC — инфа ценная, но крайне опасная, от обоих фич на порядки больше зла, чем пользы. Сейчас куча народу пойдет и врубит себе это и погубит себе данные, а-то и клиентам :/
Было бы круто почитать подобное по ploop, ибо по нему инфы почти нету, а возможностей «отстрелить себе ногу веревкой» там решительно больше.
Еще стоило бы добавить, что для грамотного балансинга нужно написать свой демон, который будет переносить контейнеры с одной NUMA ноды на другую. В PCS он есть — numabalanced.
По поводу O_DIRECT и FSYNC — инфа ценная, но крайне опасная, от обоих фич на порядки больше зла, чем пользы. Сейчас куча народу пойдет и врубит себе это и погубит себе данные, а-то и клиентам :/
Было бы круто почитать подобное по ploop, ибо по нему инфы почти нету, а возможностей «отстрелить себе ногу веревкой» там решительно больше.
Кстати, Вы бы удалили vzcpucheck что ли, а-то он больше людей запутывает, чем пользы приносит :)
А что с ним не так?
Нууу, он веса складывает как абсолютные величины github.com/kolyshkin/vzctl/blob/c90b707f96125b8bb1f0b8b482414be653a1c710/bin/vzcpucheck.in :)
Ах, вот еще «при этом нужно понимать, что если какой-либо процесс из, например, контейнера 100 уже выделил память на NUMA-ноде 1, то каждый доступ к этой памяти будет медленнее, чем доступ к локальной памяти. Поэтому рекомендуется перезапустить контейнеры после выполнения этих команд.»
Неправда Ваша — достаточно поменять привязку машины к другой numa ноде и сделать следующий финт ушами:
И после этого OpenVZ очень быстро перетащит память на требуемую NUMA ноду и локализует всю свою память на ней впредь :)
Неправда Ваша — достаточно поменять привязку машины к другой numa ноде и сделать следующий финт ушами:
echo 0,1 > /proc/vz/fairsched/58268/cpuset.mem_migration_pending
И после этого OpenVZ очень быстро перетащит память на требуемую NUMA ноду и локализует всю свою память на ней впредь :)
Отключение O_DIRECT для контейнера с СУБД — это прямой путь к порченной базе данных. Если БД или файловая система хотят записать данные именно так и именно сейчас, то лучше это позволять — иначе нарушаются все обещания/ожидания и консистентность никто больше обещать не может. Более того, повреждения могут быть молчаливыми (то есть «исчезла транзакция с начислением зарплаты»).
Такое утверждение неверно. Сам по себе O_DIRECT никаких гарантий, что после успешного завершения системного вызова write() данные попадут на энергонезависимый носитель, не дает. Такие гарантии могут дать только успешно завершенные системные вызовы fsync()/fdatasync(). До этого момента данных могут быть, например, в кэше самого диска или в кэше raid-контроллера.
А может быть вы напишите чуть более развернуто про лимиты и их мониторинг?
Там же есть такие увлекательные vmguarpages, shmpages или lockedpages. Или например про интерпритацию вывода vzmemcheck. А уж как работает vzsplit для меня пока загадка — пытался получить то него конфиг, так он уверял, что на моем железе можно поднять 1000 нелимитированных машинок :)
Там же есть такие увлекательные vmguarpages, shmpages или lockedpages. Или например про интерпритацию вывода vzmemcheck. А уж как работает vzsplit для меня пока загадка — пытался получить то него конфиг, так он уверял, что на моем железе можно поднять 1000 нелимитированных машинок :)
А что в shmpages интересного? В нем совершенно никакого смысла сейчас нету, все аккаунтится посредством physpages и shmpages включается в него.
Если требуется управление лимитами памяти (выделяемой, гарантируемой, общей), то вместо тюнинга privvmpages сейчас используется параметр vm_overcommit и задаваемый объем vswap и далее указывается просто --ram и --swap, а параметры physpages, oomguarpages и vmguarpages генерирует сам vzctl.
Если требуется управление лимитами памяти (выделяемой, гарантируемой, общей), то вместо тюнинга privvmpages сейчас используется параметр vm_overcommit и задаваемый объем vswap и далее указывается просто --ram и --swap, а параметры physpages, oomguarpages и vmguarpages генерирует сам vzctl.
А слона и не заметил… Как задать cpulimit для OpenVZ в мегагерцах?
«желаемые MHz» * 100 / «MHz одного CPU»
(если у хоста, например, 8 CPU, то максимально допустимый процент будет составлять 800%)
(если у хоста, например, 8 CPU, то максимально допустимый процент будет составлять 800%)
Этот способ даже задокументирован, с ним проблем нету. OpenVZ ядро позволяет забить именно мегагерцы, явно. Про что и упомянуто «также иногда может быть полезно лимитировать CPU в процентах (или же в мегагерцах) с помощью опции --cpulimit». Но вот возможности этой в vzctl я не видел либо она не документирована.
Да, извиняюсь, мой косяк. vzctl из состава OpenVZ напрямую в мегагерцах ставить не дает.
vzctl из состава PCS так умеет, нужно добавит суффикс 'm' после значения, например:
vzctl set 111 --cpulimit 1500m
vzctl из состава PCS так умеет, нужно добавит суффикс 'm' после значения, например:
vzctl set 111 --cpulimit 1500m
А в OpenVZ'шный vzctl планируется добавить такую возможность, т.к. на данный момент я вижу только один вариант:
самописный скрипт-костыль обсчитывает правильный Rate на основе переданных в него MHz'ах и загоняет результат в /proc/vz/fairsched/$CID/cpu.rate
самописный скрипт-костыль обсчитывает правильный Rate на основе переданных в него MHz'ах и загоняет результат в /proc/vz/fairsched/$CID/cpu.rate
Голосую за добавление такой фичи в OpenVZ! Тем более упомянутой в пресс-релизе самого Parallels :) Сообщество будет бесконечно Вам благодарно.
Тогде еще вопрос, цитирую man vzctl от PCS:
Как задавать нагрузку в мегагерцах? Например, для кристалла в 3.5Ghz 3500 означает 100% в случае использования «процентного» cpulimit?
--cpulimit num
Sets the CPU limit, in percent or megahertz (MHz), the Container is not allowed to exceed. By default, the limit is set in percent. To specify the limit in MHz, specify "m" after the value. Note: If the computer has 2 CPUs, the total CPU time equals 200%.
Как задавать нагрузку в мегагерцах? Например, для кристалла в 3.5Ghz 3500 означает 100% в случае использования «процентного» cpulimit?
Да. Если задать, например, 7000, то это будет 200% (т.е. два полных ядра). Вообще он будет печатать пересчитанное в проценты значение, и предупреждение, если заданное значение превышает суммарную мощность машины:
[root@host ~]# vzctl set 50 --cpulimit 3100m
CPU limit: 100.0%
[root@host ~]# vzctl set 50 --cpulimit 6200m
CPU limit: 199.9%
[root@host ~]# vzctl set 50 --cpulimit 12500m
Warning: the specified CPU frequency 12500 is higher the total 12404
CPU limit: 403.1%
[root@host ~]# vzctl set 50 --cpulimit 3100m
CPU limit: 100.0%
[root@host ~]# vzctl set 50 --cpulimit 6200m
CPU limit: 199.9%
[root@host ~]# vzctl set 50 --cpulimit 12500m
Warning: the specified CPU frequency 12500 is higher the total 12404
CPU limit: 403.1%
После долгого обсуждения сошлись на очень хитром эффекте, а именно, если для Innodb выставить тип коммита O_DIRECT вместо стандартного sync/fdatasync, то на OpenVZ это приведет к очень крутому ускорению работы базы данных.
Но как раз в данной статьей красиво объяснено то, что OpenVZ игнорирует O_DIRECT и тем самым указывая такой флаг для MySQL мы отключаем вообще как таковую работу с транзакциями. То есть что есть транзакция, что нету — данные будут записаны по flush таймауту ext4 (5 секунд), а не тогда, когда этого хочет MySQL.
Возможно, в случае очень высокой нагрузки это может привести к потере данных, но в общем случае конфигурация дисковой системы HWN нод подразумевает высокий уровень резервирования (BBU, кэши, UPS, дизеля) и вероятность подобного развития событий (с повреждением данных) очень низкая.
Но как раз в данной статьей красиво объяснено то, что OpenVZ игнорирует O_DIRECT и тем самым указывая такой флаг для MySQL мы отключаем вообще как таковую работу с транзакциями. То есть что есть транзакция, что нету — данные будут записаны по flush таймауту ext4 (5 секунд), а не тогда, когда этого хочет MySQL.
Возможно, в случае очень высокой нагрузки это может привести к потере данных, но в общем случае конфигурация дисковой системы HWN нод подразумевает высокий уровень резервирования (BBU, кэши, UPS, дизеля) и вероятность подобного развития событий (с повреждением данных) очень низкая.
Sign up to leave a comment.
Как ускорить контейнер: тюнингуем OpenVZ