如何解决从SLURM了解MaxRSS
我认为MaxRSS
是用来了解SLURM
作业的内存需求的;但是,现在我在问自己。
我收到SLURM
的通知,说我的工作失败了。
SLURM Job_id = 7347729 Name = job.cph.proband已结束,运行时间00:01:21,OUT_OF_MEMORY
我用sacct
检查了作业失败的原因;但是,它似乎失败,并出现 OOM 错误。这很奇怪,因为它似乎仅尝试使用所请求的1.61 Gb
中的3 Gb
(在此处显示为2.93
)。
我对MaxRSS
的理解是错误的还是该工作因其他原因而失败?
解决方法
在此wiki post中,建议sacct
工具为您提供特定的答案,作业管理器可能无法以足够快的速度获取使用情况数据以跟踪内存使用量的峰值。
SLURM的记帐机制基于轮询,并不总是能够捕获内存使用量的高峰。 FSL的实现使用称为“ cgroups”的Linux内核功能来控制内存和CPU使用率。 SLURM为作业设置了一个cgroup,具有Linux内核严格执行的适当限制。
问题很简单:内核从有问题的工作中杀死了一个进程,而SLURM计费机制没有在正确的时间进行轮询,以查看导致内核杀死该进程的使用高峰。
您的sacct
呼叫在取消3 GB作业之前显示1.6 GB的使用情况,可能暗示您的进程如何使用内存。
您的流程使用的数据结构可能会随着其增长而调整大小。在重新分配该数据的过程中,您的过程可能会临时请求一块内存,大于Slurm可用于该作业的内存。
根据实现的不同,一旦添加了足够的元素,C ++ std::vector
(例如may try to create a temporary,new vector that is twice or some other multiple of size)就会从旧向量中复制数据。
通俗地说,在不了解正在运行的内容的情况下,临时创建两倍于1.6 GB大小的数据结构似乎足以触发作业取消,在您的示例中,除了任何已分配的空间。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。