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

С чего ты взял что он завис из-за памяти?

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

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

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

но свопа там нет и

Сделайте. Линукс спроектирован с учетом наличия свопа и без него работает странно.

Нельзя, там кубернетес, он запрещает использовать своп.

Это может быть не оператива, а место на диске или иноды.

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

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

debian@worker-d-3:~$ /usr/sbin/sysctl vm.oom-kill sysctl: cannot stat /proc/sys/vm/oom-kill: No such file or directory

Как там, в 2005?

vm.admin_reserve_kbytes

Это шляпа, она не влияет по умолчанию.

Максимальнт простое решение:

sudo apt install earlyoom

какая версия дебиан, кстати? 10, 11?

https://github.com/rfjakob/earlyoom

не забудь поправить дефолты после установки

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

Нормально он без свопа работает.

Ядро 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.

без кэширования оперативки медленными устройствами?

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

Спасибо. То бишь без юзерспейсного 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 вместо него написали тоже свой костыль, который по большому счёту делает ровно то же, что и скрипт.

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

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

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

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

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

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

sudo journalctl -eu earlyoom.service

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

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

Так все-таки 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.

Крис прав, своп важен. Конечно, можно жить без свопа.