Налагодження поза пам'яті за допомогою / var / log / messages

У журнал моїх повідомлень міститься такий звіт:

kernel: Out of memory: Kill process 9163 (mysqld) score 511 or sacrifice child
kernel: Killed process 9163, UID 27, (mysqld) total-vm:2457368kB, anon-rss:816780kB, file-rss:4kB

Не має значення , якщо ця проблема для httpd, mysqldабо , postfixале мені цікаво , як я можу продовжити налагодження проблеми.

Як я можу отримати більш детальну інформацію про те, чому PID 9163 вбито, і я не впевнений, чи зберігає Linux десь історію для припинених PID.

Якщо це трапляється у вашому файлі журналу повідомлень, як ви вирішите цю проблему поетапно?

# free -m

             total       used       free     shared    buffers     cached
Mem:          1655        934        721          0         10         52
-/+ buffers/cache:        871        784
Swap:          109          6        103`

Ядро буде записати купу матеріалів до того, як це сталося, але більшість його, мабуть, не буде /var/log/messages, залежно від того, як (r)syslogdналаштовано ваш файл . Спробуйте:

grep oom /var/log/*
grep total_vm /var/log/*

Перший повинен показувати купу разів, а другий лише в одному-двох місцях. Це файл, який ви хочете подивитися.

Знайдіть оригінальний рядок "Без пам'яті" в одному з файлів, який також містить total_vm. Тридцять секунди на хвилину (може бути більше, може бути і менше) перед цим рядком ви знайдете щось на зразок:

kernel: foobar invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

Ви також повинні знайти таблицю десь між цим рядком та рядком "З пам'яті" з такими заголовками:

[ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name

Це може не сказати вам набагато більше, ніж ви вже знаєте, але поля такі:

• pid Ідентифікатор процесу.
• uid ID користувача.
• tgid ID групи ниток.
• total_vm Використання віртуальної пам'яті (на 4 кБ сторінок)
• rss Використання постійної пам'яті (на 4 кБ сторінок)
• nr_ptes Записи таблиці сторінок
• swapents Поміняти записи
• oom_score_adj Зазвичай 0; менша кількість вказує на те, що процес викликає менше шансів загинути, коли викликається вбивця OOM.

Ви здебільшого можете ігнорувати, nr_ptesі swapentsхоча я вважаю, що це фактори, які визначають, хто загине. Це не обов'язково процес, що використовує найбільшу пам'ять, але це дуже ймовірно. Більше про процес відбору дивіться тут . В основному, процес, який закінчується найвищим балом oom, вбивається - ось "оцінка", що повідомляється у рядку "З пам'яті"; на жаль, про інші бали не повідомляється, але ця таблиця містить деякі підказки з точки зору факторів.

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

Ключ до цього в самому повідомленні - Без пам'яті . Коли ядро ​​Linux голодує від віртуальної пам’яті (фізична оперативна пам’ять плюс своп), воно почне вбивати процеси, і саме тут відбулося. Схоже, mysqldбуло використано понад 2 ГБ віртуальної пам'яті.

Скільки оперативної пам’яті та свопів має система? Я б подумав додати додаткову оперативну пам’ять або, якщо це неможливо, додати додатковий своп. Щоб швидко запобігти припиненню процесів, ви можете додати файл swap.

Оновлення: дивлячись на об’єм оперативної пам’яті, ви можете відразу побачити проблему. У вас ~ 1.6 Гб оперативної пам’яті та 100 Мб свопу, але MySQL використовує набагато більше оперативної пам’яті, ніж це. Це пояснює, чому ви бачите, що процеси припиняються.