Linux диск OOM ввод-вывод. Также: подкачка, для чего это хорошо?
человек находит
- mmin
Данные файла были в последний раз изменены несколько n минуты назад.
Реальный вопрос, почему Вы работаете без подкачки? Особенно, если Вы видите (серьезные) проблемы производительности, связанные с исчерпыванием RAM? Вы знаете, что не имеющая подкачка может на самом деле сделать Вашу систему медленнее, правильно?
Очевидное решение состоит в том, чтобы добавить некоторую область подкачки и не иметь Ваше системное дерьмо на Вас. Рассматривая, как дешевое дисковое пространство, я не могу думать ни о каком общем situations1, где необходимо когда-либо создавать систему без подкачки.
Относительно ответа на Ваш вопрос, я не помню все детали низкого уровня о том, почему подкачка важна даже в системах, куда Вы не собираетесь исчерпывать память, но были аргументы в списке рассылки Ядра Linux о том, разумно ли выполнить системы без подкачки (и не было большого количества окончательных ответов). Общее согласие состоит в том, чтобы обычно всегда иметь подкачку и корректировать swapiness по мере необходимости.
Кроме того, я думаю, что Вы неправильно понимаете некоторые важные протесты относительно уничтожителя OOM Linux. В первую очередь, доверие ему для обработки Вашего Из Проблем памяти является Очень Плохой Идеей (TM). Это может быть очень неразборчиво о том, что это уничтожает, и совершенно возможно, что Вас оставят с нестабильной или даже неприменимой системой. Да, это пытается уничтожить недавние процессы, которые едят большую память (незначительная гарантия, чтобы попытаться поймать убежавший процесс), но нет никаких гарантий. Я видел, что он уничтожает ssh, уничтожьте процессы Xen (на Xen виртуальный хост-сервер, заставив VMs отказать), и в одном случае это уничтожило NFS.
Что касается IO... Я не знаю наверняка, что вызвало бы его. Возможно, файловая система или связанный с диском процесс были уничтожены? Возможно, процесс имеет своего рода "кэш к диску" функциональность, встроенная, когда это не может выделить достаточно памяти?
Другое примечание, если это - рабочий стол, подкачка, требуется для, Приостанавливают к Диску. Если это - сервер, полагаться на OOM никогда не является хорошей идеей, поскольку это ставит под угрозу устойчивость на, ну, в общем, никаком серьезном основании вообще.
[1] Встроенные системы о единственном очевидном исключении, и они не особенно распространены (и если Вы имеете дело со встроенными системами, Вы уже собираетесь быть знающий о требованиях).
I think AndreasM has hit it on the head (the reason for the disk going all thrashy.) Executables are demand paged -- so in normal operation you will have nearly all of your executables nad libraries sitting in good ol' physical RAM. But when RAM runs low, but not low enough for the out-of-memory killer to be run, these pages are evicted from RAM. So you end up with a situation where pages are evicted -- at first, no problem, because they are evicted least-recently-used first and it kicks out pages you aren't using anyway. But then, it kicks out the ones you are using, just to have to page them right back in moments later. Thrash city.
Basically, if something used just a bit more RAM, you probably would have the OOM killer kick in but you weren't there yet. As a few have said, OOM killer is indiscriminate, it's really more of a last resort to avoid a kernel panic than something you should consider to use in normal operation. If you have some custom setup, I'd consider writing up some daemon to monitor free memory, and kill using the policy of your choosing when it approaches full.