В моем журнале сообщений появился следующий отчет:
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`
решение1
Ядро зарегистрировало кучу всего, прежде чем это произошло, но большая часть этого, вероятно, не будет в /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
Это, возможно, не скажет вам ничего нового о том, что вы уже знаете, но поля следующие:
- пидИдентификатор процесса.
- uidID пользователя.
- тгидИдентификатор группы тем.
- всего_вмИспользование виртуальной памяти (на страницах по 4 КБ)
- rssИспользование резидентной памяти (на страницах по 4 кБ)
- nr_ptesЗаписи таблицы страниц
- свопыОбмен записями
- oom_score_adjОбычно 0; меньшее число указывает на то, что процесс с меньшей вероятностью завершится при вызове OOM killer.
Вы можете в основном игнорировать nr_ptes
, и swapents
хотя я считаю, что это факторы, определяющие, кого убьют. Это не обязательно процесс, использующий больше всего памяти, но очень вероятно, что это так. Подробнее о процессе выбора,глянь сюда. По сути, процесс, который в итоге набирает наивысшую оценку oom, завершается — это «оценка», указанная в строке «Недостаточно памяти»; к сожалению, другие оценки не указываются, но эта таблица дает некоторые подсказки с точки зрения факторов.
Опять же, это, вероятно, не сделает ничего, кроме как прояснит очевидное: системе не хватило памяти, и mysqld
она была выбрана для остановки.потому что его уничтожение высвободит больше всего ресурсов. Это не обязательно означает, mysqld
что вы делаете что-то неправильно. Вы можете посмотреть на таблицу, чтобы увидеть, не вышло ли что-то еще за рамки в тот момент, но может и не быть явного виновника: системе может не хватить памяти просто потому, что вы неправильно оценили или неправильно настроили запущенные процессы.
решение2
Ключ к этому кроется в самом сообщении -Недостаточно памяти. Когда ядру Linux не хватает виртуальной памяти (физическая оперативная память плюс подкачка), оно начинает убивать процессы, и это именно то, что здесь произошло. Похоже, что mysqld
использовалось более 2 ГБ виртуальной памяти.
Сколько RAM и swap в системе? Я бы рассмотрел возможность добавления дополнительной RAM или, если это невозможно, добавления дополнительного swap. В качестве быстрого решения, чтобы хотя бы предотвратить завершение процессов, можно добавить файл подкачки.
Обновлять:Глядя на объем ОЗУ, вы сразу видите проблему. У вас ~1,6 ГБ ОЗУ и 100 МБ подкачки, но MySQL использует гораздо больше ОЗУ. Это объясняет, почему вы видите завершение процессов.