Отладка нехватки памяти с помощью /var/log/messages

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

решение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 использует гораздо больше ОЗУ. Это объясняет, почему вы видите завершение процессов.

Связанный контент