我与 HAL 共享一台服务器。该服务器有 32 GB 内存。
我很少使用超过 1 GB 的内存，即使使用，每次也只用几分钟，而且我也不介意将这样的作业排在队伍的后面。
HAL 读取/写入大型文件（例如使用 gunzip）。这最多可能占用 100% 的记忆CPU 间歇性地占用数小时。这通常是在夜间完成的，但在运行时，即使是简单的命令（例如cd打开）也需要 30 秒，emacs可能需要几分钟。
我希望能够保留 1 GB 供使用 << 1GB 的进程使用（例如文本编辑器）。我还想避开 HAL 的干扰，而且我认为这不会成为问题。
HAL 表示，排队系统（如 PBS）不能用于将读/写优先级设置为低，例如，在运行大型作业时始终留出 1 GB 内存可用。用他的话来说：
用于 gunzip 的脚本占用了所有处理器，因为数据太大了……排队不能解决这个问题……在将文件从（那个服务器）传输到（这个服务器）的过程中，膨胀步骤会进行大量的读/写操作
为什么排队不能解决这个问题？什么可以？
答案1
答案2
Bob 读取/写入大型文件（例如使用 gunzip）。这可能会间歇性地占用高达 100% 的内存，持续数小时。这通常在夜间完成，但在运行时，即使是简单的命令（例如 cd）也需要 30 秒，打开 emacs 可能需要几分钟。
首先gzip，gunzip它的工作方式与你想象的不同——gzip 使用的算法是基于块，虽然在处理大型压缩文件时可能会稍微大一些，但即使解压 1GB 的 .gz 文件，在我的计算机上也只会占用大约 15M 的 RAM（总处理大小）。
第二，除非你吸全部的将文件放入 RAM 中，简单地读取或写入大型文件不会占用太多内存 - 操作系统可能会将数据保存在文件系统缓存中，但当程序需要该 RAM 时，缓存数据将被清除。只有保存在程序工作内存中的数据才会计入“内存压力”（已用 RAM，加上或减去一些其他因素）。
我希望能够保留 1GB 供使用<< 1GB 的进程使用（例如文本编辑器）。我还想避开 Bob，而且我认为这不会成为问题。
不要再试图超越操作系统的分页程序：内核将交换任务以确保当前正在执行的任务有 RAM 可供使用。是的，这意味着如果您使用的 RAM 超过可用 RAM，您将会占用磁盘空间。解决方案是通过运行更少的程序或添加更多 RAM 来限制您使用的 RAM 量。
从操作系统设计的角度来看，“保留” RAM 的概念从根本上就是有缺陷的：您可能没有其他活动在进行，但 Bob 的程序无法触及“保留”的 RAM，因此现在它必须转到磁盘进行交换。由于缺少（例如）1KB，Bob 的程序现在不断进行磁盘访问，将数据分页进出 RAM，您的性能就会下降。
你可以人为地限制 Bob 的 RAM 使用量（ulimit），但是当他达到硬限制时，他的程序可能不会做出良好反应（想想：malloc(): Unable to allocate XXXXX bytes随后会非正常退出）。
正如 rvs 在其评论中提到的那样，您可以虚拟化环境并确保 Bob 的进程只能访问其 VM 可用的资源，但这只会转移问题（Bob 的 VM 将开始交换，而在 VM 中交换必然比在裸机上更慢）。
在现实世界中，Jeff 可能是正确的 - 你可能遇到的是磁盘 IO 限制，而不是 RAM 限制：解压缩文件是巨大的磁盘 I/O 量（从压缩文件读取，通过 CPU 和少量 RAM，将其吐出到未压缩的文件中）。nice（影响 CPU 优先级）并且ionice如果支持（影响磁盘优先级）将缓解您的问题。
演讲
并非毫无意义，但我从我的操作系统设计教科书中回忆起同样的问题（尽管示例不是 gzip/gunzip）。虽然您在现实世界中遇到这个问题的可能性很小，但我对此表示怀疑：这只是一个过于牵强的例子。
请记住Server Fault is for system administrators and desktop support professionals, people who manage or maintain computers in a professional capacity- 不适合 CS/301 家庭作业。（常问问题）
如果这是现实世界中实际存在的问题，那么我深表歉意——您可能是在生产环境中真正遇到这种极端情况的 10000 分之一的人。