我强烈鄙视任何类型的自动 OOM 杀手，并希望手动解决此类情况。所以很长一段时间我都
vm.overcommit_memory=1
vm.overcommit_ratio=200
但这样一来，当内存溢出时，系统就会变得无响应。在我的带有 HDD 和 6 GB RAM 的旧笔记本电脑上，有时我不得不等待很多分钟才能切换到文本 VT，发出一些命令并等待它们被执行。这就是为什么我有许多绩效指标来提前注意到这种情况，并且经常收到问题为什么我需要它们。而且它们并不总是有帮助，因为如果当我不在笔记本电脑旁时发生内存溢出，那就太晚了。
我怀疑在配备 SSD 和 12 GB RAM 的新型笔记本电脑上情况会更好，但实际上情况更糟。我有 zRam vm.swappiness=200，它允许高达 16.4 GB 的压缩交换空间，当它几乎耗尽时，系统变得比旧笔记本电脑更加反应迟钝，甚至 VT 开关几乎无法工作，而且我无法 SSH 进入系统从本地网络，所以我唯一的手段是盲目地用 Alt+SysRq+RF 调用内核的手动 OOM，有时会选择杀死重要进程，例如dbus-daemon. 当交换几乎已满时，我可能会创建一个带有声音警报的守护进程，但这又是一个部分权宜之计，因为无论如何我可能都无法及时到达。
过去，我尝试使用 来缓解这种情况thrash-protect。它发送SIGSTOP到贪婪的进程，然后自动SIGCONT-s 它们，这对推迟总锁定并手动解决问题有很大帮助，但在严重过载的情况下，它几乎开始冻结所有内容（尽管可以明确将其列入允许名单）。而且它有很多刺激性的副作用。例如，如果 shell 被冻结，则其子进程在解冻 shell 后可能仍保持冻结状态。如果两个进程共享一条消息总线，并且其中一个进程被冻结，则消息会在总线中快速累积，从而导致 RAM 使用量再次快速增长，或者死机（图形服务器和多进程浏览器尤其容易出现这种情况）。
我尝试sshd以 -20 优先级运行，就像类似问题中所建议的那样，但这并没有真正帮助：它与默认优先级一样无响应。
我想要一些紧急控制台，它始终锁定在 RAM 中，并且无论系统其余部分如何超载，都可以使用。类似于 Windows NT≥6 中的 Ctrl+Alt+Del 屏幕，甚至更好。鉴于可以使用crashkernel参数保留一些 RAM，我将其用于kdump，我怀疑也可以利用此或其他一些内核机制来完成该任务？
