Убийца OOM не работает должным образом, приводит к зависанию ОС
Согласно standard.freedesktop.org , запись TryExec принимает следующее:
Путь к исполняемый файл на диске, используемый для определения того, действительно ли установлена программа. Если путь не является абсолютным, файл ищется в переменной среды $ PATH. Если файл отсутствует или не является исполняемым, запись может быть проигнорирована (например, не может использоваться в меню).
Спецификация автозапуска настольных приложений гласит:
Файл .desktop с непустым полем TryExec НЕ ДОЛЖЕН запускаться автоматически, если значение ключа TryExec НЕ совпадает с установленной исполняемой программой.
В отличие от Exec и, несмотря на похожее имя, TryExec на самом деле не выполняет свое значение.
Я нашел два объяснения (одного и того же )того, почему kswapd0 выполняет постоянное чтение диска происходит задолго до того, как OOM -убийца убивает нарушителя процесс:
- см. ответ и комментарий этого ответа askubuntu SE
- см. ответ и комментарии Дэвида Шварца к этому ответу на unix SE
Я процитирую здесь комментарий из 1., который действительно открыл мне глаза на то, почему у меня постоянно читается диск, когда все заморожено:
For example, consider a case where you have zero swap and system is nearly running out of RAM. The kernel will take memory from e.g. Firefox (it can do this because Firefox is running executable code that has been loaded from disk - the code can be loaded from disk again if needed). If Firefox then needs to access that RAM again N seconds later, the CPU generates "hard fault" which forces Linux to free some RAM (e.g. take some RAM from another process), load the missing data from disk and then allow Firefox to continue as usual. This is pretty similar to normal swapping and kswapd0 does it. – Mikko Rantalainen Feb 15 at 13:08
Если у кого-нибудь есть способ, как отключить это поведение (, возможно, перекомпилировать ядро с какими параметрами? ), пожалуйста, дайте мне знать как можно скорее! Очень признателен, спасибо!
ОБНОВЛЕНИЕ:Единственный способ, который я нашел до сих пор, это исправление ядра, и он работает для меня с отключенным свопом (, т.е.CONFIG_SWAP is not set)но не работает для других с включенным свопом кажется ; см. патч внутри этого вопроса.
Параметр memory.minв контроллере памяти cgroups-v2должен помочь.
А именно, приведу цитату:
Hard memory protection. If the memory usage of a cgroup is within its effective min boundary, the cgroup’s memory won’t be reclaimed under any conditions. If there is no unprotected reclaimable memory available, OOM killer is invoked.
Источник:https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html
Утилита EarlyOOM является практическим решением этой проблемы.https://fedoraproject.org/wiki/Changes/EnableEarlyoom
Эта утилита будет отслеживать использование памяти и уничтожать крупных потребителей до того, как общее использование памяти превысит настраиваемый порог (, например. 95% ).
Он упакован для Arch Linux в пакет earlyoom, который поставляется с сервисом systemd, так что вы можете быстро настроить его:
pacman -S earlyoom
systemctl enable earlyoom
systemctl start earlyoom
Я использую его в течение нескольких недель, и это ночь -и -разница в день :система больше не зависает, несмотря на доведение системы до предела с помощью нескольких приложений, потребляющих память (Java, Electron и браузеры ). Я не был свидетелем того, как он убивает неправильный процесс, что, я полагаю, может произойти теоретически. Возможно, это неразрешимая проблема в теории, так как в Интернете было написано так много объяснений по этому поводу, но на практике простая эвристика работает очень хорошо.