是否可以对进程的内存消耗施加某种软限制？

我认为这并不是一个不常见的问题：一个进程分配大量的内存（这是由于内存泄漏错误所致，因为您尝试处理不可行的大输入文件，或其他原因）。RAM已满，并且在某些时候Linux必须切换到交换。好吧，有时候这只是最后的选择：如果我要进行昂贵的计算，如果快要用完RAM了，我不想丢失数据。

但是（以我的经验）更常见的是，内存消耗不受无赖（可能是错误的）过程的限制。就是说，我不仅要交换一些不那么急需的数据，而且操作系统不得不紧急交换数据负载。不幸的是，这不仅严重破坏了令人讨厌的过程，而且可能使整个系统陷入停顿（在装有SSD的计算机上，情况已经不再那么糟糕了，但是OTOH让我担心是否要写入数千兆字节的垃圾数据）。长期损害闪存）。
直到我发现问题并手动终止进程（实际上甚至要花几分钟才能让我自己登录到虚拟终端！），我一半的运行会话仍处于交换状态，我需要等待相当长的一段时间，直到系统运行平稳再次。

解决这个问题的方法很简单：强制执行硬内存限制。但是在整个系统范围内进行操作有时会杀死我本来仍然需要的进程，如果ulimit在启动有问题的进程之前必须手动进行操作……那么，我常常会忘记直到为时已晚。

我可能更喜欢的解决方案：

• 如果有任何进程超出了一定的内存使用量，则会人为地限制它，以便系统的其余部分保持响应。
• 如果有任何进程超出了一定的内存使用量，那么它将被SIGSTOPping，因此我有时间弄清楚下一步该怎么做。
• 如果进程接近RAM限制，那么在进行大容量交换之前，我会收到警告。

有什么办法可以得到这样的行为，或者类似的？

niceload --noswap yourprg正是针对这种情况：它着眼于交换活动：

• 如果换出：让进程运行
• 如果交换：让进程运行
• 如果进出交换：挂起进程直到交换停止，并在交换停止后恢复该进程

它不会在交换开始之前暂停该过程，而是让交换运行1秒钟后再执行操作。

niceload --mem 1G yourprg工作原理类似：如果少于1GB的可用空间，则将暂停。当超过1GB可用空间时，将恢复yourprg。

是。几乎任何现代外壳都可以轻松实现。

sh -c 'ulimit -S -m "$1"
       shift; exec your_command "$@"
' -- some_size args

您可以将-l选项用于锁定的内存限制。如果超出限制，将向您发出信号。

Cronjob清除缓存：如何在Linux中清除内存缓存

我实际上也有类似的问题。我有一堆运行自己的自定义脚本的用户，每隔一段时间，他们的脚本会消耗所有可用内存并关闭redhat服务器。大量消耗RAM的原因是，它们的脚本仅在等待事件时就可以运行数天，从而在实际上不使用任何资源的情况下占用资源。因此，我所做的只是简单地用cronjob强制清除了缓存，此后就再也没有问题了。

简单而懒惰。