我与 HAL 共享一个服务器。服务器有 32 GB 内存。
我很少使用超过 1 GB 的内存,当我使用时,每次使用几分钟,而且我不介意将此类作业发送到后面。
HAL 读/写大文件(例如使用 gunzip)。这可能会间歇性地占用多达 100% 的内存CPU 数小时。这通常是在一夜之间完成的,但在运行时,即使是简单的命令,例如cd
take 30s,打开emacs
也可能需要几分钟。
我希望能够保留 1 GB 供使用 << 1GB 的进程使用(如文本编辑器)。我也想远离 HAL,并且没有理由认为这应该是一个问题。
HAL 说排队系统(如 PBS)不能用于将读/写的优先级设置为低,例如,在大型作业运行时始终保留 1 GB 内存可用。用他的话来说:
用于 gunzip 的脚本会阻塞所有处理器,因为数据很大......排队无法解决这个问题......在从(该服务器)到(该服务器)的文件传输期间,膨胀步骤会进行大量读取/写
为什么排队不能解决这个问题?什么可以?
Bob 读/写大文件(例如使用 gunzip)。这可能会间歇性地占用多达 100% 的内存数小时。这通常在一夜之间完成,但在运行时,即使是简单的命令,例如 cd 也需要 30 秒,打开 emacs 可能需要几分钟。
首先gzip
,gunzip
不要像你想象的那样工作——gzip 使用的算法是基于块的,虽然在处理大型压缩文件时它可能会稍大一些,即使解压缩 1GB .gz 文件也只会占用大约 15M 的 RAM。 (总进程大小)在我的机器上。
其次,除非您将整个文件吸入 RAM ,否则只是读取或写入大文件不会占用太多内存 - 操作系统可能会将数据保存在文件系统缓存中,但缓存数据将在程序需要时被逐出内存。只有保存在程序工作内存中的数据才计入“内存压力”(使用的 RAM,加上或减去一些其他因素)。
我希望能够保留 1GB 供使用 << 1GB 的进程使用(如文本编辑器)。我也想远离鲍勃,并且认为没有理由这应该是一个问题。
不要试图超越操作系统的寻呼机:内核将交换任务以确保当前正在执行的任何人都有可以工作的 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 中交换是,通过必要性,甚至比在裸机上还要慢)。
在现实世界中,杰夫可能是正确的-你可能触及磁盘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 作业。(常见问题解答)
如果这是一个实际的现实问题,那么我很抱歉 - 您可能是在生产环境中实际遇到这种极端情况的万分之一。
归档时间: |
|
查看次数: |
258 次 |
最近记录: |