OOM killer не работает должным образом, приводит к зависанию ОС

В течение многих лет OOM убийца моей операционной системы не работает должным образом и приводит к зависанию системы.
Когда использование памяти очень велико, вся система имеет тенденцию «зависать» (на самом деле: становиться очень медленной) в течение нескольких часов или даже дней , вместо того, чтобы убивать процессы для освобождения памяти.
Максимум, что я записал, составляет 7 дней до того, как я смирился с необходимостью выполнить сброс.
Когда OOM собирается быть достигнутым, Iowait очень очень высок (~ 70%), прежде чем стать неизмеримым.
Инструмент: iotopпоказал, что каждая программа читает с очень высокой пропускной способностью (на десятки МБ / с) с моего жесткого диска.
Что эти программы читают?
- иерархия каталогов?
- сам исполняемый код?
Я не совсем сейчас.

[отредактировано] В то время, когда я писал это сообщение (в 2017 году), я использовал обновление ArchLinux (4.9.27-1-lts), но уже сталкивался с этой проблемой в течение многих лет.
У меня возникла та же проблема с различными дистрибутивами Linux и различными конфигурациями оборудования.
В настоящее время (2019) я использую обновленную версию Debian 9.6 (4.9.0), у меня 16 ГБ физического ОЗУ, твердотельный накопитель, на котором установлена моя ОС, а не раздел подкачки .

Из-за количества оперативной памяти, которую я имею, я не хочу включать раздел подкачки, так как это только задержит появление проблемы.
Кроме того, слишком частая замена SSD может потенциально сократить срок службы диска.
Кстати, я уже пробовал с разделом подкачки и без него, оказалось, что он только задерживает появление проблемы, но не является решением.

Для меня проблема вызвана тем фактом, что Linux удаляет важные данные из кэшей , что приводит к зависанию системы, потому что она должна читать все, каждый раз с жесткого диска.

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

Я пробовал несколько вещей в надежде решить эту проблему.
Один из них был установить , /proc/sys/vm/min_free_kbytesчтобы 1000000(1 GB).
Поскольку этот 1 ГБ должен оставаться свободным, я думал, что эта память будет зарезервирована Linux для кэширования важных данных.
Но это не сработало.

Кроме того, я считаю полезным добавить, что, даже если теоретически это звучит великолепно, ограничение размера виртуальной памяти размером физической памяти, определяя, /proc/sys/vm/overcommit_memoryчто 2это не является технически приемлемым в моей ситуации, потому что тип приложений что я использую, требуют больше виртуальной памяти, чем они эффективно используют по ряду причин.
Согласно файлу /proc/meminfo, это Commited_ASзначение часто выше, чем удвоенное значение физической памяти в моей системе (16 ГБ, Commited_AS часто> 32 ГБ).

У меня возникла эта проблема с /proc/sys/vm/overcommit_memoryее значением по умолчанию: 0и некоторое время я определял ее как:, 1потому что я предпочел, чтобы программы были убиты OOM-убийцей, а не вели себя неправильно, потому что они не проверяют возвращаемые значения, mallocкогда ассигнования отказываются.

Когда я говорил об этой проблеме в IRC , я встречал других пользователей Linux, которые сталкивались с той же самой проблемой, поэтому я думаю, что многие пользователи обеспокоены этим.
Для меня это неприемлемо, поскольку даже Windows лучше справляется с высоким использованием памяти.

Если вам нужна дополнительная информация, есть предложение, пожалуйста, сообщите мне.

Документация:
https://en.wikipedia.org/wiki/Thrashing_%28computer_science%29
https://en.wikipedia.org/wiki/Memory_overcommitment
https://www.kernel.org/doc/Documentation/sysctl/vm. txt
https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
https://lwn.net/Articles/317814/

Они говорят об этом:
почему Linux-убийца без памяти (OOM) не запускается автоматически, а работает на sysrq-key?
Почему OOM-killer иногда не может убить боровов с ресурсами?
Предварительная загрузка OOM Killer
Можно ли запустить OOM Killer при принудительной замене?
Как избежать высокой задержки в ситуации с OOM?
https://lwn.net/Articles/104179/
https://bbs.archlinux.org/viewtopic.php?id=233843

— M89
источник

Я думаю, что это то, что вы должны ожидать, если вы бьетесь, но на самом деле вы не приближаетесь к 100% «использованию», то есть слишком много использования памяти, которое поддерживается файлами, считается как «buff / cache». (Тьфу, эта фраза предполагает, что ваши распределения tmpfs тривиальны, так как они отображаются как «buff / cache», но не могут быть перенесены на физическую файловую систему). min_free_kbytesне актуально, это не резерв для кэшированных страниц. AFAICT, ни один из vm sysctls не позволяет резервировать какую-либо память специально для кэшированных страниц, то есть ограничивать выделение MAP_ANONYMOUS :(.

— sourcejedi

Я искал решение этой проблемы уже много лет, но безуспешно. Я полагаю, что впервые заметил проблему после замены моего жесткого диска на SSD, что также повлекло за собой полное отключение подкачки, но я не могу гарантировать, что это никогда не происходило до этих изменений, поэтому это может быть не связано. Я на Archlinux, кстати.

— brunocodutra

Я только что опубликовал на форумах Arch Linux об этом.

— Игнат Инсаров

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

— M89

Это помогло, когда chrome удалось просочиться через всю мою оперативную память ... (Хотя я в конечном итоге также добавил реальный раздел подкачки диска и в итоге обновил до приличного объема оперативной памяти)

— Герт ван ден Берг

Ответы:

Я нашел два объяснения (одного и те же), почему ~~kswapd0 делает~~ чтение постоянного диска происходит задолго до того, ОАЯ-убийца убивает процесс обижая:

см. ответ и комментарий к этому ответу аскубунту SE
см. ответ и комментарии Дэвида Шварца к этому ответу на Unix SE

Я процитирую здесь комментарий от 1., который действительно открыл мне глаза на то, почему я получал постоянное чтение с диска, пока все было заморожено :

Например, рассмотрим случай, когда у вас нулевой своп, и системе почти не хватает ОЗУ. Ядро будет извлекать память, например, из Firefox (это можно сделать, потому что Firefox запускает исполняемый код, который был загружен с диска - код может быть загружен с диска снова, если это необходимо). Если затем Firefox необходимо снова получить доступ к этой ОЗУ через N секунд, ЦП генерирует «серьезный сбой», который вынуждает Linux освободить часть ОЗУ (например, извлечь часть ОЗУ из другого процесса), загрузить недостающие данные с диска и затем позволить Firefox продолжить работу как обычный. Это очень похоже на обычный обмен, и kswapd0 делает это. - Микко Ранталайнен 15 февраля в 13:08

Если у кого-то есть способ отключить это поведение (возможно, перекомпилировать ядро с какими опциями? ), Пожалуйста, дайте мне знать как можно скорее! Высоко ценится, спасибо!

ОБНОВЛЕНИЕ: единственный способ, который я нашел до сих пор, - это исправление ядра, и оно работает для меня с отключенным свопом (т.е. CONFIG_SWAP is not set), но не работает для других с активированным свопом, кажется ; посмотрите патч внутри этого вопроса.

Пожалуйста, удалите недопустимый текст. Не отмечайте правки с помощью «РЕДАКТИРОВАТЬ» в тексте. Они очевидны из истории пересмотра .

— Кусалананда

@Kusalananda Этот пользователь должен поощряться, так как он, вероятно, является тем, кто внес наибольший вклад.

— M89

@Kusalananda Я думал, что важно сохранить их, чтобы другие могли видеть, что (еще) пытались и не работали. Возможно, UPDATEвместо этого EDITбыло бы лучше?

@MarcusLinsner Нет, извините, вы неправильно поняли. Показывать то, что вы пробовали, - это то, что вы делаете, когда задаете вопрос. Ответ должен быть правильным на вопрос , как это в настоящее время поставлено. Я имею в виду, что одно редактирование даже просит читателя игнорировать предыдущие изменения . Если кому-то интересно посмотреть историю редактирования, вы можете увидеть ее здесь .

— Кусалананда

memory.minПараметр в cgroups-v2памяти контроллера должно помочь.

А именно, позвольте мне процитировать:

Жесткая защита памяти. Если использование памяти cgroup находится в пределах ее эффективной минимальной границы, память cgroup не будет восстановлена ни при каких условиях. Если нет доступной незащищенной доступной памяти, вызывается OOM killer.

Источник: https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html.

— Владимир Никишкин
источник

Не могли бы вы уточнить, пожалуйста? Ваш ответ немного отстает в ответе на вопрос ОП.

— Парадокс