如果我在 shell 中输入x=`yes`，最终我会得到，cannot allocate 18446744071562067968 bytes (4295032832 bytes allocated)因为yes尝试写入x永远，直到内存耗尽。我收到一条消息，cannot allocate <memory>因为内核的 OOM-killer 告诉我xrealloc没有更多的字节可以分配，并且它应该立即退出。
但是，当我game_engine因为资源不足而要求任何人分配更多不存在的图形内存时，它会转向我的 RAM 和 CPU 来分配所请求的内存。
为什么内核的 OOM-killer 没有捕获任何game_engine分配大量内存的尝试，就像它所做的那样x=`yes`？
也就是说，如果我正在运行game_engine并且我的用户自 memory-hog 以来没有生成任何新进程game_engine，为什么 saidgame_engine总是成功地使我的系统陷入无响应、不可恢复的状态，而不会被 OOM-killer 杀死？
我使用游戏引擎作为示例，因为它们往往会在我可怜的小集成卡上分配大量内存，但这似乎发生在许多资源密集型 X 进程中。
是否存在 OOM-killer 无效或无法撤销进程内存的情况？
答案1
事实上，针对 OOM 杀手的最佳解决方案就是不拥有它。将您的系统配置为不使用过度使用的内存，并拒绝使用依赖于它的应用程序和库。在这个无限磁盘的时代，为什么不提供无限的交换呢？除非内存被使用，否则不需要提交交换，对吧？
您的问题的答案可能是 OOM 杀手并不像您想象的那样工作。 OOM 杀手使用启发式方法来选择要终止的进程，并且规则并不总是意味着最后一个请求者会终止。比照。驯服 OOM 杀手。因此，这并不是 OOM 杀手“无效”的问题，而是其中之一做出了与您想要的不同的选择。