在我的工作环境中，我们有一个包含大约33个物理节点的集群。每个节点有2个虚拟机(VM(，每个虚拟机具有10个CPU(4个插槽(和112Gb内存。
我正在向该集群提交作业，下面是作业所需的最大内存(使用qacct -j [job]获得
maxvmem 37.893GB
maxvmem 37.660GB
maxvmem 37.980GB
maxvmem 41.059GB
maxvmem 41.615GB
maxvmem 38.744GB
maxvmem 38.615GB
让我们考虑一下这个问题剩余部分所需的最大内存为42GB。
事实上，当向这个集群提交92个作业(没有指定任何qsub参数(时，我注意到其中一些作业崩溃了，显然是由于内存问题。所有崩溃的作业都在有四个作业的物理节点上运行。这是有道理的：如果我有四个作业在一个物理节点上运行，每个42GB，4*42=168(>112(，所以我对一些作业崩溃并不感到惊讶。
然后我决定限制每个作业的内存。根据这个链接，这可以通过-l h_vmem=[maxmem]qsub参数来完成，该参数被添加到提交到队列的shell脚本中(下面我显示了.sh脚本的前三行，而第二行应该限制内存(。注意，-l h_vmem是每个插槽的内存
#! /bin/bash
#$ -l h_vmem=28G
echo HOSTNAME: `hostname`
在提交92个作业后，如果我执行qstat -j [job]，我会看到一行，如：
hard resource_list: h_vmem=28G
这意味着每个物理节点28*4=112GB，这是我的限制。看起来不错
然而，我看到一些物理节点已经有4个作业在运行，这正是我想要避免的。假设每个作业最多可以占用42GB的内存，我希望每个物理节点最多有2个作业(所需的最大内存为2*42=84GB(，这样它们就不会因内存不足而崩溃。
因此，qsub似乎没有正确解释我的.sh脚本上的参数#$ -l h_vmem=28G，因为所需的内存可能高达42x4=168GB，而28x4=112GB应该是我的限制。
我是否使用了错误的qsub参数(-l h_vmem(、.sh脚本上的错误符号(#$ -l h_vmem=28G-可能没有，因为在发出qstat时，这似乎已经被正确解析(，或者其他什么？
选项-l m_mem_free=42G在这种情况下会有所帮助。每个插槽的内存量。根据文档：如果主机无法满足m_mem_free请求，则跳过该主机。2021.1文件