Давним-давно в одній далекій селі заморської жили серверів лінуксячіх CentOS-них десятків пару. Ядра - чистий смарагд (2.6.18-194.17.1.el5). Жили-не тужили, гвинтами шаруділи та лампочками весело переморгувались. І жили разом з ними в тому селі девелопер-буйна голівонька і адмін-добрий молодець. Девелопер всякі хитрі штуки на java вигадував, а адмін мед-пиво пив, по вусах текло, на клавіатуру капало.
І ось одного разу девелоперу прийшла в світлих голівоньку думка - на цих серверах всякі документи чудові в форматах іноземних в чистий html перетворювати, та не просто перетворювати, а через openoffice. Задумано - зроблено. І стали раптом відразу чудеса відбуватися - сервера занадилися один за іншим журитися, працювати як заведено переставали, на консоль жалібно писали, що, мовляв, немає в них більше силушки богатирської, бо пам'ять оператівния вся вільна вийшла, і навіть oom-killer справи не допомагає (бо хоч і намагається процеси до пам'яті охочі стратити, та рідко потрапляє в якісь потрібно). Та не просто вийшла, а так що і "swap free: 0Kb". І далі тільки чарівний ребут допомагав. Засумував тоді адмін, бо мед-пиво більше пити було ніколи, все сервера впали тільки і піднімав. Так робити нічого - не будеш же писалом на бересті html писати, openoffic-му якось все ж зручніше було.
Одного разу наснився адміну сон. Явився йому святий Патрег в золотому сяйві і каже людським голосом: "А ти політику виділення пам'яті, з давніх-давен в лінукс-ядрах за замовчуванням прийняту, так поміняв би. Постав vm.overcommit_memory = 2 замість дефолтного 0, авось, перестане пам'ять закінчуватися". Послухався поради адмін, вранці взяв bash чудодійний і зробив як йому Патрег уві сні говорив:
echo 2> / proc / sys / vm / overcommit_memory
І сталося диво тоді - перестали сервера в журбу впадати, знов запрацювали ще дужче. Зрадів адмін, і вирішив мудрість здобуту в скрижалях висікти, щоб синам і онукам легше було з норовистим лінуксом впоратися і ще про запас в /etc/sysctl.conf запаси зробив:
Про vm.overcommit_ratio = 100 адмін вже сам збагнув, бо з дефолтних 50 занадто часто java "Can not allocate memory" отримувала. І ось дійшла з тієї пори мудрість наступна до наших часів:
Є ядрі два основних параметри, що відповідають за overcommit пам'яті:
- vm.overcommit_memory - відповідає за стратегію overcommit.
- vm.overcommit_ratio - відповідає за рівень (у відсотках) overcommit-а
Стратегії є такі (див. Файл з вихідними кодами ядра mm / mmap.c):
- 0 - OVERCOMMIT_GUESS - евристичний підхід до розподілу пам'яті. У ньому виділяється стільки пам'яті, скільки хоче процес. Але в swap / res потрапляє тільки ті сторінки, які використовуються цим процесом.
- 1 - OVERCOMMIT_ALWAYS - overcommit пам'яті є завжди. Використовувати краще з зовсім кривими програмами та бути готовим при цьому до всього.
- 2 - OVERCOMMIT_NEVER - без overcommit. В цьому випадку допустимий обсяг простору пам'яті буде swap + ram * overcommit_ratio / 100.
За замовчуванням використовується стратегія OVERCOMMIT_GUESS, а vm.overcommit_ratio знаходиться в значення 50% і використовується тільки в разі OVERCOMMIT_NEVER. Система резервує близько 3% пам'яті для процесів користувача root.