我与HAL共享服务器。 该服务器有32 GB的内存。
我很less使用超过1 GB的内存，而当我这样做的时候，一次只需几分钟，我不介意把这样的工作交给后面的人。
HAL读/写大文件（例如使用gunzip）。 这可能会占用内存 CPU的100％，间歇性地持续数小时。 这通常是在一夜之间完成的，但是运行时，甚至可以使简单的命令（如cd花费30秒，打开emacs可以花费几分钟。
我希望能够保留1 GB的使用<< 1GB（如文本编辑器）的进程使用。 我也想避开HAL的方式，没有理由认为这是一个问题。
HAL说排队系统（比如PBS）不能用来把读/写的优先级降低，例如当大工作正在运行时总是保留1GB的内存。 用他的话说：
用于gunzip的脚本阻塞了所有的处理器，因为数据很大……排队不会解决这个问题…在从（服务器）传输文件到（这个服务器）的过程中，通货膨胀步骤会执行大量的读/写
为什么不能排队解决这个问题？ 什么可能？
你可以有一个工作排队系统或修改内核的调度方法。
我会忽略这些选项，并build议您使用ionice – 或者更具体地说，Bob使用它来降低他的优先级。 这听起来像你有一个磁盘访问问题，而不是内存问题。
常规的好也可能是一个选项，因为它会间接影响磁盘优先级（从ionice手册页： “尽力而为类中的优先级将从进程的CPU优良级dynamic派生：io_priority =（cpu_nice + 20）/ 5.“ ） 上面的软件也很容易得到什么是瓶颈，如果它是常规的IO或交换到问题的磁盘的概述。
鲍勃读/写大文件（例如使用gunzip）。 这可能会占用100％的内存，间歇性的，几个小时。 这通常是在一夜之间完成的，但是运行时，甚至可以使简单的命令（如cd）花费30秒，打开emacs可以花费几分钟。
第一个gzip和gunzip并不像你认为的那样工作 – gzip使用的algorithm是以块为基础的 ，而当通过一个大的压缩文件，即使解压缩一个1GB的.gz文件时，它可能会略微大一点，只能嚼碎大约15M RAM（总进程大小）在我的机器上。
其次，除非将整个文件吸入RAM，否则只需读取或写入大文件就不会消耗太多内存 – 操作系统可能会将数据保存在文件系统caching中，但caching数据将在程序需要内存。 只有在程序工作存储器中保存的数据才会计入“内存压力”（使用的RAM，加上或减去一些其他因素）。
我希望能够保留1GB的使用<< 1GB（如文本编辑器）的进程使用。 我也想避开鲍勃的方式，没有理由认为这应该是一个问题。
停止试图超越你的操作系统的寻呼机：内核将交换任务，以确保当前正在执行的任何人都有RAM在其中工作。 是的，这意味着如果你使用的RAM超过了你的可用空间，你将会碰到磁盘。 解决方法是通过运行较less的程序来限制您使用的RAM数量，或者添加更多的RAM。
从操作系统devise的angular度来看，“预留”内存的概念是根本上的缺陷：你可能没有其他的活动，但是鲍勃的程序不能触及“保留的”内存，所以现在必须去换磁盘了。 对于（例如）1KB的需求，Bob的程序现在正在不断的将磁盘命中数据进出RAM，而且你的性能也是如此。
你可以人为地限制Bob的内存使用量（ ulimit ），但是当他遇到硬性限制时，他的程序可能不会反应良好（想想： malloc(): Unable to allocate XXXXX bytes然后是不正常退出）。
您可以像他们的评论中提到的rvs一样虚拟化环境，并确保Bob的进程只能访问其虚拟机可用的资源，但这只是简单地移动了问题（Bob的VM将开始交换，并且在VM中交换甚至比裸机还要慢）。
在现实世界中，Jeff可能是正确的 – 你可能达到了磁盘IO限制，而不是内存限制：解压缩文件是大量的磁盘I / O（从压缩文件中读入，通过CPU传递，一点RAM，把它吐出来解压缩文件）。 nice （影响CPU优先级），如果支持（影响磁盘优先级） ionice将缓解您的问题。
演讲
不是没有，但我从我的操作系统devise教科书回忆同样的问题（虽然这个例子不是gzip / gunzip）。 虽然现实世界中遇到这个问题的机会渺茫，但我还是怀疑：这只是一个例子。
请记住， Server Fault is for system administrators and desktop support professionals, people who manage or maintain computers in a professional capacity – 不适用于CS / 301作业（ FAQ ）
如果这是一个实际的现实问题，那么我很抱歉 – 在生产环境中，您实际上可能遇到了这种情况。