Уникайте схилу програми поза пам'яттю Linux

Я виявляю, що іноді в моєму Linux-вікні не вистачає пам'яті, і він починає виривати випадкові процеси для боротьби з ним.

Мені цікаво, що робити адміністраторам, щоб уникнути цього? Є єдине реальне рішення збільшити об'єм пам'яті (чи допоможе збільшити обмін своєю суткою?), Чи є кращі способи встановити вікно з програмним забезпеченням, щоб уникнути цього? (тобто квоти, чи якісь такі?).

За замовчуванням Linux має дещо пошкоджену мозку концепцію управління пам’яттю: вона дозволяє виділити більше пам’яті, ніж ваша система, а потім випадковим чином знімає процес в голову, коли він потрапляє в проблеми. (Справжня семантика того, що вбивається, є більш складною, ніж це - Google "Linux OOM Killer" для безлічі деталей та аргументів про те, добре це чи погано).

Щоб відновити деяку подобу розуму для управління пам’яттю:

1. Вимкнути вбивцю OOM ( vm.oom-kill = 0ввести /etc/sysctl.conf)
2. Вимкнути перевиконання пам'яті ( vm.overcommit_memory = 2введіть
   /etc/sysctl.conf ) Зауважте, що це тризначне значення: 0 = "оцінюйте, якщо у нас достатньо оперативної пам’яті", 1 = "Завжди кажіть так", 2 = "скажіть ні, якщо ми цього не зробимо мати пам'ять ")

Ці параметри змусять Linux вести себе традиційним чином (якщо процес вимагає більше пам'яті, ніж доступно, malloc () не вдасться, і очікується, що процес, що запитує пам'ять, впорається з цим збоєм).

Перезавантажте машину, щоб перезавантажити її /etc/sysctl.confабо скористайтеся procфайловою системою, щоб увімкнути її відразу, без перезавантаження:

echo 2 > /proc/sys/vm/overcommit_memory 

Ви можете відключити перезавантаження, див. Http://www.mjmwired.net/kernel/Documentation/sysctl/vm.txt#514

Коротка відповідь для сервера - придбати та встановити більше оперативної пам’яті.

Сервер, який зазвичай достатньо досвідчених помилок OOM (Out-Of-Memory), тоді крім опції overcommit sysctl менеджера VM (віртуальної пам'яті) в ядрах Linux, це не дуже добре.

Підвищення кількості свопу (віртуальної пам'яті, яку викачували на диск менеджером пам'яті ядра) допоможе, якщо поточні значення низькі, а використання передбачає багато завдань для кожного такого великого обсягу пам'яті, а не одного чи кількох обробляє кожен запит величезної кількості всієї доступної віртуальної пам'яті (оперативна пам'ять + своп).

Для багатьох застосувань, що виділяють більше, ніж два рази (2x), кількість оперативної пам’яті як swap забезпечує зменшення віддачі від покращення. У деяких великих обчислювальних моделюваннях це може бути прийнятним, якщо уповільнення швидкості є терпимим.

Оскільки оперативна пам’ять (ECC чи ні) може бути досить доступною для скромних кількостей, наприклад, 4-16 ГБ, мушу визнати, я давно не відчував цієї проблеми.

Основи розгляду споживання пам'яті, включаючи використання freeта topсортування за використанням пам'яті, як дві найпоширеніші швидкі оцінки моделей використання пам'яті. Тому не забудьте зрозуміти значення кожного поля у висновку цих команд як мінімум.

Не маючи конкретних програм (наприклад, база даних, сервер мережевих служб, обробка відео в режимі реального часу) та використання сервера (мало енергетичних користувачів, 100-1000s підключень користувача / клієнта), я не можу придумати жодних загальних рекомендацій щодо роботи з проблема OOM.

Збільшення кількості фізичної пам’яті може не бути ефективною реакцією за будь-яких обставин.

Один із способів перевірити це - команда 'на вершині'. Особливо ці два рядки.

Це поза сервером, коли було здоровим:

MEM | tot   23.7G | free   10.0G | cache   3.9G | buff  185.4M | slab  207.8M |
SWP | tot    5.7G | free    5.7G |              | vmcom  28.1G | vmlim  27.0G |

Коли вона працювала погано (і до того, як ми відрегулювали overcommit_memory з 50 до 90, ми побачимо поведінку з vmcom, який працює понад 50G, процесори, що вбивають oom, що підривають процеси кожні кілька секунд, а навантаження не змінюється радикально підстрибуючи через роздуття дочірніх процесів NFSd вгору і відновлюватися постійно.

Нещодавно ми дублювали випадки, коли багатокористувацькі сервери терміналів Linux масово перевищують розподіл віртуальної пам’яті, але насправді споживається дуже мало запитуваних сторінок.

Хоча не рекомендується дотримуватися цього точного маршруту, ми відрегулювали пам'ять overcommit з 50 до 90 за замовчуванням, що полегшило деякі проблеми. Зрештою, нам довелося перенести всіх користувачів на інший термінальний сервер і перезапустити, щоб побачити всю користь.

Ви можете використовувати ulimit, щоб зменшити об'єм пам'яті, на яку дозволено претендувати на процес, перш ніж його вбити. Це дуже корисно, якщо у вашій проблемі є один або кілька запущених процесів, які вибивають ваш сервер.

Якщо ваша проблема полягає в тому, що вам просто не вистачає пам'яті для запуску потрібних послуг, є лише три рішення:

1. Зменшіть обсяг пам’яті, що використовується вашими службами, обмеживши кеші та подібне

2. Створіть велику область заміни. Це обійдеться вам у продуктивності, але може придбати вам якийсь час.

3. Купіть більше пам’яті

У мене була схожа проблема, пов’язана з цією помилкою, і рішенням було використовувати старіші / новіші (виправлені) ядра.

Однак у той час я не міг перезавантажувати свою машину, тому якийсь некрасивий спосіб вирішення проблеми полягав у тому, щоб увійти як кореневий та чистий кешові системи за допомогою цієї команди:

echo 3 > /proc/sys/vm/drop_caches

@ voretaq7 Linux не має концепції управління пам'яттю з пошкодженнями мозку, за замовчуванням vm.overcommit_ratio дорівнює 0,

0       -   Heuristic overcommit handling. Obvious overcommits of
            address space are refused. Used for a typical system. It
            ensures a seriously wild allocation fails while allowing
            overcommit to reduce swap usage.  root is allowed to
            allocate slightly more memory in this mode. This is the
            default.

Таким чином, якщо у вас є 4 ГБ оперативної пам’яті, і ви намагаєтеся виділити 4,2 ГБ з маликом віртуальної пам'яті, розподіл не вдасться.

З vm.overcommit_ratio = 1

            1    -   Always overcommit. Appropriate for some scientific
            applications. Classic example is code using sparse arrays
            and just relying on the virtual memory consisting almost
            entirely of zero pages.

З vm.overcommit_ratio = 2

           2    -   Don't overcommit. The total address space commit
            for the system is not permitted to exceed swap + a
            configurable percentage (default is 50) of physical RAM.
            Depending on the percentage you use, in most situations
            this means a process will not be killed while accessing
            pages but will receive errors on memory allocation as
            appropriate.

            Useful for applications that want to guarantee their
            memory allocations will be available in the future
            without having to initialize every page.

Отже, Linux за замовчуванням не переповнює, якщо у вашої програми більше пам’яті, ніж у вас, можливо, ваш код баггі