как заставить oom killer убивать процессы до того как система намертво повиснет при нехватке памяти?
2 пути:
Патч ядра, обеспечивающий запрет вытеснения файловых страниц из памяти при нехватке памяти — https://github.com/hakavlad/le9-patch
При применении патча OOM killer приходит быстро и без заморогки гуя. Демо — https://youtu.be/iU3ikgNgp3M — открытие вкладок хрома, MemTotal=2.3G, пространства подкачки нет. Вкладки падают, заморозки нет. В этом видео повторяется известный опыт Артема С. Ташкинова — https://lkml.org/lkml/2019/8/4/15.
memavaild — поддерживает некоторый обем доступной памяти при активном своппинге путем вытеснения в своп памяти user.slice и system.slice, это приводит к поддержанию некоторого объема файлового кэша, и thrashing уменьшается https://github.com/hakavlad/memavaild.
Таким образом, с применением специальных средств в Linux можно добиться отличной обработки нехватки памяти.
Проблема в том, что большинство дистрибутивов не используют лучшие практики. Только недавно началось внедрение свопа на zram по умолчанию и использование юзерспейсных OOM киллеров.
В earlyoom в Fedora используются нестандартные настройки и порог доступной памяти 4%, но не более 400 MiB. [1]
Эта проблема была озвучена при обсуждении включения earlyoom по умолчанию, и решена при содействии апстрима — теперь можно указывать два порога (абсолютный в KiB и относительный в %), и применяется меньший порог.
В конце концов, пользователь может изменить дефолты и выбрать любой другой порог.
3 гигабайта оперативы будет уходить впустую
Они будут заняты страничным кэшем, скорее всего. Запас кэша позвлоляет быстрее восстановить отзывчивость после корректирующего действия.
3. Если кончится оперативная память, всё повиснет.
Проблема решается установкой обработчика нехватки памяти: github.com/hakavlad/nohang#solution. В Fedora 32 Workstation по умолчанию включен earlyoom, и проблема не возникает.
8. Хочешь интеграцию приложений с «проводником»?
Skype у меня интегрирован с Dolphin, есть пункт «Поделиться в Skype», например. Таким образом, интеграция возможна при желании.
9. Ctrl+F4 чтобы закрыть окно внутри приложения? Забудь, нет такого в линуксе.
У меня в Debian Mate это из коробки прекрасно работает. Не «в линуксе нет», а в дефолтной версии одного из окружений рабочего стола.
Простое и логичное управление памятью и нехваткой памяти.
В Linux вы можете его получить путем выставления vm.overcommit_memory=2, и киллер не придет: процессы сами будут падать на cannot allocate memory, без всякого киллера, причем падать будет не самые большие по потреблению памяти, а именно те, которые запрашивают выделение. Вот пример: жирный процесс выделяет память, но обрабатывает ошибки выделения и пытается продолжить работу. В итоге падают маленькие процессы, котрые не обрабатывают ошибки выделения. Вот скриншоты такого — процессы getty падают без вмешательства киллера. Возможно ли подобное в *BSD?
2 пути:
При применении патча OOM killer приходит быстро и без заморогки гуя. Демо — https://youtu.be/iU3ikgNgp3M — открытие вкладок хрома, MemTotal=2.3G, пространства подкачки нет. Вкладки падают, заморозки нет. В этом видео повторяется известный опыт Артема С. Ташкинова — https://lkml.org/lkml/2019/8/4/15.
Появились новые способы.
uresourcedрезервирует некоторый обем памяти для GUI, начал поставляться с Fedora 33 https://fedoraproject.org/wiki/Changes/Reserve_resources_for_active_user_WS.prelockd— блокирует в памяти бинари и либы, в том числе иксов и оконных менеджеров https://github.com/hakavlad/prelockd.memavaild— поддерживает некоторый обем доступной памяти при активном своппинге путем вытеснения в своп памятиuser.sliceиsystem.slice, это приводит к поддержанию некоторого объема файлового кэша, и thrashing уменьшается https://github.com/hakavlad/memavaild.Демо:
https://youtu.be/QquulJ06dAo — играем в supertux на фоне 12 потоков быстрых пожирателей памяти
tail /dev/zero.https://youtu.be/nSCT_zZHYYQ — playing superux + compiling Linux 5.4 with make -j512, MemTotal=9.6G
https://youtu.be/X1wsgWOE-Tk —
while true; do (tail /dev/zero &); done— гуй жив.Таким образом, с применением специальных средств в Linux можно добиться отличной обработки нехватки памяти.
Проблема в том, что большинство дистрибутивов не используют лучшие практики. Только недавно началось внедрение свопа на zram по умолчанию и использование юзерспейсных OOM киллеров.
Эта проблема была озвучена при обсуждении включения earlyoom по умолчанию, и решена при содействии апстрима — теперь можно указывать два порога (абсолютный в KiB и относительный в %), и применяется меньший порог.
В конце концов, пользователь может изменить дефолты и выбрать любой другой порог.
Они будут заняты страничным кэшем, скорее всего. Запас кэша позвлоляет быстрее восстановить отзывчивость после корректирующего действия.
[1] src.fedoraproject.org/rpms/earlyoom/blob/master/f/earlyoom-fedora-options.patch#_21
Проблема решается установкой обработчика нехватки памяти: github.com/hakavlad/nohang#solution. В Fedora 32 Workstation по умолчанию включен earlyoom, и проблема не возникает.
Skype у меня интегрирован с Dolphin, есть пункт «Поделиться в Skype», например. Таким образом, интеграция возможна при желании.
У меня в Debian Mate это из коробки прекрасно работает. Не «в линуксе нет», а в дефолтной версии одного из окружений рабочего стола.
В Linux вы можете его получить путем выставления vm.overcommit_memory=2, и киллер не придет: процессы сами будут падать на cannot allocate memory, без всякого киллера, причем падать будет не самые большие по потреблению памяти, а именно те, которые запрашивают выделение. Вот пример: жирный процесс выделяет память, но обрабатывает ошибки выделения и пытается продолжить работу. В итоге падают маленькие процессы, котрые не обрабатывают ошибки выделения. Вот скриншоты такого — процессы getty падают без вмешательства киллера. Возможно ли подобное в *BSD?
Еще вопросы:
Есть ли в *BSD аналоги zram и zswap?
Есть ли в *BSD аналог PSI?
Как в *BSD обстоят дела с поддержкой иерархии контрольных групп? Есть ли аналоги cgroup в *BSD?