Как можете да намалите консумацията на RAM на VPS с 2 пъти, без да променяте нищо в настройките
Взех VPS, изграден на OpenVZ. Сложете там Debian Lenny и всякакви програми (всъщност нормален LAMP). От гледна точка на потреблението на ресурси, почти нищо не съм настройвал, излезе някъде около 200M заета RAM (веднага след старта). Написа ulimit -s 1024 в /etc/init.d/rc близо до върха. Рестартиран. Консумацията на памет на VPS е намаляла повече от половината до около 100M.
Ако имате VPS на Xen или подобен, тогава нямате рейка, с който се борех тук. Ако сте на OpenVZ (Virtuozzo) с другари, най-вероятно имате същия рейк на VPS.
Статията обяснява защо и как работи.
OpenVZ срещу Xen
Разликата между OpenVZ и Xen, която ни интересува тук:OpenVZ ограничава виртуалната памет. Тоест, например, тарифи от формата „256M + 256M burstable“ означават, че макс. 256M виртуална памет (и 512M виртуална памет по празниците).
Много програми разпределят виртуална памет за себе си "в резерв", т.к. по време на нормална работа (или виртуализация чрез Xen et al.), той може да бъде разпределен колкото желаете (wh > физически достъпен) без никакви последствия. Това е една от причините VPS на Xen да са по-скъпи от подобни VPS на OpenVZ - те всъщност предоставят повече ресурси.
Но това не е всичко
За всяка работеща нишка се разпределя място във виртуалната памет за стек. Така че в debian lenny, например, по подразбиране това място е 10M. Взимаме някакъв apache с mpm_worker (който създава куп нишки), пускаме го под OpenVZ - губят се стотици мегабайти памет.
10 мегабайта на стек са много. И толкова са инсталирани, т.к при нормално стартиране на Linux тази памет е "свободна" −би било възможно да се инсталират поне 100M без отрицателни ефекти (освен ако програмите с грешки за рекурсия не агонизират по-дълго). Обикновено програмите изискват в пъти по-малко, дори като се има предвид "в резерв".
Намаляване на размера на стека по подразбиране
Сървърът не е публичен компютър, програмите, които ще работят там, са предварително известни. Тези програми обикновено правят едно и също нещо през цялото време. Някак си не виждам причините за резките промени в размера на паметта, от която се нуждаят под стека.
Можете да намалите размера на стека по подразбиране с командата ulimit -s. Параметърът се променя за програми, стартирани от текущата обвивка (добре, йерархично, разбира се). Стартираме това нещо при зареждане на системата (вътре в скрипта, който стартира демоните) - и това е всичко.
Тук има очевидно предупреждение - ако зададете ограничението твърде ниско, нещо сложно (с куп рекурсивен код или неразбираема защо-сложна работа със стека) може да започне да пада. Не боли да внимавате. Предупреден си. Правете резервни копия. Но 10 милиона под стека в повечето случаи са много)
Намерих 2M за най-добрия размер. Търсачите на силни усещания и експериментаторите могат да намалят още повече (аз го пробвах, всичко работи добре за мен на 32K), но там печалбата вече е малка, а рискът се увеличава, няма смисъл като цяло. Въпреки че - опитайте.
По принцип пускането на ulimit на всички процеси е доста грубо. За по-фина настройка можете (да ви омръзне) да редактирате стартовите скриптове за отделни демони. Освен това за някои програми можете да промените паметта в конфигурациите, която те ще разпределят към стека на нишките, пример е apache, директивата ThreadStackSize за mpm_worker. В интерес на истината имах Apache и бях конфигуриран в работен режим (php - чрез fastcgi, ако има нещо), а паметта в стека беше ограничена с помощта на ThreadStackSize без ulimit (двукратното намаление беше заmysql акаунт с InnoDB, php fastcgi процеси, пощенски сървър и всякакви малки неща).
За да тествате всичко, ако се страхувате да отидете директно до /etc/init.d/rc, можете 1) да видите колко памет заема даден процес, 2) да въведете ulimit -s в обвивката, 3) да рестартирате процеса (нещо като /etc/init.d/mysql restart ) 4) да погледнете отново колко отнема сега и да проверите дали всичко работи
В резултат на това имаме: потребителите на OpenVZ плащат с куп RAM за възможността някой ден (по дяволите, кога) да стартират рядка сложна програма, докато на всички останали не струва нищо. Следователно, ние действаме, струва ми се, логично: когато виртуализираме OpenVZ, намаляваме макс. дълбочина на стека до 1-2M. На всички видове HP-UX (които обаче никога не съм виждал), например 64K, те не плачат. И от намаляване на макс. дълбочина на стека, много RAM се освобождава за по-важни неща.
Критиката и коментарите са добре дошли.
Hardcore conf в C++. Каним само професионалисти.