10 авг 2010
Как можно снизить потребление оперативной памяти на VDS\VPS в 2 раза.
Dmitrius Категория: LINUX » Общие советы
У нас вы можете скачать бесплатно Как можно снизить потребление оперативной памяти на VDS\VPS в 2 раза. .

Данный материал предоставлен сайтом Skripter.info исключительно в ознакомительных целях. Администрация не несет ответственности за его содержимое.
Как можно снизить потребление оперативной памяти на VDSVPS в 2 раза.

Взял VDS, построенный на OpenVZ. Поставил туда Debian Lenny и всякие программы (обычный LAMP, по сути). С точки зрения потребления ресурсов ничего почти не настраивал, вышло где-то 200М занятой оперативной памяти (сразу после старта).
Написал ulimit -s 1024 в /etc/init.d/rc ближе к верху. Перезагрузился. Потребление памяти на VDS упало более чем вдвое, стало около 100М.

Если у Вас VDS\VPS на Xen или аналогичных, то у Вас нет граблей, с которыми я тут боролся. Если на OpenVZ (Virtuozzo) со товарищи — у Вас, скорее всего, на VDS\VPS эти же грабли.

В статье — почему и как это работает.

OpenVZ vs Xen

Отличие OpenVZ от Xen, которое нас тут интересует: в OpenVZ ограничивается виртуальная память. Т.е., например, тарифы вида «256М + 256М burstable» означают, что нам доступно макс. 256М именно виртуальной памяти (и 512М виртуальной по праздникам).

Многие программы выделяют себе виртуальной памяти «про запас», т.к. при обычной работе (или виртуализации через Xen со товарищи) ее можно выделить сколько угодно (втч > доступной физически) безо всяких последствий. Это одна из причин, по котрой VPS на Xen стоят дороже аналогичных по характеристикам VPS на OpenVZ — они реально предоставляют больше ресурсов.

Но это еще не все

На каждый запущенный тред в виртуальной памяти выделяется место под стек. Так вот, в debian lenny, например, по умолчанию это место = 10М. Берем какой-нибудь apache с mpm_worker (который создает кучу тредов), запускаем под OpenVZ — тратятся сотни мегабайт памяти.

10 мегабайт под стек — это много. А установлено столько, т.к. при нормальном запуске linux эта память «бесплатная» — можно было бы хоть 100M установить без негативных эффектов (разве что программы с багами на рекурсию агонизировали бы дольше). Обычно программам требуется в разы меньше, даже с учетом «про запас».

Уменьшаем размер стека по умолчанию

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

Уменьшить размер стека по умолчанию можно командой ulimit -s . Параметр меняется для программ, запущенных из текущего шелла (ну иерархически тоже ессно). Запускаем эту штуку при загрузке системы (внутри скрипта, стартующего демоны) — и все.

Тут очевидное предупреждение — если установить слишком низкий лимит, что-нибудь сложное (с кучей рекурсивного кода или непонятно-зачем-хитрой работой со стеком) может начать падать. Осторожность не повредит. Вы предупреждены. Делайте бэкапы. Но 10M под стек — это, в большинстве случаев, очень много)

Мне показался оптимальным размер 1М. Экстремалы и экспериментаторы могут снижать и дальше (пробовал, у меня и на 32К все работало прекрасно), но там выигрыш уже небольшой получается, а риск возрастает, смысла мало вообщем. Хотя — пробуйте.

В принципе, запуск ulimit для всех процессов — довольно грубо. Для более тонкой настройки можно(задолбаться) править скрипты запуска отдельных демонов. Также у некоторых программ можно в конфигах менять память, которую они будут выделять на стек треда, пример — apache, директива ThreadStackSize для mpm_worker. Собственно говоря, у меня апач и был настроен в режиме worker (php — через fastcgi, если что), а память на стек ограничивалась с помощью ThreadStackSize без ulimit (то снижение в 2 раза было за счет mysql с InnoDB, fastcgi-процессов php, mail-сервера и всякой мелочи).

Для тестирования всего этого дела, если боязно лезть сразу в /etc/init.d/rc, можете
1) посмотреть, сколько занимает в памяти какой-нибудь процесс,
2) в шелле ввести ulimit -s ,
3) перезапустить процесс (что-нибудь в духе /etc/init.d/mysql restart)
4) посмотреть еще раз, сколько теперь занимает, и проверить, что все работает.

Мысли

В итоге мы имеем: пользователи OpenVZ расплачиваются кучей оперативной памяти за возможность когда-нибудь (черти когда) запустить редкую хитрую программу, тогда как всем остальным это не стоит ничего. Поэтому поступаем, как мне кажется, логично: при виртуализации OpenVZ снижаем макс. глубину стека до 1-2М. На всяких HP-UX (который я, правда, в глаза не видел), например, 64К, и не плачут. А от снижения макс. глубины стека освобождается куча оперативной памяти для более важных штук.

Критика и замечания приветствуется.










Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии к данной публикации.