Як можна знизити споживання оперативної пам’яті на VPS у 2 рази, нічого не змінюючи у налаштуваннях
Взяв VPS, побудований на OpenVZ. Поставив туди Debian Lenny та всілякі програми (звичайний LAMP, по суті). З погляду споживання ресурсів нічого майже не налаштовував, вийшло десь 200М зайнятої оперативної пам'яті (відразу після старту). Написав ulimit -s 1024 /etc/init.d/rc ближче до верху. Перезавантажився. Споживання пам'яті на VPS впало більш ніж удвічі, близько 100М.
Якщо у Вас є VPS на Xen або аналогічних, то у Вас немає граблів, з якими я тут боровся. Якщо на OpenVZ (Virtuozzo) з товаришами - у Вас, швидше за все, на 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 під стек - це, як правило, дуже багато)
Мені видався оптимальним розмір 2М. Екстремали та експериментатори можуть знижувати і далі (пробував, у мене і на 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К, і не плачуть. А від зниження макс. глибини стека звільняється купа оперативної пам'яті для найважливіших штук.
Критика та зауваження вітається.
Хардкорна конфа за С++. Ми запрошуємо лише профі.