Если я ввожу в свой shell x=`yes`, в конечном итоге я получу сообщение cannot allocate 18446744071562067968 bytes (4295032832 bytes allocated), потому что yesпытается писать xвечно, пока не закончится память. Я получаю сообщение, cannot allocate <memory>потому что OOM-killer ядра сообщил, xreallocчто больше нет байтов для выделения, и что он должен немедленно завершиться.
Но когда я прошу кого-либо game_engineвыделить больше графической памяти, которой нет из-за нехватки ресурсов, он обращается к моей оперативной памяти и процессору, чтобы вместо этого выделить запрошенную память.
Почему OOM-killer ядра никогда не отлавливает game_engineпопытки выделить тонны памяти, как это происходит с x=`yes`?
То есть, если я работаю game_engine, а мой пользователь не создал ни одного нового процесса с момента memory-hog game_engine, почему said game_engineвсегда успешно доводит мою систему до состояния невосприимчивости и необратимого краха, без того, чтобы OOM-killer ее убил?
Я использую игровые движки в качестве примера, потому что они, как правило, выделяют тонны памяти на моей бедной маленькой интегрированной карте, но это, похоже, происходит со многими ресурсоемкими процессами X.
Существуют ли случаи, когда OOM-killer неэффективен или не способен отозвать память процесса?
решение1
На самом деле, лучшее решение для OOM killer — не иметь его. Настройте свою систему так, чтобы она не использовала перераспределённую память, и откажитесь от использования приложений и библиотек, которые зависят от неё. В этот день бесконечного диска, почему бы не предоставить бесконечный swap? Не нужно брать на себя обязательства по swap, если память не используется, верно?
Ответ на ваш вопрос может быть в том, что OOM killer не работает так, как вы думаете. OOM killer использует эвристику для выбора процесса, который нужно убить, и правила не всегда означают, что последний запросчик умирает. Ср.Укрощение убийцы OOM. Так что дело не в том, что убийца ООМ «неэффективен», а в том, что он делает выбор, отличный от того, который вам бы хотелось.