Вопрос или проблема
Убийца OOM только что убил какой-то процесс. Я могу узнать об этом, когда значение grep oom_kill /proc/vmstat увеличится.
Как я могу узнать, какой именно процесс был убит (имя, pid, владелец и так далее) и когда именно (метка времени)?
Простой, но легкий способ узнать детали о недавнем OOM-убийстве — это выполнить grep везде (путь к логам может отличаться от дистрибутива к дистрибутиву):
sudo dmesg -T | grep -Ei 'killed process|oom.killer'
sudo grep -Ei 'killed process|oom.killer' /var/log/messages /var/log/syslog 2>/dev/null
. означает “любой символ” в регулярных выражениях для grep, поэтому он найдет строки, содержащие как “oom-killer”, так и “oom killer”.
2>/dev/null в конце необходимо для устранения ошибки “Нет такого файла или каталога”, если в вашей системе нет таких логов.
Ищите записи о событиях ОOM-убийцы в логах.
sudo grep -i "oom-killer" /var/log/messages
Результат выглядит примерно так:
kernel: [timestamp] Out of memory: Kill process [process_name] ([process_pid]), UID [user_id]/[username], VmSize:[memory_size] kB, VmRSS:[resident_memory_size] kB, MemLimit:[memory_limit] kB
Ответ или решение
Чтобы определить, какой именно процесс был убит OOM-убийцей в Linux, следует использовать несколько подходов для сбора информации об этом событии. При возникновении нехватки оперативной памяти ядро операционной системы инициирует OOM-убийцу, который завершает процессы в попытке освободить ресурсы. Вы можете легко выявить убитый процесс с помощью следующих шагов.
1. Отслеживание OOM-убийцы через систему логирования
Наиболее распространенным способом определения убитых процессов является распространение по системным логам. В зависимости от конфигурации системы логи могут находиться в различных местах. В основном полезные сведения можно найти в следующих файлах:
/var/log/messages/var/log/syslog/var/log/kern.log
Используйте команды grep для поиска записей, связанных с OOM-убийцей:
sudo dmesg -T | grep -Ei 'killed process|oom.killer'
sudo grep -Ei 'killed process|oom.killer' /var/log/messages /var/log/syslog 2>/dev/nullЭти команды помогут отфильтровать записи, в которых упоминается OOM-убийца, что позволит получить все нужные данные одновременно. Важно обратить внимание, что 2>/dev/null используется для подавления сообщений об ошибках, если в системе не существуют указанные файлы логов.
2. Анализ логов
После выполнения команд, приведенных выше, вы должны увидеть записи, которые будут выглядеть примерно так:
kernel: [timestamp] Out of memory: Kill process [process_name] ([process_pid]), UID [user_id]/[username], VmSize:[memory_size] kB, VmRSS:[resident_memory_size] kB, MemLimit:[memory_limit] kBВ этих записях содержатся следующие критически важные детали:
- timestamp — метка времени, когда произошло событие, что позволяет определить, когда именно система не смогла выделить память и убила процесс.
- process_name — наименование убитого процесса.
- process_pid — идентификатор процесса, который был завершен OOM-убийцей.
- user_id/user_name — UID и имя владельца процесса, что может помочь в дальнейшей диагностике и понимании контекста.
- memory_size — общий размер виртуальной памяти, используемый процессом.
- resident_memory_size — фактический объем оперативной памяти, используемой процессом.
- memory_limit — максимальный лимит памяти, установленный для данного процесса (если установлен).
3. Использование системного мониторинга
Системы мониторинга, такие как Prometheus или Grafana, могут также помочь в отслеживании и получении уведомлений о событиях OOM. Настройка таких систем предоставляет возможность получать более детализированную информацию о потреблении ресурсов и потенциальных предупреждениях до момента срабатывания OOM-убийцы.
Заключение
Таким образом, для получения информации о процессах, убитых OOM-убийцей, следует активно использовать логи системы и инструменты для мониторинга. Регулярный анализ данных в системных логах и применение средств мониторинга могут помочь предотвратить проблемы с нехваткой памяти в будущем и улучшить стабильность системы.