slurm如何確定作業的內存使用情況

最近有用戶在我們的羣集上運行交互式作業。我們使用slurm作爲工作負載管理器。slurm如何確定作業的內存使用情況

salloc --cpus-per-task=48 --time=14-0 --partition=himem

這就要求整個高端內存（1.5TB）的機器我們的集羣上：他通過了他的分配。他跑了他的工作。當它運行，他的屏幕上，他得到了錯誤信息（或像這樣）：

salloc: Error memory limit exceeded

我登錄到節點，並利用top，他的工作只是採取310GB的RES。然而，slurmd.log內有錯誤的（跨越8小時！）這樣的轉換：

[2017-08-03T23:21:55.200] [398692.4294967295] Step 398692.4294967295 exceeded memory limit (1588997632 > 1587511296), being killed

問題：爲什麼頂部認爲他雖然SLURM認爲自己是使用1.58TB是一個使用310GB？

來源

2017-08-04 irritable_phd_syndrom

因爲據說slurm殺死了一個進程，可能會出現這樣的情況：在某個時間點，用戶產生了一個使用1.5TB的進程，但是當你登錄時它已經消失了。如果你碰巧有一個RedHat或派生系統，你可能會[sadc]（https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Introduction_To_System_Administration/s3-resource-tools-sar-sadc .html）以10分鐘的間隔運行並收集mem使用數據以檢查此假設。 –

我不認爲是這種情況，上面的'步驟398692.'中報告的pid與310GB進程的pid匹配。我正在監視'top'和slurm日誌，同時它正在生成所有'步驟398692.4294967295超出內存限制'錯誤。當它產生這些錯誤時，根本沒有任何過程具有那麼多的記憶。 –

要回答這個問題，Slurm使用/proc/<pid>/stat來獲取內存值。就你的情況而言，你無法親眼目睹這個有罪的過程，可能是因爲它被Slurm殺死了，正如@Dmitri Chubarov所建議的那樣。

另一種可能性是您遇到了最近在版本17.2.7中更正的Slurm錯誤。從更改日誌中：

- 增加緩衝處理長的/ proc //統計輸出，使SLURM可以讀取正確的RSS值，並就使用比請求更多的內存就業行動。

是SLURM多次試圖殺掉該進程的事實（你提到的日誌條目的幾次出現）表示機器上的RAM運行低和slurmd是試圖終止該進程所面臨的問題。我建議你激活cgroups進行任務控制;它更強大。

來源

2017-08-16 07:00:10 damienfrancois

感謝您指出這一變化。與此更改相關的錯誤是：https：//bugs.schedmd.com/show_bug.cgi？id = 3999。我們目前正在使用slurm的cgroups插件。在錯誤修復中，他們將緩衝區的長度從256-> 512字節更改。我會查看是否可以複製錯誤並檢查/ proc//stat的長度。我遇到的問題與bug中描述的問題有點不同，但絕對值得一試。 –

slurm如何確定作業的內存使用情況

回答

相關問題