Отладка нехватки памяти с / 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/*

Первый должен появляться несколько раз, а второй только в одном или двух местах. Это файл, который вы хотите посмотреть.

Найдите оригинальную строку «Out of memory» в одном из файлов, который также содержит 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 ГБ виртуальной памяти.

Сколько оперативной памяти и подкачки у системы? Я хотел бы добавить дополнительную оперативную память или, если это невозможно, добавить дополнительную подкачку. В качестве быстрого решения, по крайней мере, для предотвращения остановки процессов, вы можете добавить файл подкачки.

Обновление: смотря на объем оперативной памяти, вы можете сразу увидеть проблему. У вас ~ 1,6 ГБ ОЗУ и 100 МБ подкачки, но MySQL использует гораздо больше ОЗУ. Это объясняет, почему вы видите прекращение процессов.