LINUX.ORG.RU
Форум — General  

Как проверить oom killer?

 ,


0

2

Завис сервер. Я рассчитывал, что он отвиснет, когда oom killer что-нибудь прибьёт, а он не отвисает до сих пор. Подожду до завтра, но явно ситуация не нормальная. Поэтому на соседнем сервере пытаюсь разобраться.

Сам я ничего не настраивал специально, свопа у системы нет. Система установлена из облачного образа debian.

Почему создал тему - в интернете на каждом сайте пишут, что оно контролируется через sysctl vm.oom-kill. Но у меня такого нет:

debian@worker-d-3:~$ /usr/sbin/sysctl vm.oom-kill
sysctl: cannot stat /proc/sys/vm/oom-kill: No such file or directory
debian@worker-d-3:~$ ls /proc/sys/vm
admin_reserve_kbytes         dirty_ratio                max_map_count              nr_hugepages              overcommit_ratio          user_reserve_kbytes
block_dump                   dirty_writeback_centisecs  memory_failure_early_kill  nr_hugepages_mempolicy    page-cluster              vfs_cache_pressure
compact_memory               dirtytime_expire_seconds   memory_failure_recovery    nr_overcommit_hugepages   page_lock_unfairness      watermark_boost_factor
compact_unevictable_allowed  drop_caches                min_free_kbytes            numa_stat                 panic_on_oom              watermark_scale_factor
compaction_proactiveness     extfrag_threshold          min_slab_ratio             numa_zonelist_order       percpu_pagelist_fraction  zone_reclaim_mode
dirty_background_bytes       hugetlb_shm_group          min_unmapped_ratio         oom_dump_tasks            stat_interval
dirty_background_ratio       laptop_mode                mmap_min_addr              oom_kill_allocating_task  stat_refresh
dirty_bytes                  legacy_va_layout           mmap_rnd_bits              overcommit_kbytes         swappiness
dirty_expire_centisecs       lowmem_reserve_ratio       mmap_rnd_compat_bits       overcommit_memory         unprivileged_userfaultfd

Видимо гайды устарели. Как правильно проверить? Ядро 5.10.0-20-amd64

В /usr/lib/systemd/ бинарника systemd-oomd тоже нет и сервиса соответствующего тоже нет, если что.

★★★

Ответ на: комментарий от firkax

Я могу открыть консоль (удаленную), ввести username но на этапе где нужно проверить пароль - система зависает, потом пишет что-то про таймаут.

А вообще он завис, когда я там пытался запускать одну жирную программу, поэтому про память это почти гарантированно. Если бы там был своп, я бы вообще не сомневался, но свопа там нет и это меня немного озадачивает, я был уверен, что в такой ситуации ядро будет грохать процессы не стесняясь.

vbr ★★★
() автор топика

Я ещё нашёл настройку vm.admin_reserve_kbytes. Сейчас там 8192. Я так понял, эту память он резервирует для процессов с capability cap_sys_admin. Правда я не понял, какие именно процессы запускаются с этой capability. Может её стоит подкрутить? Мегабайтов на 128, скажем, чтобы был запас хотя бы для ssh?

vbr ★★★
() автор топика
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от vbcnthfkmnth123

Линукс спроектирован с учетом наличия свопа

Неужели нельзя было спроектировать нормальную операционную систему, без кэширования оперативки медленными устройствами?

i_am_not_ai
()

Ядро 5.10.0-20-amd64

Прекрасно, деб 11.

earlyoom вполне отлично сработает.

По поводу самой проблемы:

With or without swap it still freezes before the OOM killer gets run automatically. This is really a kernel bug that should be fixed (i.e. run OOM killer earlier, before dropping all disk cache). Unfortunately kernel developers and a lot of other folk fail to see the problem. Common suggestions such as disable/enable swap, buy more RAM, run less processes, set limits etc. do not address the underlying problem that the kernel’s low memory handling sucks camel’s balls.

The traditional Linux OOM killer works fine in some cases, but in others it kicks in too late, resulting in the system entering a livelock for an indeterminate period.

hakavlad ★★★
()
Ответ на: комментарий от hakavlad

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

Нашёл такой скрипт на просторах интернета, не будет ли он полезным?

while true; do
  if [ "`free -m | head -n2 | tail -n1 | awk '{ print $7 }'`" -lt "${MIN_MEMORY:-100}" ]; then
    echo f > /proc/sysrq-trigger
    echo "Kernel OOM killer invoked."
  fi
  sleep 60
done

Если в двух словах, то когда объём свободной памяти падает ниже заданного значения (например 128 MB), то пишется f в /proc/sysrq-trigger что, как я понимаю, вызывает ядерный oom killer пораньше.

earlyoom смущает тем, что там куча кода на C, который имеет явно логику посложней, чем вышеописанный скрипт и тем, что никто особо не пишет про его применение на сервере. К примеру flant в своём дистрибутиве kubernetes вместо него написали тоже свой костыль, который по большому счёту делает ровно то же, что и скрипт.

vbr ★★★
() автор топика
Последнее исправление: vbr (всего исправлений: 5)
Ответ на: комментарий от vbr

Нашёл такой скрипт на просторах интернета, не будет ли он полезным?

Зачем древние васянские скрипты, если есть проверенные инструменты?

earlyoom уже использовался в дистрибутиве Fedora по умолчанию, написан на С, проверен временем (разрабатывается и активно поддерживается с 2014), по умолчанию мягко завершает процессы сигналом SIGTERM вместо жесткого убийства, конфигурабилен.

hakavlad ★★★
()
Ответ на: комментарий от vbr

там куча кода на C, который имеет явно логику посложней, чем вышеописанный скрипт и тем, что никто особо не пишет про его применение на сервере

На серверах он столь же эффективен. Можно в конфиге указать объём доступной памяти, при котором жирному процессу посылается сигнал (опции -m и -M).

Разультаты можно смотреть в журнале:

sudo journalctl -eu earlyoom.service

Я автор альтернативного решения - https://github.com/hakavlad/nohang - это также есть в репах дебиана.

hakavlad ★★★
()
Ответ на: комментарий от hakavlad

Своп можно выключать, если не нужен.

Так все-таки Chris Down не прав, говоря о важности свопа, В защиту свопа: распространенные заблуждения.

Все же на ЛОРе иногда можно видеть, что именно эту статью приводят в обоснование необходимости использования swap. В обоснование для тех, кто набивает свои компы/сервера огромными объемами в 64/128/256Gb… RAM и сразу же отключают своп (или не включают).

p.s. Цитата для справки о Chris Down:

Hey there! I’m a kernel developer and SRE, primarily working on Linux memory management. I work at Meta as part of the Linux Kernel team, and am responsible for improving the overall reliability and performance of user-facing products from an infrastructure perspective. In general, my drive is in conceiving, designing, and improving systems that make Meta and the wider industry better.

Most of my active work revolves around making operating systems more efficient at scale, developing things like the Linux kernel, cgroups, systemd, and a number of other emerging technologies.

krasnh ★★★
()
General