我认为MaxRSS是用来了解SLURM工作的内存要求;然而,现在我在质疑自己。
SLURM我收到了我的工作失败的通知。
SLURM Job_id=7347729 名称=job.cph.proband 已结束,运行时间 00:01:21,OUT_OF_MEMORY
我曾经sacct检查工作失败的原因;但是,看起来它因OOM错误而失败。这很奇怪,因为它看起来只是尝试使用1.61 Gb所请求的3 Gb(如下所示2.93)。
要么我的理解MaxRSS是错误的,要么这项工作因其他原因而失败?
这篇wiki 帖子中建议,作业管理器可能无法足够快地获取使用数据来跟踪内存使用量的峰值,以便该sacct工具为您提供具体的答案:
SLURM 的记账机制基于轮询,并不总能捕获内存使用量的峰值。FSL 的实现使用称为“cgroups”的 Linux 内核功能来控制内存和 CPU 使用情况。SLURM 为作业设置了一个 cgroup,并具有 Linux 内核严格执行的适当限制。
问题很简单:内核杀死了有问题的作业中的一个进程,并且 SLURM 记账机制没有在正确的时间轮询以查看导致内核杀死该进程的使用量峰值。
您的sacct调用在取消 3 GB 作业之前显示 1.6 GB 使用情况可能表明您的进程如何使用内存。
您的进程使用的数据结构可能需要随着其增长而调整大小。在重新分配该数据的过程中,您的进程可能会暂时请求比 Slurm 可用于该作业的内存块更大的内存块。
std::vector例如,根据实现的不同,C++可能会尝试创建一个临时的新向量,该向量是 size 的两倍或其他倍数,一旦添加了足够的元素,就会从旧向量复制数据。
一般来说,在不知道您正在运行的内容的任何细节的情况下,在您的示例中,除了已经存在的任何空间之外,临时创建两倍 1.6 GB 大小的数据结构似乎足以触发作业取消分配。
| 归档时间: |
|
| 查看次数: |
7302 次 |
| 最近记录: |