可以将读/写作业放入队列吗?

Dav*_*uer 3 redhat queue pbs

我与 HAL 共享一个服务器。服务器有 32 GB 内存。

我很少使用超过 1 GB 的内存,当我使用时,每次使用几分钟,而且我不介意将此类作业发送到后面。

HAL 读/写大文件(例如使用 gunzip)。这可能会间歇性地占用多达 100% 的内存CPU 数小时。这通常是在一夜之间完成的,但在运行时,即使是简单的命令,例如cdtake 30s,打开emacs也可能需要几分钟。

我希望能够保留 1 GB 供使用 << 1GB 的进程使用(如文本编辑器)。我也想远离 HAL,并且没有理由认为这应该是一个问题。

HAL 说排队系统(如 PBS)不能用于将读/写的优先级设置为低,例如,在大型作业运行时始终保留 1 GB 内存可用。用他的话来说:

用于 gunzip 的脚本会阻塞所有处理器,因为数据很大......排队无法解决这个问题......在从(该服务器)到(该服务器)的文件传输期间,膨胀步骤会进行大量读取/写

为什么排队不能解决这个问题?什么可以?

Jef*_*and 5

您可以拥有一个作业排队系统或修改内核的调度方法。

我将忽略这些选项并建议您使用ionice —— 或者更具体地说,Bob 使用它来降低他的优先级。听起来您遇到的是磁盘访问问题而不是内存问题。

常规的nice也可能是一个选项,因为它会间接影响磁盘优先级(来自 ionice 手册页:“尽力而为类别中的优先级将从进程的 cpu nice 级别动态派生:io_priority = (cpu_nice + 20) / 5." )上面的软件也非常方便,可以大致了解什么是瓶颈,以及是否是常规 IO 或交换到有问题的磁盘。


vor*_*aq7 5

Bob 读/写大文件(例如使用 gunzip)。这可能会间歇性地占用多达 100% 的内存数小时。这通常在一夜之间完成,但在运行时,即使是简单的命令,例如 cd 也需要 30 秒,打开 emacs 可能需要几分钟。

首先gzipgunzip不要像你想象的那样工作——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 作业。(常见问题解答

如果这是一个实际的现实问题,那么我很抱歉 - 您可能是在生产环境中实际遇到这种极端情况的万分之一。

  • 感谢您提前道歉;也许快速浏览一下我的个人资料会澄清我所做的工作。更重要的是,请确保不要将此特定作业问题出现的概率(您估计的万分之一表明它应该已经出现)与本网站上约 100,000 个问题之一的概率类似于以前出现在你的教科书中的一个。 (3认同)
  • @voretaq7 我经常看到磁盘争用问题。磁盘正忙于其他人的读/写,以至于 ls 需要整整一秒钟才能列出目录。哎呀,只是试图在我的笔记本电脑启动时立即打开应用程序是一种拖累。 (2认同)