Компания
272,03
рейтинг
14 октября 2014 в 11:47

Разное → Как ускорить контейнер: тюнингуем OpenVZ

image
OpenVZ — это OpenSource-реализация технологии контейнерной виртуализации для ядра Linux, которая позволяет запускать на одной системе с ядром OpenVZ множество виртуальных окружений с различными дистрибутивами Linux внутри. За счет своих особенностей (контейнерная виртуализация идет на уровне ядра, а не железа) по ряду показателей производительности – плотности, эластичности, требованиям к размеру оперативной памяти, скорости отклика и т.д. – она работает лучше, чем другие технологии виртуализации. Например, тут можно посмотреть сравнения производительности OpenVZ с традиционными системами гипервизорной виртуализации. Но, помимо этого, в Linux и OpenVZ есть и масса вариантов тонкой настройки.
В данной статье мы рассмотрим нетривиальные варианты настроек контейнеров ядра OpenVZ, которые позволяют улучшить производительность всей системы OpenVZ.

Общие настройки


imageОсновные настройки, влияющие на производительность контейнеров — это лимиты на потребление памяти и процессора. В большинстве случаев увеличение количества выделенной памяти и процессоров помогает добиться большей производительности контейнеров для пользовательских приложений, таких как, например, ваш веб-сервер или сервер базы данных.

Для установки глобального лимита на физическую память, выделенную контейнеру, достаточно указать опцию --ram, например:

# vzctl set 100 --ram 4G --save


Очень часто заниженные лимиты в контейнере приводят к отказу в выделении памяти в том или ином месте в ядре или приложении, поэтому при использовании контейнеров крайне полезно мониторить содержимое файла /proc/user_beancounters. Ненулевые значения в колонке failcnt означают, что какие-то из лимитов слишком малы и нужно либо уменьшить working set в контейнере (например, уменьшить количество нитей apache или postgresql сервера), либо же увеличить лимит на память с помощью опции --ram. Для удобного мониторинга файла /proc/user_beancounters можно воспользоваться утилитой vzubc, которая позволяет, например, смотреть только счетчики, близкие к failcnt, или обновлять показания с какой-то периодичностью (top-like mode). Подробнее про утилиту vzubc можно почитать здесь.

Помимо установки лимита на физическую память, рекомендуется установить лимит на размер swap для контейнера. Для настройки размера swap контейнера воспользуемся опцией --swap команды vzctl:

# vzctl set 100 --ram 4G --swap 8G --save


Сумма значений --ram и --swap — это максимальный объем памяти, которым может воспользоваться контейнер. После достижения лимита --ram контейнера, страницы памяти, принадлежащие процессам контейнера, начнут вытесняться в так называемый “виртуальный swap (VSwap)”. При этом не будет происходить реального дискового I/O, а производительность контейнера будет искусственно занижаться для создания эффекта реального swapping.

При конфигурации контейнеров рекомендуется, чтобы сумма ram+swap по всем контейнерам не превышала сумму ram+swap на host node. Для проверки настроек можно воспользоваться утилитой vzoversell.

Для управления максимальным количеством доступных процессоров для контейнера необходимо использовать опцию --cpus, например:

# vzctl set 100 --cpus 4 --save


При создании нового контейнера количество процессоров для этого контейнера не лимитируется, и он будет использовать все возможные CPU-ресурсы сервера. Поэтому для систем с несколькими контейнерами имеет смысл устанавливать лимит на количество процессоров каждого контейнера в соответствии с возлагаемыми на них задачами. Также иногда может быть полезно лимитировать CPU в процентах (или же в мегагерцах) с помощью опции --cpulimit, а также управлять весами, то есть приоритетами контейнеров, с помощью опции --cpuunits.

Оверкоммит по памяти


Ядро OpenVZ позволяет выделить всем контейнерам суммарно больший объём памяти чем полный размер физической памяти, доступный на хосте. Данная ситуация называется memory overcommit и в этом случае ядро будет управлять памятью динамически, балансируя её между контейнерами, ведь разрешённая к использованию контейнерами память не обязательно будет ими востребована и ядро может управлять ей по своему усмотрению. При оверкоммите по памяти ядро будет эффективно управлять различными кэшами (page cache, dentry cache) и стараться уменьшать их в контейнерах пропорционально установленному лимиту по памяти. Например, если вы хотите изолировать друг от друга сервисы какого-нибудь высоконагруженного веб сайта состоящего из фронт-энда, бэк-энда и базы данных ради улучшения безопасности, то вы можете поместить их в отдельные контейнеры, но при этом каждому выделить максимально доступное на хосте количество памяти, например:

# vzctl set 100 --ram 128G --save
# vzctl set 101 --ram 128G --save
# vzctl set 102 --ram 128G --save


В этом случае с точки зрения управления памяти ситуация не будет отличаться ничем от той, когда ваши сервисы работали на одном хосте и балансировка памяти будет по-прежнему максимально эффективной. Вам не нужно думать о том, в каком из контейнеров нужно поставить больше памяти – во фронт-энд контейнере для большего размера page cache для статических данных веб сайта, или же в контейнере с базой данных – для большего размера кэша самой базы данных. Ядро будет балансировать всё автоматически.

Хотя оверкоммит позволяет ядру максимально эффективно балансировать память между контейнерами, он также обладает определёнными неприятными свойствами. Когда общее количество выделенной анонимной памяти, то есть суммарный working set для всех процессов всех контейнеров приблизится к общему размер памяти в хосте, то при попытке выделения новой памяти каким-нибудь процессом или ядром может возникнуть глобальное исключение “нехватка памяти” и OOM-killer убьёт один из процессов в системе. Чтобы проверить, случались ли такие исключения на хосте или в контейнере можно воспользоваться командой:

# dmesg | grep oom
[3715841.990200] 645043 (postmaster) invoked oom-killer in ub 600 generation 0 gfp 0x2005a
[3715842.557102] oom-killer in ub 600 generation 0 ends: task died


При этом важно отметить, что OOM-killer убьёт процесс не обязательно в том же контейнере, в котором как раз и пытались выделить память. Для управления поведением OOM-killer’a служит команда:

# vzctl set 100 --oomguarpages 2G --save


позволяющая установить лимит, гарантирующий неприкосновенность процессов контейнера в рамках заданного лимита. Поэтому для контейнеров, в которых запущенны жизненно важные сервисы, можно установить этот лимит равный лимиту памяти.

Оверкоммит по процессорам


Точно также как и в случае с памятью оверкоммит по процессорам позволяет выделять контейнерам суммарное количество процессоров превышающее общее количество логических процессоров на хосте. И также как и в случае с памятью оверкоммит по процессорам позволяет достичь максимально эффективной общей производительности системы. Например, в случае с тем же веб-сервером, “разложенным” на три контейнера для фронт-энда, бэк-энда и базы данных можно также выставить неограниченное количество CPU для каждого контейнера и достичь максимальной суммарной производительности системы. Опять же ядро само определит каким процессам из каких контейнеров выделять процессорное время.

В отличие от памяти процессор – «эластичный» ресурс, то есть нехватка CPU не приводит к каким-либо исключениям или ошибкам в системе, кроме замедления работы каких-то активных процессов. Поэтому использование оверкоммита по процессорам является более безопасным трюком для разгона системы, чем оверкоммит по памяти. Единственным негативным эффектом оверкоммита по процессорам является возможное нарушение принципа честности выделения процессорного времени для контейнеров, что может быть плохо, например, для клиентов VPS хостинга, которые могут недополучать оплаченное процессорное время. Для сохранения честного распределения процессорного времени необходимо выставить “веса” контейнерам, в соответствии с оплаченым процессорным временем, используя опцию --cpuunits команды vzctl (подробнее можно прочитать здесь).

Оптимизация работы контейнеров на NUMA-хостах


В случае запуска контейнеров на хосте с NUMA (Non-Uniform Memory Access) возможна ситуация, когда процессы контейнера исполняются на одной NUMA-ноде, а часть (или вся память) этих процессов была выделена на другой NUMA-ноде. В этом случае каждое обращение к памяти будет медленнее, чем обращение к памяти локальной NUMA-ноды и коэффициент замедления будет зависеть от дистанции между нодами. Ядро Linux будет стараться не допускать такой ситуации, но для гарантированного исполнения контейнера на локальной NUMA-ноде можно выставить для каждого контейнера CPU mask, которая ограничит набор процессоров, на которых разрешено выполнение процессов контейнера.

Посмотреть доступные на хосте NUMA-ноды можно с помощью команды numactl:

# numactl -H
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3
node 0 size: 16351 MB
node 0 free: 1444 MB
node 1 cpus: 4 5 6 7
node 1 size: 16384 MB
node 1 free: 10602 MB
node distances:
node   0   1
  0:  10  21
  1:  21  10


В данном примере на хосте присутствуют две NUMA-ноды, в каждой из которых 4 процессорных ядра и 16Гб памяти.

Для установки ограничения на набор процессоров для контейнера воспользуемся командой vzctl:

# vzctl set 100 --cpumask 0-3 --save
# vzctl set 101 --cpumask 4-7 --save


В данном примере мы разрешили контейнеру 100 исполняться только на процессорах с 0 по 3, а контейнеру 101 — с 4 по 7. При этом нужно понимать, что если какой-либо процесс из, например, контейнера 100 уже выделил память на NUMA-ноде 1, то каждый доступ к этой памяти будет медленнее, чем доступ к локальной памяти. Поэтому рекомендуется перезапустить контейнеры после выполнения этих команд.

Стоит отметить, что в новом релизе vzctl 4.8, появилась опция --nodemask, которая позволяет прикреплять контейнер к конкретной NUMA-ноде не указывая список процессоров данной ноды, а оперируя только номером NUMA-ноды.

При этом следует иметь ввиду, что данный подход ограничит возможности планировщика процессов по балансировке нагрузки между процессорами системы, что в случае большого overcommit по процессорам может привести к замедлению работы.

Управление поведением fsync в контейнерах


Как известно, для гарантированной записи данных на диск приложению необходимо выполнить системный вызов fsync() на каждый измененный файл. Данный системный вызов запишет данные файла из write-back cache на диск и инициирует сброс данных из кэша диска на постоянный энергонезависимый носитель. При этом, даже если приложение записывает данные на диск, минуя write-back cache (так называемое Direct I/O), данный системный вызов все равно необходим для гарантированного сброса данных из кэша самого диска.

Частое выполнение системного вызова fsync() может существенно замедлить работу дисковой подсистемы. Среднестатистический жесткий диск способен выполнить 30-50 syncs/sec.

При этом зачастую известно, что для всех или части контейнеров такие строгие гарантии записи данных не нужны, и потеря части данных в случае аппаратного сбоя не является критической. Для таких случаев ядро OpenVZ предоставляет возможность игнорировать fsync()/fdatasync()/sync() запросы для всех или части контейнеров. Настроить поведение ядра можно, используя файл /proc/sys/fs/fsync-enable. Возможные значения данного файла в случае настройки на host node (глобальные настройки):

  0 (FSYNC_NEVER)       fsync()/fdatasync()/sync() запросы от контейнеров игнорируются
  1 (FSYNC_ALWAYS)      fsync()/fdatasync()/sync() запросы от контейнеров работают как обычно, 
                        данные всех inodes на всех файловых системах хостовой машины будут записаны
  2 (FSYNC_FILTERED)    fsync()/fdatasync() запросы от контейнеров работают как обычно,
                        sync() запросы от контейнеров затрагивают только файлы контейнера (значение по умолчанию)


Возможные значения данного файла в случае настройки внутри конкретного контейнера:

  0       fsync()/fdatasync()/sync() запросы от данного контейнера игнорируются 
  2       использовать глобальные настройки, установленные на host node (значение по умолчанию)


Несмотря на то, что данные настройки могут существенно ускорить работу дисковой подсистемы сервера, нужно использовать их аккуратно и избирательно, т.к. отключение fsync() может привести к потере данных в случае аппаратного сбоя.

Управление поведением Direct I/O в контейнерах


По умолчанию запись во все файлы, открытые без флага O_DIRECT, осуществляется через write-back cache. Это не только уменьшает latency (время ожидания) записи данных на диск для приложения (системный вызов write() завершится, как только данные будут скопированы в write-back cache, не дожидаясь реальной записи на диск), но и позволяет планировщику I/O ядра эффективнее распределять ресурсы диска между процессами, группируя I/O запросы от приложений.

При этом некоторые категории приложений, например, базы данных, сами эффективно управляют записью своих данных, выполняя большие последовательные I/O запросы. Поэтому зачастую такие приложения открывают файлы с флагом O_DIRECT, который указывает ядру писать данные в такой файл, минуя write-back cache, напрямую из памяти пользовательского приложения. В случае работы одной базы данных на хосте такой подход оказывается эффективнее, чем запись через кэш, поскольку I/O запросы от базы данных уже выстроены оптимальным образом и нет необходимости в дополнительном копировании памяти из пользовательского приложения в write-back cache.

В случае работы нескольких контейнеров с базами данных на одном хосте данное предположение оказывается неверным, так как планировщик I/O в ядре Linux не может оптимально распределять ресурсы диска между приложениями, использующими Direct I/O. Поэтому по умолчанию в ядре OpenVZ Direct I/O для контейнеров выключено, и все данные пишутся через write-back cache. Это вносит небольшие накладные расходы в виде дополнительного копирования памяти из пользовательского приложения в write-back cache, при этом позволяя планировщику I/O ядра эффективнее распределять ресурсы диска.

Если заранее известно, что подобной ситуации на хосте не будет, то можно избежать дополнительных накладных расходов и разрешить использование Direct I/O всем или части контейнеров. Настроить поведение ядра можно, используя файл /proc/sys/fs/odirect_enable. Возможные значения данного файла в случае настройки на host node (глобальные настройки):

  0        флаг O_DIRECT игнорируется для контейнеров, вся запись происходит через write-back cache (значение по умолчанию)
  1        флаг O_DIRECT в контейнерах работает как обычно


Возможные значения данного файла в случае настройки внутри конкретного контейнера:

  0        флаг O_DIRECT игнорируется для данного контейнера, вся запись происходит через write-back cache
  1        флаг O_DIRECT для данного контейнера работает как обычно
  2        использовать глобальные настройки (значение по умолчанию)


Заключение


Вообще ядро Linux в целом, и OpenVZ в частности, предоставляют большое количество возможностей тонкой настройки производительности под конкретные задачи пользователя. Виртуализация на базе OpenVZ позволяет обеспечить максимально возможную производительность за счёт гибкого менеджмента ресурсов и различных настроек. В данной статье мы привели лишь небольшую часть специфических для контейнеров настроек. В частности, я не стал расписывать про три параметра CPUUNITS/CPULIMIT/CPUS и как они все три друг на друга влияют. Но готов это и многое другое пояснить в комментариях.
Для более полной информации читайте vzctl man page и массу ресурсов в интернете, например, openvz.livejournal.com.
Автор: @pbor
Parallels
рейтинг 272,03

Комментарии (42)

  • +2
    Отличная статья :)
    • +7
      Очень страшно от хостера видеть такой комментарий!:)

      Все предложенные способы конечно могут увеличить производительность, но за это приходится чем-то платить.
      Если мы отключаем O_DIRECT / fsync в контейнере, то клиент имеет шанс потерять данные.
      Оверкоммиты по памяти и процессору конечно уже не столь деструктивны, но и это может негативно сказаться совместном исполнении нескольких контейнеров внутри одной машины.
      • +2
        Само по себе отключение O_DIRECT *не может* привести к потере данных.
        Гарантированно на диск данные попадают только после успешно выполненных fsync()/fdatasync().
        И они нужны вне зависимости от того, как писались данные (через кэш или напрямую).
        • +2
          Не спорю, именно поэтому написал их вместе:)

          Кстати если мы отключаем O_DIRECT, а внутри у нас какая-то умная база данных, которая делает свой кеш данных в памяти вместо page cache, то на деле у данные могут хранится в двух копиях. В кеше программы и page cache. При этом, вытесняя что-то полезное из page cache можно так же навредить и уменьшить производительность других контейнеров и упереться в диски на случайное чтение.

          Аффинити по NUMA-нодам правда даёт снижение latency к памяти, но возможны ситуации когда процессорного времени одного сокета начинает не хватать, и тогда контейнер, который съедает всё процессорное время на numa-ноде, будет очень сильно мешать другим контейнерам на той же numa-ноде.
          Польза будет в том случае, если мы упираемся в latency RAM, но не в процессорное время.
          • +4
            Конечно, в случае O_DIRECT нет одного универсального, подходящего всем решения. Поэтому и дана ручка, позволяющая настраивать его поведение (в том числе индивидуально, для каждого контейнера). Для того и статья, чтобы про ручку знали :)

            Согласен с тем, что аффинити по NUMA-нодам в случае оверкоммита по CPU, может сделать только хуже, про это в статье тоже есть предупреждение ;) Это, скорее информация для тех, кто оверкоммитить не собирается, но кому нужно выжать максимальную производительность из машины, при этом изолируя компоненты системы в разных контейнерах.
            • +4
              В любом случае спасибо за статью.

              Просто всегда нужно знать что можно крутить и к чему это может привести:)
          • 0
            С page cache у OpenVZ вообще все плохо, фича по его изоялции есть (ubc.pagecache_isolation = 0), но по дефалту не включена нигде — даже в коммерческом продукте ;)
            • 0
              Уже включена =)
              • 0
                Не лучшая идея, это серьезно увеличивает потребление памяти и вызывает проблемы в случае, когда памяти достаточно и она еще могла бы быть использована под кэш и ускорение впски. А в этом случае кэша не будет и будет долбаться дисковая система.

                Это плохое решение данной проблемы. Хорошее — аналог ZFS/L2ARC.
                • 0
                  Да, я читал ваши комментарии на других ресурсах. Но как я понял вы сами хотели эту «фичу» по дефолту изменить. Что же изменилось за год?
                  • 0
                    Никаких подвижек, мы её не используем по причине означенных проблем :( Саппорт || также не может сказать однозначно о оверхеде и серьезных доводах за и против данного флага.
                    • 0
                      Народ требовал — сделали, народу не нравится — в следующем релизе удалят. Все ОК =)
                      • +1
                        Народ требовал изоляцию с умом, а данная реализация мягко говоря не айс =)
                        • 0
                          Кстати, нашел тут тикет товарища: bugzilla.openvz.org/show_bug.cgi?id=2823, попросил дать комментарии в нем. У нас вроде такой проблемы не было, но надо проверить внимательно… Займемся.
                          • 0
                            Не наблюдал подобного.
                          • 0
                            Я бы на месте разработчиков также не отвечал. Информации ноль. Почему не показано что конкретно в файловом кэше? Почему нету вывода всех параметров sysctl?

                            С такими исходными данными можно ежедневно по сто багов создавать.
                            • 0
                              Это не мой тикет — вопрос к автору =)
                              • 0
                                Да я понял =)
        • 0
          Это зависит от диска, точнее от его кеша.
          • 0
            Обычно это все же кэш RAID контроллера, использовать тот же ploop без резервированного батарейкой кэша — смертельный номер.
      • –1
        Еще как страшно.
        Если уж хостер соглашается с необходимостью ребутить машины ради минорных улучшений производительности — нафиг он такой нужен.
        (обычно же как все происходит: падение системы, падение системы после правок на скорую руку, запланированный ребут; спонтанный незапланированный ребут на тему «все равно все падало, давайте это зафиксим» — ересь полная)
  • 0
    Атата, а про --numa не указали, кто оплачивал доработку и открытие фичи! :)

    Еще стоило бы добавить, что для грамотного балансинга нужно написать свой демон, который будет переносить контейнеры с одной NUMA ноды на другую. В PCS он есть — numabalanced.

    По поводу O_DIRECT и FSYNC — инфа ценная, но крайне опасная, от обоих фич на порядки больше зла, чем пользы. Сейчас куча народу пойдет и врубит себе это и погубит себе данные, а-то и клиентам :/

    Было бы круто почитать подобное по ploop, ибо по нему инфы почти нету, а возможностей «отстрелить себе ногу веревкой» там решительно больше.
    • +1
      Почему не указали? В release notes к vzctl все есть :)

      Про O_DIRECT/fsync() — мое мнение такое, что лучше иметь возможности тонкой настройки системы (пускай и довольно опасные, если подходить без знания дела), чем вообще не иметь такой возможности.
  • 0
    Кстати, Вы бы удалили vzcpucheck что ли, а-то он больше людей запутывает, чем пользы приносит :)
  • +2
    Ах, вот еще «при этом нужно понимать, что если какой-либо процесс из, например, контейнера 100 уже выделил память на NUMA-ноде 1, то каждый доступ к этой памяти будет медленнее, чем доступ к локальной памяти. Поэтому рекомендуется перезапустить контейнеры после выполнения этих команд.»

    Неправда Ваша — достаточно поменять привязку машины к другой numa ноде и сделать следующий финт ушами:
    echo 0,1 > /proc/vz/fairsched/58268/cpuset.mem_migration_pending

    И после этого OpenVZ очень быстро перетащит память на требуемую NUMA ноду и локализует всю свою память на ней впредь :)
  • 0
    Отключение O_DIRECT для контейнера с СУБД — это прямой путь к порченной базе данных. Если БД или файловая система хотят записать данные именно так и именно сейчас, то лучше это позволять — иначе нарушаются все обещания/ожидания и консистентность никто больше обещать не может. Более того, повреждения могут быть молчаливыми (то есть «исчезла транзакция с начислением зарплаты»).
    • +2
      Такое утверждение неверно. Сам по себе O_DIRECT никаких гарантий, что после успешного завершения системного вызова write() данные попадут на энергонезависимый носитель, не дает. Такие гарантии могут дать только успешно завершенные системные вызовы fsync()/fdatasync(). До этого момента данных могут быть, например, в кэше самого диска или в кэше raid-контроллера.
  • 0
    А может быть вы напишите чуть более развернуто про лимиты и их мониторинг?
    Там же есть такие увлекательные vmguarpages, shmpages или lockedpages. Или например про интерпритацию вывода vzmemcheck. А уж как работает vzsplit для меня пока загадка — пытался получить то него конфиг, так он уверял, что на моем железе можно поднять 1000 нелимитированных машинок :)
    • 0
      А что в shmpages интересного? В нем совершенно никакого смысла сейчас нету, все аккаунтится посредством physpages и shmpages включается в него.

      Если требуется управление лимитами памяти (выделяемой, гарантируемой, общей), то вместо тюнинга privvmpages сейчас используется параметр vm_overcommit и задаваемый объем vswap и далее указывается просто --ram и --swap, а параметры physpages, oomguarpages и vmguarpages генерирует сам vzctl.

  • 0
    А слона и не заметил… Как задать cpulimit для OpenVZ в мегагерцах?
    • +1
      «желаемые MHz» * 100 / «MHz одного CPU»
      (если у хоста, например, 8 CPU, то максимально допустимый процент будет составлять 800%)
      • 0
        Этот способ даже задокументирован, с ним проблем нету. OpenVZ ядро позволяет забить именно мегагерцы, явно. Про что и упомянуто «также иногда может быть полезно лимитировать CPU в процентах (или же в мегагерцах) с помощью опции --cpulimit». Но вот возможности этой в vzctl я не видел либо она не документирована.
        • +2
          Да, извиняюсь, мой косяк. vzctl из состава OpenVZ напрямую в мегагерцах ставить не дает.
          vzctl из состава PCS так умеет, нужно добавит суффикс 'm' после значения, например:

          vzctl set 111 --cpulimit 1500m
          • +1
            А в OpenVZ'шный vzctl планируется добавить такую возможность, т.к. на данный момент я вижу только один вариант:

            самописный скрипт-костыль обсчитывает правильный Rate на основе переданных в него MHz'ах и загоняет результат в /proc/vz/fairsched/$CID/cpu.rate
          • 0
            Голосую за добавление такой фичи в OpenVZ! Тем более упомянутой в пресс-релизе самого Parallels :) Сообщество будет бесконечно Вам благодарно.
            • 0
              Тогде еще вопрос, цитирую man vzctl от PCS:
              --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?
              • +1
                Да. Если задать, например, 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%
                • +1
                  Вы еще сделайте эту фичу для OpenVZ, раз в статье зацепили её — это будет честно :)
  • 0
    После долгого обсуждения сошлись на очень хитром эффекте, а именно, если для Innodb выставить тип коммита O_DIRECT вместо стандартного sync/fdatasync, то на OpenVZ это приведет к очень крутому ускорению работы базы данных.

    Но как раз в данной статьей красиво объяснено то, что OpenVZ игнорирует O_DIRECT и тем самым указывая такой флаг для MySQL мы отключаем вообще как таковую работу с транзакциями. То есть что есть транзакция, что нету — данные будут записаны по flush таймауту ext4 (5 секунд), а не тогда, когда этого хочет MySQL.

    Возможно, в случае очень высокой нагрузки это может привести к потере данных, но в общем случае конфигурация дисковой системы HWN нод подразумевает высокий уровень резервирования (BBU, кэши, UPS, дизеля) и вероятность подобного развития событий (с повреждением данных) очень низкая.
    • 0
      если для Innodb выставить тип коммита O_DIRECT вместо стандартного sync/fdatasync, то на OpenVZ это приведет к очень крутому ускорению работы базы данных.

      Это касается не только OpenVZ.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное