Новость одной строкой: теперь клиенты могут изменять параметры MOD из панели управления.

Давным-давно в нашем mod-server'е была реализована возможность управления параметрами выделения памяти. Это было реализовано на уровне самого сервера и параметров базы данных.

… Но этого не было в веб-интерфейсе. Самые настойчивые клиенты просили изменить настройки — и мы их меняли вручную. Глупо, да?

Наконец-таки, мы исправили ситуацию — настройки MOD-сервера стали доступны клиентам. Большая их часть применяется «на ходу» и не требует перезагрузки или приостановки обслуживания.

Принцип работы Memory-on-Demand

В зависимости от количества запущенных программ, требуется различный объём памяти. Поскольку память оплачивается в «гигабайто-часах» (на самом деле, в килобайто-наносекундах), то тратить лишние деньги на неиспользуемую память жалко. Но и ютиться в маленьком объёме, залезая в своп, тоже нехорошо.

Вся система MOD состоит из трёх компонент: сервера, базы данных (настройки) и агентов.

Агент — modd (mod daemon) запущен внутри гостевой машины, он записывает в xenstore (система, благодаря которой возможно взаимодействие гостевой системы и управляющей в dom0 без использования сети) информацию о текущем состоянии памяти. Точнее, он просто записывает данные из /proc/meminfo в xenstore в data/mod_meminfo.

Сервер смотрит на эти цифры и решает, добавить ли памяти, или уменьшить. Алгоритм работы MOD-сервера (в общих чертах): считается объём свободной памяти (мы правильно учитываем buffers и cached), если её больше, чем нужно, то память уменьшают. Если меньше, чем нужно — то увеличивают.

Параметры, управляющие работой MOD

MOD имеет следующие параметры:

• жёсткие лимиты памяти — абсолютный минимум и максимум. Эти лимиты определяют границы, в пределах которых возможно изменение объёма памяти. Наличие этих границ — техническое ограничение используемого у нас гипервизора (Xen 3.4). Рекомендуемое соотношение минимума и максимума примерно 1 к 4, максимум 1 к 8. (На экстремальных значениях вида 128Мб — 48Гб можно запросто схлопотать kernel panic из-за того, что у ядра не хватает собственной памяти для обслуживания теоретического лимита). Эти лимиты не параметры MOD — мы их объединили в одну страницу просто потому, что вынос их в отдельное место увеличил бы путаницу.
• Галка «включить»/«выключить», она всего лишь выключает (включает) MOD. Если MOD выключить, то память фиксируется на последней выставленной величине и больше никак не меняется.
• «Мягкие лимиты» памяти. Эти лимиты определяют в каких пределах регулировать память. Заметим, это не совсем «лимиты», это, скорее, пожелание к размеру памяти. Если выставить эти числа слишком маленькими, то xen их проигнорирует, если выставить слишком большими — аналогично.
• Границы свободной памяти. Это самая интересная пара чисел — она определяет, сколько свободной памяти должно быть в виртуальной машине. Точнее, аналогично мягкому лимиту, указывает к какому значению следует стремиться MOD-серверу.
  Эти величины не могут быть равны нулю (если у вас 0 свободной памяти, то либо вы идёте в своп, либо ядро падает). Они так же не могут быть равны друг другу — у этого есть очень довольно специфичное объяснение — если бы лимиты были равны друг другу, то могли бы возникнуть самовзбуждающиеся колебания (, допустим, нам не хватает 8кб. Алгоритм: добавить 16кб, убрать 16кб, добавить 16кб, убрать 16кб...). Поскольку при отдаче памяти в гипервизор, гостевая машина память чистит (было бы странно отдавать память вместе с содержимым), то это операция для клиента не совсем бесплатная. Единичные добавления/удаления памяти занимают незначительные ресурсы; однако, если бы память начала дёргаться туда-сюда постоянно, это создало бы паразитную нагрузку. Значения по-умолчанию — минимум — 96Мб, максимум 192Мб. Для шаблона Mini значения 24 и 32Мб соответственно.

Если в поле написан ноль (или ничего не написано), значит, используются значения по-умолчанию.

Исключения

Список приложений, для которых MOD не нужен. Если приложение является основным на сервере, лимиты памяти можно выставить одинаковыми и не мучать сервер по-понапрасну:

• JRE, JEEE, Tomcat и прочие Java-based — java использует свой механизм распределения памяти
• MongoDB — читает настройки памяти при запуске, не проверяет и не обрабатывает ошибки выделения памяти

P.S. Предыдущий топик по этой теме: habrahabr.ru/company/selectel/blog/99157/