管理實(shí)戰(zhàn)：從提交到監(jiān)控的完整命令指南)
1. 項(xiàng)目概述Slurm集群作業(yè)管理的核心武器如果你正在或即將使用高性能計(jì)算集群那么Slurm這個名字你一定不陌生。它不是什么美味佳肴而是當(dāng)今學(xué)術(shù)界和工業(yè)界最主流的開源集群管理和作業(yè)調(diào)度系統(tǒng)。想象一下一個擁有成百上千個計(jì)算節(jié)點(diǎn)的龐大機(jī)器如何公平、高效地把計(jì)算任務(wù)分配給每個“工人”并管理好他們的工作狀態(tài)和產(chǎn)出這就是Slurm的職責(zé)。而作為用戶我們與這個龐大系統(tǒng)交互的唯一方式就是通過一系列命令行指令。今天我們就來徹底拆解這些命令從作業(yè)的“生”提交到“死”結(jié)束覆蓋你日常使用中90%以上的場景。無論你是剛接觸集群的新手還是想系統(tǒng)梳理知識的老手這篇基于實(shí)戰(zhàn)經(jīng)驗(yàn)的命令指南都能讓你對Slurm作業(yè)的管理游刃有余。很多朋友剛上手時面對srun、sbatch、squeue這些命令可能會感到困惑參數(shù)繁多輸出信息復(fù)雜。其實(shí)它們的核心邏輯非常清晰提交作業(yè)、查詢狀態(tài)、控制作業(yè)生命周期。掌握了這些你就掌握了在集群上開展計(jì)算工作的主動權(quán)。本文將不僅列出命令更會深入解釋每個常用參數(shù)背后的邏輯、不同命令的適用場景以及我在多年使用中踩過的坑和總結(jié)的技巧。比如如何優(yōu)雅地指定GPU資源作業(yè)卡住了怎么辦如何修改一個已經(jīng)提交但尚未運(yùn)行的作業(yè)這些實(shí)戰(zhàn)問題我們都會一一找到答案。2. Slurm作業(yè)生命周期與命令全景圖在深入每個命令之前我們需要建立一個宏觀視角理解一個作業(yè)在Slurm系統(tǒng)中經(jīng)歷的完整生命周期以及每個階段對應(yīng)的核心管理命令。這就像理解一個產(chǎn)品的流水線知道了各個環(huán)節(jié)操作起來才能心中有數(shù)。2.1 作業(yè)生命周期的五個關(guān)鍵階段一個典型的Slurm作業(yè)通常會經(jīng)歷以下五個階段提交用戶將計(jì)算任務(wù)腳本提交給Slurm調(diào)度器。此時作業(yè)進(jìn)入隊(duì)列等待被調(diào)度。排隊(duì)作業(yè)在隊(duì)列中等待滿足其資源需求如CPU、內(nèi)存、GPU、節(jié)點(diǎn)數(shù)的計(jì)算節(jié)點(diǎn)空閑出來。運(yùn)行調(diào)度器為作業(yè)分配了資源作業(yè)開始在計(jì)算節(jié)點(diǎn)上執(zhí)行。完成/終止作業(yè)正常執(zhí)行完畢或因錯誤、被用戶手動終止而結(jié)束。后處理用戶查看作業(yè)的輸出、錯誤日志以及效率統(tǒng)計(jì)信息。2.2 對應(yīng)各階段的核心命令家族圍繞這個生命周期Slurm提供了一套完整的命令集我們可以將其分為幾個家族提交家族負(fù)責(zé)創(chuàng)建和遞交作業(yè)。sbatch最常用的批處理作業(yè)提交命令。你編寫一個Shell腳本在其中通過#SBATCH指令指定資源需求然后用sbatch提交。作業(yè)會在后臺運(yùn)行與你當(dāng)前終端會話解耦。srun用于交互式地運(yùn)行作業(yè)。它會分配資源并立即在分配的資源上執(zhí)行一個命令。通常用于測試、調(diào)試或者作為sbatch腳本內(nèi)部用于啟動并行任務(wù)的命令。salloc分配一個資源分配如幾個節(jié)點(diǎn)并獲取一個交互式的Shell。在這個Shell中你可以直接運(yùn)行srun命令而無需再指定資源參數(shù)因?yàn)樗鼈円呀?jīng)被salloc分配好了。適合需要交互式探索的場景。查詢家族負(fù)責(zé)監(jiān)控作業(yè)和集群狀態(tài)。squeue查看作業(yè)隊(duì)列狀態(tài)的核心命令?？梢圆榭此凶鳂I(yè)或自己作業(yè)的排隊(duì)、運(yùn)行等情況。sinfo查看集群節(jié)點(diǎn)狀態(tài)?？梢灾滥男┕?jié)點(diǎn)空閑、哪些節(jié)點(diǎn)正在工作、哪些節(jié)點(diǎn)下線對于理解為什么作業(yè)在排隊(duì)非常有幫助。scontrol一個功能強(qiáng)大的管理命令可以查看作業(yè)、節(jié)點(diǎn)、分區(qū)等非常詳細(xì)的信息show子命令也可以用于修改作業(yè)參數(shù)update子命令?？刂萍易遑?fù)責(zé)干預(yù)作業(yè)的運(yùn)行。scancel終止作業(yè)?？梢越K止單個、多個或符合特定條件的所有作業(yè)。scontrol除了查詢還能用于掛起、恢復(fù)作業(yè)。歷史與診斷家族負(fù)責(zé)查看已完成作業(yè)的信息。sacct查看已完成作業(yè)的會計(jì)信息。這是squeue的互補(bǔ)命令squeue看活著的作業(yè)sacct看死去的作業(yè)。可以查看作業(yè)的運(yùn)行時間、消耗的CPU時間、內(nèi)存使用量、退出狀態(tài)等對于性能分析和計(jì)費(fèi)至關(guān)重要。seff查看指定作業(yè)ID的資源使用效率報告如CPU和內(nèi)存的使用率非常直觀。理解這個全景圖后我們再深入每個命令的細(xì)節(jié)就會感覺脈絡(luò)清晰不再是一盤散沙。接下來我們從最核心的作業(yè)提交開始。3. 作業(yè)提交從腳本編寫到資源請求提交作業(yè)是萬里長征的第一步也是最容易出錯的一步。資源請求不合理可能導(dǎo)致作業(yè)永遠(yuǎn)排不到隊(duì)或者一運(yùn)行就因內(nèi)存不足被“殺”。sbatch是這里的主角。3.1 編寫一個規(guī)范的sbatch腳本一個典型的sbatch腳本包含兩部分以#SBATCH開頭的Slurm指令和你要執(zhí)行的常規(guī)Shell命令。#!/bin/bash #SBATCH --job-namemy_test_job # 作業(yè)名稱方便在隊(duì)列中識別 #SBATCH --outputslurm-%j.out # 標(biāo)準(zhǔn)輸出重定向到文件%j會被替換為作業(yè)ID #SBATCH --errorslurm-%j.err # 標(biāo)準(zhǔn)錯誤重定向到文件 #SBATCH --partitioncompute # 指定分區(qū)隊(duì)列名 #SBATCH --nodes2 # 請求的節(jié)點(diǎn)數(shù) #SBATCH --ntasks-per-node4 # 每個節(jié)點(diǎn)上啟動的任務(wù)數(shù)通常對應(yīng)MPI進(jìn)程數(shù) #SBATCH --cpus-per-task2 # 每個任務(wù)分配的CPU核心數(shù) #SBATCH --mem-per-cpu4G # 每個CPU核心分配的內(nèi)存 #SBATCH --time01:00:00 # 作業(yè)運(yùn)行的最大時間時:分:秒 #SBATCH --gresgpu:2 # 請求通用資源這里是每個節(jié)點(diǎn)2塊GPU # 加載必要的環(huán)境模塊根據(jù)集群配置 module load cuda/11.7 module load gcc/9.3.0 # 打印一些環(huán)境信息便于調(diào)試 echo Starting job on host: $(hostname) echo Job ID: $SLURM_JOB_ID echo Allocated nodes: $SLURM_JOB_NODELIST # 這里是你的實(shí)際計(jì)算命令 # 例如運(yùn)行一個MPI程序 srun ./my_mpi_program input.data # 或者運(yùn)行一個非MPI的并行任務(wù) # python my_script.py注意#SBATCH指令必須放在腳本開頭在所有可執(zhí)行命令之前。Slurm在解析腳本時會讀取這些指令然后才將腳本交給Shell執(zhí)行。3.2 關(guān)鍵資源參數(shù)詳解與選型邏輯為什么這么指定參數(shù)背后的考量是什么--partition分區(qū)是集群管理員根據(jù)節(jié)點(diǎn)硬件或用途劃分的邏輯組。比如可能有debug短時間測試、compute通用計(jì)算、gpuGPU節(jié)點(diǎn)、bigmem大內(nèi)存節(jié)點(diǎn)。選型邏輯根據(jù)作業(yè)需求選擇。短測試用debug需要GPU選gpu需要超大內(nèi)存選bigmem。選錯分區(qū)可能導(dǎo)致作業(yè)無法調(diào)度。--nodes、--ntasks-per-node、--cpus-per-task這三個參數(shù)共同定義了并行計(jì)算資源。MPI作業(yè)通常--ntasks-per-node指定每個節(jié)點(diǎn)的進(jìn)程數(shù)總進(jìn)程數(shù) --nodes*--ntasks-per-node。--cpus-per-task為每個MPI進(jìn)程綁定CPU核心提升緩存親和性。OpenMP/多線程作業(yè)可能只需要1個任務(wù)--ntasks1但需要多個CPU核心--cpus-per-task16?；旌螹PIOpenMP--nodes和--ntasks-per-node定義MPI進(jìn)程網(wǎng)格--cpus-per-task定義每個MPI進(jìn)程內(nèi)部的OpenMP線程數(shù)。選型邏輯明確你的程序是哪種并行模式。最保險的方法是閱讀程序文檔或咨詢開發(fā)者。--mem與--mem-per-cpu指定內(nèi)存。--mem指定每個節(jié)點(diǎn)總內(nèi)存--mem-per-cpu指定每個CPU核心的內(nèi)存。二選一不要同時指定。選型邏輯如果你的程序內(nèi)存需求與核心數(shù)線性相關(guān)用--mem-per-cpu更靈活。如果程序有固定的基礎(chǔ)內(nèi)存開銷用--mem更直觀。務(wù)必預(yù)留buffer不要卡著程序理論最小值申請否則可能因內(nèi)存超限被Slurm強(qiáng)制終止。--time極其重要。這是作業(yè)運(yùn)行時間上限。超時后作業(yè)會被強(qiáng)制終止。選型邏輯根據(jù)歷史運(yùn)行經(jīng)驗(yàn)估算并加上一定的安全余量如20%。在debug分區(qū)時間限制通常很短如30分鐘用于快速測試。--gres請求通用資源最常見的是GPU。--gresgpu:2表示請求2塊GPU類型默認(rèn)。更精確的請求可以是--gresgpu:v100:2請求2塊V100 GPU。選型邏輯確認(rèn)你的代碼支持GPU加速并加載了對應(yīng)的CUDA環(huán)境。3.3 提交作業(yè)與srun交互模式編寫好腳本假設(shè)名為run.slurm后使用以下命令提交sbatch run.slurm提交成功后會返回一個作業(yè)ID例如Submitted batch job 1234567。這個ID是后續(xù)查詢、控制作業(yè)的唯一憑證。交互式作業(yè)srun當(dāng)你需要快速測試一個命令或者進(jìn)行調(diào)試時可以使用srun。# 請求一個節(jié)點(diǎn)的一個核心運(yùn)行10分鐘運(yùn)行一個交互式bash srun --pty --nodes1 --ntasks1 --cpus-per-task1 --time00:10:00 /bin/bash進(jìn)入交互式Shell后你就可以像在登錄節(jié)點(diǎn)一樣操作但實(shí)際是在計(jì)算節(jié)點(diǎn)上。退出Shell作業(yè)即結(jié)束。資源分配salloc它介于sbatch和srun之間。# 分配2個節(jié)點(diǎn)每個節(jié)點(diǎn)4個任務(wù)分配1小時 salloc --nodes2 --ntasks-per-node4 --time01:00:00命令執(zhí)行后你的終端會“附著”到這個新分配的資源上命令行提示符通常會變化。在此終端中后續(xù)的srun命令會直接使用已分配的資源。# 此時運(yùn)行srun無需再指定節(jié)點(diǎn)、任務(wù)數(shù)等參數(shù) srun ./my_mpi_program使用exit命令退出資源釋放。4. 作業(yè)查詢與監(jiān)控掌握集群動態(tài)作業(yè)提交后你不能干等著。你需要知道它是在排隊(duì)、在運(yùn)行還是失敗了。squeue和sinfo是你的“監(jiān)控大屏”。4.1 使用squeue洞察作業(yè)狀態(tài)squeue是最常用的查詢命令。不加任何參數(shù)它會列出所有用戶的所有作業(yè)信息量巨大。squeue輸出示例JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) 123456 compute my_test_jo alice PD 0:00 2 (Resources) 123457 gpu train bob R 2:34 1 gpu-node-03 123458 debug quick_test carl R 0:05 1 compute-01關(guān)鍵列解析ST狀態(tài)這是最重要的列。PD排隊(duì)中。NODELIST(REASON)列會顯示排隊(duì)原因如(Resources)等待資源、(Priority)優(yōu)先級低、(Dependency)等待依賴作業(yè)。R運(yùn)行中。CG正在完成作業(yè)已結(jié)束Slurm在進(jìn)行收尾工作。F失敗。CA已取消。TIME作業(yè)已運(yùn)行時間或排隊(duì)時間對于PD狀態(tài)。NODELIST(REASON)對于運(yùn)行中的作業(yè)顯示使用的節(jié)點(diǎn)列表對于排隊(duì)作業(yè)顯示排隊(duì)原因。常用過濾選項(xiàng)squeue -u $USER只看自己的作業(yè)。squeue -j 123456查看特定作業(yè)ID的詳細(xì)信息。squeue --start非常有用。顯示排隊(duì)作業(yè)的預(yù)計(jì)開始時間如果調(diào)度器能估算的話。squeue -o “%.18i %.9P %.30j %.8u %.2t %.10M %.6D %.20R”自定義輸出格式。例如這里顯示了更長的作業(yè)名和節(jié)點(diǎn)原因信息。4.2 使用sinfo診斷集群資源如果你的作業(yè)一直PD且原因是(Resources)就該用sinfo看看集群到底怎么了。sinfo輸出示例PARTITION AVAIL TIMELIMIT NODES STATE NODELIST compute* up infinite 2 idle compute-[01-02] compute* up infinite 1 alloc compute-03 gpu up 2-00:00:00 4 idle gpu-[01-04] gpu up 2-00:00:00 2 alloc gpu-[05-06] debug up 00:30:00 2 idle debug-[01-02]關(guān)鍵列解析STATE節(jié)點(diǎn)狀態(tài)idle節(jié)點(diǎn)空閑可用。alloc節(jié)點(diǎn)已被分配正在運(yùn)行作業(yè)。mix節(jié)點(diǎn)部分資源被分配部分空閑。drain節(jié)點(diǎn)正在被排干管理員可能在進(jìn)行維護(hù)不接受新作業(yè)。down節(jié)點(diǎn)宕機(jī)不可用。NODELIST處于該狀態(tài)的節(jié)點(diǎn)列表。常用選項(xiàng)sinfo -N以節(jié)點(diǎn)為單位顯示信息更清晰。sinfo -p compute只看compute分區(qū)的信息。sinfo -R顯示節(jié)點(diǎn)不可用的原因如果狀態(tài)是drain或down。通過結(jié)合squeue和sinfo你就能清晰地知道我的作業(yè)在等什么是資源不夠還是節(jié)點(diǎn)壞了從而決定是繼續(xù)等待還是調(diào)整作業(yè)資源請求。4.3 使用scontrol挖掘詳細(xì)信息scontrol show job jobid可以讓你看到作業(yè)的一切詳細(xì)信息遠(yuǎn)比squeue豐富。這對于調(diào)試復(fù)雜問題至關(guān)重要。scontrol show job 123456輸出信息包括提交時間、開始時間、運(yùn)行限制、資源請求詳情、使用的節(jié)點(diǎn)列表、工作目錄、標(biāo)準(zhǔn)輸出/錯誤路徑、依賴關(guān)系等等。當(dāng)作業(yè)行為異常時這是第一手的診斷資料。5. 作業(yè)控制與修改動態(tài)管理你的計(jì)算任務(wù)計(jì)劃趕不上變化。你可能需要取消一個錯誤的作業(yè)或者修改一個還在排隊(duì)中的作業(yè)的資源需求。scancel和scontrol update是應(yīng)對這些情況的工具。5.1 安全終止作業(yè)scancel的多種用法scancel用于向作業(yè)發(fā)送終止信號。取消單個作業(yè)scancel 123456取消自己所有作業(yè)scancel -u $USER慎用取消某個分區(qū)所有作業(yè)scancel -p compute取消所有排隊(duì)中的作業(yè)scancel -t PD強(qiáng)制終止如果作業(yè)不響應(yīng)普通的終止信號可以加--signalKILL或-9選項(xiàng)scancel --signalKILL 123456注意對于運(yùn)行中的作業(yè)scancel會先發(fā)送一個軟終止信號SIGTERM允許程序進(jìn)行清理工作。如果一段時間后作業(yè)仍未結(jié)束Slurm會發(fā)送強(qiáng)制終止信號SIGKILL。直接使用-9會跳過軟終止階段可能導(dǎo)致程序產(chǎn)生垃圾文件或數(shù)據(jù)損壞。5.2 動態(tài)修改排隊(duì)中的作業(yè)scontrol update這是一個非常強(qiáng)大但容易被忽略的功能。如果你的作業(yè)還在排隊(duì)PD狀態(tài)你可以修改它的部分參數(shù)而無需取消后重新提交?？梢孕薷牡某Ｒ妳?shù)包括--time增加或減少運(yùn)行時間限制。--partition切換到另一個分區(qū)。--qos修改服務(wù)質(zhì)量如從普通QoS切換到高優(yōu)先級QoS。--dependency修改作業(yè)依賴關(guān)系。--mail-user修改郵件通知地址。修改命令格式scontrol update jobid123456 time02:00:00 partitiongpu這條命令將作業(yè)123456的運(yùn)行時間限制改為2小時并將其從當(dāng)前分區(qū)移動到gpu分區(qū)。重要限制只能修改排隊(duì)中的作業(yè)。運(yùn)行中的作業(yè)無法修改核心參數(shù)。修改分區(qū)或QoS可能會導(dǎo)致作業(yè)重新排隊(duì)因?yàn)檎{(diào)度器需要根據(jù)新條件重新評估。無法修改核心資源請求如節(jié)點(diǎn)數(shù)、CPU數(shù)、內(nèi)存、GPU數(shù)因?yàn)檫@些是調(diào)度決策的基礎(chǔ)。要修改這些通常需要取消后重新提交。5.3 掛起與恢復(fù)作業(yè)在某些集群配置下管理員或擁有特定權(quán)限的用戶可以掛起和恢復(fù)作業(yè)。# 掛起作業(yè) scontrol suspend 123456 # 恢復(fù)作業(yè) scontrol resume 123456掛起后作業(yè)會釋放其占用的CPU資源但內(nèi)存狀態(tài)會被保留在節(jié)點(diǎn)上。這通常用于臨時給更高優(yōu)先級的作業(yè)讓路。普通用戶通常沒有此權(quán)限。6. 歷史分析與效率評估從已完成作業(yè)中學(xué)習(xí)作業(yè)運(yùn)行結(jié)束后故事并沒有結(jié)束。分析作業(yè)的運(yùn)行效率、資源使用情況對于優(yōu)化代碼和資源請求至關(guān)重要。sacct和seff是這方面的利器。6.1 使用sacct查看會計(jì)信息sacct是查看歷史作業(yè)的瑞士軍刀功能極其強(qiáng)大。默認(rèn)顯示最近一天的自己作業(yè)。sacct輸出示例JobID JobName Partition Account AllocCPUS State ExitCode ------------ ---------- ---------- ---------- ---------- ---------- -------- 123456 my_test_j compute alice 16 COMPLETED 0:0 123456.batch batch alice 16 COMPLETED 0:0 123456.0 my_mpi_prog alice 16 COMPLETED 0:0常用選項(xiàng)組合sacct -j 123456查看特定作業(yè)的詳細(xì)信息。sacct --starttime2024-01-01 --endtime2024-01-02查看指定時間段的作業(yè)。sacct -o JobID,JobName,Partition,AllocCPUS,State,Elapsed,MaxRSS,TotalCPU自定義輸出字段。Elapsed實(shí)際運(yùn)行時間。MaxRSS最大常駐內(nèi)存集即作業(yè)使用的最大物理內(nèi)存。這是判斷你申請的內(nèi)存是否合理的關(guān)鍵指標(biāo)TotalCPU作業(yè)消耗的總CPU時間核心數(shù)*時間。sacct -X只顯示作業(yè)主體不顯示每個步驟如.batch.0。一個實(shí)用的分析命令sacct -j 123456 -o JobID,JobName,AllocCPUS,ReqMem,MaxRSS,State,Elapsed,TotalCPU --unitsG這條命令可以清晰地看到作業(yè)123456申請的內(nèi)存ReqMem、實(shí)際使用的最大內(nèi)存MaxRSS、運(yùn)行狀態(tài)、耗時和總CPU消耗并且內(nèi)存單位是G。如果MaxRSS遠(yuǎn)小于ReqMem說明你申請了過多內(nèi)存浪費(fèi)了資源下次可以適當(dāng)減少請求。6.2 使用seff快速獲取效率報告sacct功能強(qiáng)大但輸出可能不夠直觀。seff命令提供了一個簡潔明了的資源效率報告。seff 123456輸出示例Job ID: 123456 Cluster: mycluster User/Group: alice/alice State: COMPLETED (exit code 0) Nodes: 2 Cores per node: 8 CPU Utilized: 1-12:34:56 CPU Efficiency: 85.7% of 1-16:00:00 core-walltime Job Wall-clock time: 1-02:00:00 Memory Utilized: 12.5 GB Memory Efficiency: 31.25% of 40.00 GB這份報告一目了然CPU EfficiencyCPU利用率。85.7%是相當(dāng)不錯的水平。如果這個值很低如50%說明你的程序可能不是CPU密集型或者存在大量I/O等待、同步等待需要優(yōu)化。Memory Efficiency內(nèi)存利用率。31.25%意味著你申請了40GB內(nèi)存但只用了12.5GB。這是嚴(yán)重的資源浪費(fèi)下次提交時應(yīng)該將內(nèi)存請求降低到16GB或20GB左右留出一些buffer即可。這樣你的作業(yè)會更容易被調(diào)度也為其他用戶釋放了資源。定期使用seff檢查作業(yè)效率是成為一個負(fù)責(zé)任、高效的集群用戶的好習(xí)慣。7. 高級技巧與實(shí)戰(zhàn)避坑指南掌握了基本命令后一些高級技巧和實(shí)戰(zhàn)中的“坑”能讓你用得更順手。7.1 作業(yè)依賴構(gòu)建工作流你可以讓一個作業(yè)在另一個作業(yè)完成或成功完成后再開始運(yùn)行。這對于多步驟的工作流非常有用。# 作業(yè)B在作業(yè)A完成后開始 sbatch --dependencyafterany:123456 jobB.slurm # 作業(yè)B在作業(yè)A成功完成后開始退出碼為0 sbatch --dependencyafterok:123456 jobB.slurm # 作業(yè)B在作業(yè)A結(jié)束后開始無論成功失敗 sbatch --dependencyafter:123456 jobB.slurm依賴關(guān)系可以組合--dependencyafterok:123456,afterok:123457兩個作業(yè)都成功后才開始。7.2 數(shù)組作業(yè)處理參數(shù)掃描如果你需要運(yùn)行大量相似的任務(wù)例如用不同的參數(shù)運(yùn)行同一個程序使用數(shù)組作業(yè)Job Array比提交幾百個獨(dú)立作業(yè)高效得多。#!/bin/bash #SBATCH --job-namearray_test #SBATCH --outputslurm-%A_%a.out # %A是主作業(yè)ID%a是數(shù)組索引 #SBATCH --array1-100 # 創(chuàng)建索引從1到100的數(shù)組 # 根據(jù)數(shù)組索引設(shè)置不同的輸入?yún)?shù) INPUT_FILE”input_${SLURM_ARRAY_TASK_ID}.dat” OUTPUT_FILE”output_${SLURM_ARRAY_TASK_ID}.dat” ./my_program -i $INPUT_FILE -o $OUTPUT_FILE提交后Slurm會調(diào)度100個子任務(wù)。你可以用squeue看到它們作業(yè)ID類似123456_[1-100]?？梢杂胹cancel 123456_[50]取消單個子任務(wù)或用scancel 123456取消整個數(shù)組。7.3 環(huán)境變量與工作目錄在sbatch腳本中Slurm會設(shè)置一系列有用的環(huán)境變量SLURM_JOB_ID當(dāng)前作業(yè)ID。SLURM_SUBMIT_DIR提交作業(yè)的目錄。SLURM_JOB_NODELIST分配給作業(yè)的節(jié)點(diǎn)列表。SLURM_ARRAY_TASK_ID數(shù)組作業(yè)的當(dāng)前索引。SLURM_CPUS_PER_TASK每個任務(wù)分配的CPU數(shù)。一個常見的坑你的程序可能依賴某些環(huán)境變量如PATH,LD_LIBRARY_PATH這些在登錄節(jié)點(diǎn)設(shè)置好了但計(jì)算節(jié)點(diǎn)可能沒有。最佳實(shí)踐是在腳本中使用module load命令顯式加載所需環(huán)境或者使用絕對路徑調(diào)用程序和庫。7.4 輸出與錯誤日志管理#SBATCH --output和#SBATCH --error務(wù)必重定向。否則輸出會混在一起難以調(diào)試。對于長時間運(yùn)行或輸出量大的作業(yè)可以考慮在腳本內(nèi)部將輸出重定向到文件而不是完全依賴Slurm的重定向。使用tail -f slurm-123456.out可以實(shí)時跟蹤運(yùn)行中的作業(yè)輸出在登錄節(jié)點(diǎn)執(zhí)行。7.5 資源請求的黃金法則時間盡可能準(zhǔn)確地估計(jì)并加10-20%緩沖。申請時間過長會降低調(diào)度優(yōu)先級申請時間過短會被強(qiáng)制殺死。內(nèi)存通過測試小規(guī)模任務(wù)用seff估算MaxRSS然后按比例放大到全規(guī)模并增加20-30%的安全余量。不要盲目申請超大內(nèi)存。CPU/GPU匹配你的程序并行能力。一個只能串行的程序申請16個核心只會浪費(fèi)15個核心。使用性能分析工具如gprof,nvprof了解你的程序。分區(qū)選擇合適的隊(duì)列。在debug隊(duì)列做短測試在gpu隊(duì)列跑GPU任務(wù)。7.6 當(dāng)作業(yè)出問題時作業(yè)一直PD用squeue --start看預(yù)計(jì)時間。用scontrol show job看詳細(xì)信息。用sinfo檢查目標(biāo)分區(qū)資源是否緊張或節(jié)點(diǎn)是否drain/down?？紤]調(diào)整資源請求或換分區(qū)。作業(yè)運(yùn)行失敗狀態(tài)為FAILED首先檢查錯誤日志文件slurm-jobid.err。常見原因內(nèi)存超限Out Of Memory、運(yùn)行超時、依賴的軟件模塊未加載、輸入文件路徑錯誤、權(quán)限問題。作業(yè)被終止?fàn)顟B(tài)為CANCELLED可能是你或他人用scancel終止了也可能是系統(tǒng)管理員因維護(hù)需要終止的。檢查郵件通知或聯(lián)系管理員。程序運(yùn)行慢登錄計(jì)算節(jié)點(diǎn)通過srun --pty bash使用top、htop、nvidia-smiGPU作業(yè)等命令查看資源實(shí)際使用情況?？赡苁荌/O瓶頸、內(nèi)存交換、或者程序本身并行效率低。掌握這些命令和技巧你就能從Slurm的“用戶”進(jìn)階為“管理者”從容應(yīng)對集群上的各種計(jì)算任務(wù)。記住清晰的資源請求、高效的代碼和定期的效率分析不僅是對自己負(fù)責(zé)也是對共享集群資源的其他用戶的尊重。 Slurm集群作業(yè)管理實(shí)戰(zhàn)：從提交到監(jiān)控的完整命令指南
1. 項(xiàng)目概述Slurm集群作業(yè)管理的核心武器如果你正在或即將使用高性能計(jì)算集群那么Slurm這個名字你一定不陌生。它不是什么美味佳肴而是當(dāng)今學(xué)術(shù)界和工業(yè)界最主流的開源集群管理和作業(yè)調(diào)度系統(tǒng)。想象一下一個擁有成百上千個計(jì)算節(jié)點(diǎn)的龐大機(jī)器如何公平、高效地把計(jì)算任務(wù)分配給每個“工人”并管理好他們的工作狀態(tài)和產(chǎn)出這就是Slurm的職責(zé)。而作為用戶我們與這個龐大系統(tǒng)交互的唯一方式就是通過一系列命令行指令。今天我們就來徹底拆解這些命令從作業(yè)的“生”提交到“死”結(jié)束覆蓋你日常使用中90%以上的場景。無論你是剛接觸集群的新手還是想系統(tǒng)梳理知識的老手這篇基于實(shí)戰(zhàn)經(jīng)驗(yàn)的命令指南都能讓你對Slurm作業(yè)的管理游刃有余。很多朋友剛上手時面對srun、sbatch、squeue這些命令可能會感到困惑參數(shù)繁多輸出信息復(fù)雜。其實(shí)它們的核心邏輯非常清晰提交作業(yè)、查詢狀態(tài)、控制作業(yè)生命周期。掌握了這些你就掌握了在集群上開展計(jì)算工作的主動權(quán)。本文將不僅列出命令更會深入解釋每個常用參數(shù)背后的邏輯、不同命令的適用場景以及我在多年使用中踩過的坑和總結(jié)的技巧。比如如何優(yōu)雅地指定GPU資源作業(yè)卡住了怎么辦如何修改一個已經(jīng)提交但尚未運(yùn)行的作業(yè)這些實(shí)戰(zhàn)問題我們都會一一找到答案。2. Slurm作業(yè)生命周期與命令全景圖在深入每個命令之前我們需要建立一個宏觀視角理解一個作業(yè)在Slurm系統(tǒng)中經(jīng)歷的完整生命周期以及每個階段對應(yīng)的核心管理命令。這就像理解一個產(chǎn)品的流水線知道了各個環(huán)節(jié)操作起來才能心中有數(shù)。2.1 作業(yè)生命周期的五個關(guān)鍵階段一個典型的Slurm作業(yè)通常會經(jīng)歷以下五個階段提交用戶將計(jì)算任務(wù)腳本提交給Slurm調(diào)度器。此時作業(yè)進(jìn)入隊(duì)列等待被調(diào)度。排隊(duì)作業(yè)在隊(duì)列中等待滿足其資源需求如CPU、內(nèi)存、GPU、節(jié)點(diǎn)數(shù)的計(jì)算節(jié)點(diǎn)空閑出來。運(yùn)行調(diào)度器為作業(yè)分配了資源作業(yè)開始在計(jì)算節(jié)點(diǎn)上執(zhí)行。完成/終止作業(yè)正常執(zhí)行完畢或因錯誤、被用戶手動終止而結(jié)束。后處理用戶查看作業(yè)的輸出、錯誤日志以及效率統(tǒng)計(jì)信息。2.2 對應(yīng)各階段的核心命令家族圍繞這個生命周期Slurm提供了一套完整的命令集我們可以將其分為幾個家族提交家族負(fù)責(zé)創(chuàng)建和遞交作業(yè)。sbatch最常用的批處理作業(yè)提交命令。你編寫一個Shell腳本在其中通過#SBATCH指令指定資源需求然后用sbatch提交。作業(yè)會在后臺運(yùn)行與你當(dāng)前終端會話解耦。srun用于交互式地運(yùn)行作業(yè)。它會分配資源并立即在分配的資源上執(zhí)行一個命令。通常用于測試、調(diào)試或者作為sbatch腳本內(nèi)部用于啟動并行任務(wù)的命令。salloc分配一個資源分配如幾個節(jié)點(diǎn)并獲取一個交互式的Shell。在這個Shell中你可以直接運(yùn)行srun命令而無需再指定資源參數(shù)因?yàn)樗鼈円呀?jīng)被salloc分配好了。適合需要交互式探索的場景。查詢家族負(fù)責(zé)監(jiān)控作業(yè)和集群狀態(tài)。squeue查看作業(yè)隊(duì)列狀態(tài)的核心命令?？梢圆榭此凶鳂I(yè)或自己作業(yè)的排隊(duì)、運(yùn)行等情況。sinfo查看集群節(jié)點(diǎn)狀態(tài)?？梢灾滥男┕?jié)點(diǎn)空閑、哪些節(jié)點(diǎn)正在工作、哪些節(jié)點(diǎn)下線對于理解為什么作業(yè)在排隊(duì)非常有幫助。scontrol一個功能強(qiáng)大的管理命令可以查看作業(yè)、節(jié)點(diǎn)、分區(qū)等非常詳細(xì)的信息show子命令也可以用于修改作業(yè)參數(shù)update子命令?？刂萍易遑?fù)責(zé)干預(yù)作業(yè)的運(yùn)行。scancel終止作業(yè)?？梢越K止單個、多個或符合特定條件的所有作業(yè)。scontrol除了查詢還能用于掛起、恢復(fù)作業(yè)。歷史與診斷家族負(fù)責(zé)查看已完成作業(yè)的信息。sacct查看已完成作業(yè)的會計(jì)信息。這是squeue的互補(bǔ)命令squeue看活著的作業(yè)sacct看死去的作業(yè)。可以查看作業(yè)的運(yùn)行時間、消耗的CPU時間、內(nèi)存使用量、退出狀態(tài)等對于性能分析和計(jì)費(fèi)至關(guān)重要。seff查看指定作業(yè)ID的資源使用效率報告如CPU和內(nèi)存的使用率非常直觀。理解這個全景圖后我們再深入每個命令的細(xì)節(jié)就會感覺脈絡(luò)清晰不再是一盤散沙。接下來我們從最核心的作業(yè)提交開始。3. 作業(yè)提交從腳本編寫到資源請求提交作業(yè)是萬里長征的第一步也是最容易出錯的一步。資源請求不合理可能導(dǎo)致作業(yè)永遠(yuǎn)排不到隊(duì)或者一運(yùn)行就因內(nèi)存不足被“殺”。sbatch是這里的主角。3.1 編寫一個規(guī)范的sbatch腳本一個典型的sbatch腳本包含兩部分以#SBATCH開頭的Slurm指令和你要執(zhí)行的常規(guī)Shell命令。#!/bin/bash #SBATCH --job-namemy_test_job # 作業(yè)名稱方便在隊(duì)列中識別 #SBATCH --outputslurm-%j.out # 標(biāo)準(zhǔn)輸出重定向到文件%j會被替換為作業(yè)ID #SBATCH --errorslurm-%j.err # 標(biāo)準(zhǔn)錯誤重定向到文件 #SBATCH --partitioncompute # 指定分區(qū)隊(duì)列名 #SBATCH --nodes2 # 請求的節(jié)點(diǎn)數(shù) #SBATCH --ntasks-per-node4 # 每個節(jié)點(diǎn)上啟動的任務(wù)數(shù)通常對應(yīng)MPI進(jìn)程數(shù) #SBATCH --cpus-per-task2 # 每個任務(wù)分配的CPU核心數(shù) #SBATCH --mem-per-cpu4G # 每個CPU核心分配的內(nèi)存 #SBATCH --time01:00:00 # 作業(yè)運(yùn)行的最大時間時:分:秒 #SBATCH --gresgpu:2 # 請求通用資源這里是每個節(jié)點(diǎn)2塊GPU # 加載必要的環(huán)境模塊根據(jù)集群配置 module load cuda/11.7 module load gcc/9.3.0 # 打印一些環(huán)境信息便于調(diào)試 echo Starting job on host: $(hostname) echo Job ID: $SLURM_JOB_ID echo Allocated nodes: $SLURM_JOB_NODELIST # 這里是你的實(shí)際計(jì)算命令 # 例如運(yùn)行一個MPI程序 srun ./my_mpi_program input.data # 或者運(yùn)行一個非MPI的并行任務(wù) # python my_script.py注意#SBATCH指令必須放在腳本開頭在所有可執(zhí)行命令之前。Slurm在解析腳本時會讀取這些指令然后才將腳本交給Shell執(zhí)行。3.2 關(guān)鍵資源參數(shù)詳解與選型邏輯為什么這么指定參數(shù)背后的考量是什么--partition分區(qū)是集群管理員根據(jù)節(jié)點(diǎn)硬件或用途劃分的邏輯組。比如可能有debug短時間測試、compute通用計(jì)算、gpuGPU節(jié)點(diǎn)、bigmem大內(nèi)存節(jié)點(diǎn)。選型邏輯根據(jù)作業(yè)需求選擇。短測試用debug需要GPU選gpu需要超大內(nèi)存選bigmem。選錯分區(qū)可能導(dǎo)致作業(yè)無法調(diào)度。--nodes、--ntasks-per-node、--cpus-per-task這三個參數(shù)共同定義了并行計(jì)算資源。MPI作業(yè)通常--ntasks-per-node指定每個節(jié)點(diǎn)的進(jìn)程數(shù)總進(jìn)程數(shù) --nodes*--ntasks-per-node。--cpus-per-task為每個MPI進(jìn)程綁定CPU核心提升緩存親和性。OpenMP/多線程作業(yè)可能只需要1個任務(wù)--ntasks1但需要多個CPU核心--cpus-per-task16?；旌螹PIOpenMP--nodes和--ntasks-per-node定義MPI進(jìn)程網(wǎng)格--cpus-per-task定義每個MPI進(jìn)程內(nèi)部的OpenMP線程數(shù)。選型邏輯明確你的程序是哪種并行模式。最保險的方法是閱讀程序文檔或咨詢開發(fā)者。--mem與--mem-per-cpu指定內(nèi)存。--mem指定每個節(jié)點(diǎn)總內(nèi)存--mem-per-cpu指定每個CPU核心的內(nèi)存。二選一不要同時指定。選型邏輯如果你的程序內(nèi)存需求與核心數(shù)線性相關(guān)用--mem-per-cpu更靈活。如果程序有固定的基礎(chǔ)內(nèi)存開銷用--mem更直觀。務(wù)必預(yù)留buffer不要卡著程序理論最小值申請否則可能因內(nèi)存超限被Slurm強(qiáng)制終止。--time極其重要。這是作業(yè)運(yùn)行時間上限。超時后作業(yè)會被強(qiáng)制終止。選型邏輯根據(jù)歷史運(yùn)行經(jīng)驗(yàn)估算并加上一定的安全余量如20%。在debug分區(qū)時間限制通常很短如30分鐘用于快速測試。--gres請求通用資源最常見的是GPU。--gresgpu:2表示請求2塊GPU類型默認(rèn)。更精確的請求可以是--gresgpu:v100:2請求2塊V100 GPU。選型邏輯確認(rèn)你的代碼支持GPU加速并加載了對應(yīng)的CUDA環(huán)境。3.3 提交作業(yè)與srun交互模式編寫好腳本假設(shè)名為run.slurm后使用以下命令提交sbatch run.slurm提交成功后會返回一個作業(yè)ID例如Submitted batch job 1234567。這個ID是后續(xù)查詢、控制作業(yè)的唯一憑證。交互式作業(yè)srun當(dāng)你需要快速測試一個命令或者進(jìn)行調(diào)試時可以使用srun。# 請求一個節(jié)點(diǎn)的一個核心運(yùn)行10分鐘運(yùn)行一個交互式bash srun --pty --nodes1 --ntasks1 --cpus-per-task1 --time00:10:00 /bin/bash進(jìn)入交互式Shell后你就可以像在登錄節(jié)點(diǎn)一樣操作但實(shí)際是在計(jì)算節(jié)點(diǎn)上。退出Shell作業(yè)即結(jié)束。資源分配salloc它介于sbatch和srun之間。# 分配2個節(jié)點(diǎn)每個節(jié)點(diǎn)4個任務(wù)分配1小時 salloc --nodes2 --ntasks-per-node4 --time01:00:00命令執(zhí)行后你的終端會“附著”到這個新分配的資源上命令行提示符通常會變化。在此終端中后續(xù)的srun命令會直接使用已分配的資源。# 此時運(yùn)行srun無需再指定節(jié)點(diǎn)、任務(wù)數(shù)等參數(shù) srun ./my_mpi_program使用exit命令退出資源釋放。4. 作業(yè)查詢與監(jiān)控掌握集群動態(tài)作業(yè)提交后你不能干等著。你需要知道它是在排隊(duì)、在運(yùn)行還是失敗了。squeue和sinfo是你的“監(jiān)控大屏”。4.1 使用squeue洞察作業(yè)狀態(tài)squeue是最常用的查詢命令。不加任何參數(shù)它會列出所有用戶的所有作業(yè)信息量巨大。squeue輸出示例JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) 123456 compute my_test_jo alice PD 0:00 2 (Resources) 123457 gpu train bob R 2:34 1 gpu-node-03 123458 debug quick_test carl R 0:05 1 compute-01關(guān)鍵列解析ST狀態(tài)這是最重要的列。PD排隊(duì)中。NODELIST(REASON)列會顯示排隊(duì)原因如(Resources)等待資源、(Priority)優(yōu)先級低、(Dependency)等待依賴作業(yè)。R運(yùn)行中。CG正在完成作業(yè)已結(jié)束Slurm在進(jìn)行收尾工作。F失敗。CA已取消。TIME作業(yè)已運(yùn)行時間或排隊(duì)時間對于PD狀態(tài)。NODELIST(REASON)對于運(yùn)行中的作業(yè)顯示使用的節(jié)點(diǎn)列表對于排隊(duì)作業(yè)顯示排隊(duì)原因。常用過濾選項(xiàng)squeue -u $USER只看自己的作業(yè)。squeue -j 123456查看特定作業(yè)ID的詳細(xì)信息。squeue --start非常有用。顯示排隊(duì)作業(yè)的預(yù)計(jì)開始時間如果調(diào)度器能估算的話。squeue -o “%.18i %.9P %.30j %.8u %.2t %.10M %.6D %.20R”自定義輸出格式。例如這里顯示了更長的作業(yè)名和節(jié)點(diǎn)原因信息。4.2 使用sinfo診斷集群資源如果你的作業(yè)一直PD且原因是(Resources)就該用sinfo看看集群到底怎么了。sinfo輸出示例PARTITION AVAIL TIMELIMIT NODES STATE NODELIST compute* up infinite 2 idle compute-[01-02] compute* up infinite 1 alloc compute-03 gpu up 2-00:00:00 4 idle gpu-[01-04] gpu up 2-00:00:00 2 alloc gpu-[05-06] debug up 00:30:00 2 idle debug-[01-02]關(guān)鍵列解析STATE節(jié)點(diǎn)狀態(tài)idle節(jié)點(diǎn)空閑可用。alloc節(jié)點(diǎn)已被分配正在運(yùn)行作業(yè)。mix節(jié)點(diǎn)部分資源被分配部分空閑。drain節(jié)點(diǎn)正在被排干管理員可能在進(jìn)行維護(hù)不接受新作業(yè)。down節(jié)點(diǎn)宕機(jī)不可用。NODELIST處于該狀態(tài)的節(jié)點(diǎn)列表。常用選項(xiàng)sinfo -N以節(jié)點(diǎn)為單位顯示信息更清晰。sinfo -p compute只看compute分區(qū)的信息。sinfo -R顯示節(jié)點(diǎn)不可用的原因如果狀態(tài)是drain或down。通過結(jié)合squeue和sinfo你就能清晰地知道我的作業(yè)在等什么是資源不夠還是節(jié)點(diǎn)壞了從而決定是繼續(xù)等待還是調(diào)整作業(yè)資源請求。4.3 使用scontrol挖掘詳細(xì)信息scontrol show job jobid可以讓你看到作業(yè)的一切詳細(xì)信息遠(yuǎn)比squeue豐富。這對于調(diào)試復(fù)雜問題至關(guān)重要。scontrol show job 123456輸出信息包括提交時間、開始時間、運(yùn)行限制、資源請求詳情、使用的節(jié)點(diǎn)列表、工作目錄、標(biāo)準(zhǔn)輸出/錯誤路徑、依賴關(guān)系等等。當(dāng)作業(yè)行為異常時這是第一手的診斷資料。5. 作業(yè)控制與修改動態(tài)管理你的計(jì)算任務(wù)計(jì)劃趕不上變化。你可能需要取消一個錯誤的作業(yè)或者修改一個還在排隊(duì)中的作業(yè)的資源需求。scancel和scontrol update是應(yīng)對這些情況的工具。5.1 安全終止作業(yè)scancel的多種用法scancel用于向作業(yè)發(fā)送終止信號。取消單個作業(yè)scancel 123456取消自己所有作業(yè)scancel -u $USER慎用取消某個分區(qū)所有作業(yè)scancel -p compute取消所有排隊(duì)中的作業(yè)scancel -t PD強(qiáng)制終止如果作業(yè)不響應(yīng)普通的終止信號可以加--signalKILL或-9選項(xiàng)scancel --signalKILL 123456注意對于運(yùn)行中的作業(yè)scancel會先發(fā)送一個軟終止信號SIGTERM允許程序進(jìn)行清理工作。如果一段時間后作業(yè)仍未結(jié)束Slurm會發(fā)送強(qiáng)制終止信號SIGKILL。直接使用-9會跳過軟終止階段可能導(dǎo)致程序產(chǎn)生垃圾文件或數(shù)據(jù)損壞。5.2 動態(tài)修改排隊(duì)中的作業(yè)scontrol update這是一個非常強(qiáng)大但容易被忽略的功能。如果你的作業(yè)還在排隊(duì)PD狀態(tài)你可以修改它的部分參數(shù)而無需取消后重新提交?？梢孕薷牡某Ｒ妳?shù)包括--time增加或減少運(yùn)行時間限制。--partition切換到另一個分區(qū)。--qos修改服務(wù)質(zhì)量如從普通QoS切換到高優(yōu)先級QoS。--dependency修改作業(yè)依賴關(guān)系。--mail-user修改郵件通知地址。修改命令格式scontrol update jobid123456 time02:00:00 partitiongpu這條命令將作業(yè)123456的運(yùn)行時間限制改為2小時并將其從當(dāng)前分區(qū)移動到gpu分區(qū)。重要限制只能修改排隊(duì)中的作業(yè)。運(yùn)行中的作業(yè)無法修改核心參數(shù)。修改分區(qū)或QoS可能會導(dǎo)致作業(yè)重新排隊(duì)因?yàn)檎{(diào)度器需要根據(jù)新條件重新評估。無法修改核心資源請求如節(jié)點(diǎn)數(shù)、CPU數(shù)、內(nèi)存、GPU數(shù)因?yàn)檫@些是調(diào)度決策的基礎(chǔ)。要修改這些通常需要取消后重新提交。5.3 掛起與恢復(fù)作業(yè)在某些集群配置下管理員或擁有特定權(quán)限的用戶可以掛起和恢復(fù)作業(yè)。# 掛起作業(yè) scontrol suspend 123456 # 恢復(fù)作業(yè) scontrol resume 123456掛起后作業(yè)會釋放其占用的CPU資源但內(nèi)存狀態(tài)會被保留在節(jié)點(diǎn)上。這通常用于臨時給更高優(yōu)先級的作業(yè)讓路。普通用戶通常沒有此權(quán)限。6. 歷史分析與效率評估從已完成作業(yè)中學(xué)習(xí)作業(yè)運(yùn)行結(jié)束后故事并沒有結(jié)束。分析作業(yè)的運(yùn)行效率、資源使用情況對于優(yōu)化代碼和資源請求至關(guān)重要。sacct和seff是這方面的利器。6.1 使用sacct查看會計(jì)信息sacct是查看歷史作業(yè)的瑞士軍刀功能極其強(qiáng)大。默認(rèn)顯示最近一天的自己作業(yè)。sacct輸出示例JobID JobName Partition Account AllocCPUS State ExitCode ------------ ---------- ---------- ---------- ---------- ---------- -------- 123456 my_test_j compute alice 16 COMPLETED 0:0 123456.batch batch alice 16 COMPLETED 0:0 123456.0 my_mpi_prog alice 16 COMPLETED 0:0常用選項(xiàng)組合sacct -j 123456查看特定作業(yè)的詳細(xì)信息。sacct --starttime2024-01-01 --endtime2024-01-02查看指定時間段的作業(yè)。sacct -o JobID,JobName,Partition,AllocCPUS,State,Elapsed,MaxRSS,TotalCPU自定義輸出字段。Elapsed實(shí)際運(yùn)行時間。MaxRSS最大常駐內(nèi)存集即作業(yè)使用的最大物理內(nèi)存。這是判斷你申請的內(nèi)存是否合理的關(guān)鍵指標(biāo)TotalCPU作業(yè)消耗的總CPU時間核心數(shù)*時間。sacct -X只顯示作業(yè)主體不顯示每個步驟如.batch.0。一個實(shí)用的分析命令sacct -j 123456 -o JobID,JobName,AllocCPUS,ReqMem,MaxRSS,State,Elapsed,TotalCPU --unitsG這條命令可以清晰地看到作業(yè)123456申請的內(nèi)存ReqMem、實(shí)際使用的最大內(nèi)存MaxRSS、運(yùn)行狀態(tài)、耗時和總CPU消耗并且內(nèi)存單位是G。如果MaxRSS遠(yuǎn)小于ReqMem說明你申請了過多內(nèi)存浪費(fèi)了資源下次可以適當(dāng)減少請求。6.2 使用seff快速獲取效率報告sacct功能強(qiáng)大但輸出可能不夠直觀。seff命令提供了一個簡潔明了的資源效率報告。seff 123456輸出示例Job ID: 123456 Cluster: mycluster User/Group: alice/alice State: COMPLETED (exit code 0) Nodes: 2 Cores per node: 8 CPU Utilized: 1-12:34:56 CPU Efficiency: 85.7% of 1-16:00:00 core-walltime Job Wall-clock time: 1-02:00:00 Memory Utilized: 12.5 GB Memory Efficiency: 31.25% of 40.00 GB這份報告一目了然CPU EfficiencyCPU利用率。85.7%是相當(dāng)不錯的水平。如果這個值很低如50%說明你的程序可能不是CPU密集型或者存在大量I/O等待、同步等待需要優(yōu)化。Memory Efficiency內(nèi)存利用率。31.25%意味著你申請了40GB內(nèi)存但只用了12.5GB。這是嚴(yán)重的資源浪費(fèi)下次提交時應(yīng)該將內(nèi)存請求降低到16GB或20GB左右留出一些buffer即可。這樣你的作業(yè)會更容易被調(diào)度也為其他用戶釋放了資源。定期使用seff檢查作業(yè)效率是成為一個負(fù)責(zé)任、高效的集群用戶的好習(xí)慣。7. 高級技巧與實(shí)戰(zhàn)避坑指南掌握了基本命令后一些高級技巧和實(shí)戰(zhàn)中的“坑”能讓你用得更順手。7.1 作業(yè)依賴構(gòu)建工作流你可以讓一個作業(yè)在另一個作業(yè)完成或成功完成后再開始運(yùn)行。這對于多步驟的工作流非常有用。# 作業(yè)B在作業(yè)A完成后開始 sbatch --dependencyafterany:123456 jobB.slurm # 作業(yè)B在作業(yè)A成功完成后開始退出碼為0 sbatch --dependencyafterok:123456 jobB.slurm # 作業(yè)B在作業(yè)A結(jié)束后開始無論成功失敗 sbatch --dependencyafter:123456 jobB.slurm依賴關(guān)系可以組合--dependencyafterok:123456,afterok:123457兩個作業(yè)都成功后才開始。7.2 數(shù)組作業(yè)處理參數(shù)掃描如果你需要運(yùn)行大量相似的任務(wù)例如用不同的參數(shù)運(yùn)行同一個程序使用數(shù)組作業(yè)Job Array比提交幾百個獨(dú)立作業(yè)高效得多。#!/bin/bash #SBATCH --job-namearray_test #SBATCH --outputslurm-%A_%a.out # %A是主作業(yè)ID%a是數(shù)組索引 #SBATCH --array1-100 # 創(chuàng)建索引從1到100的數(shù)組 # 根據(jù)數(shù)組索引設(shè)置不同的輸入?yún)?shù) INPUT_FILE”input_${SLURM_ARRAY_TASK_ID}.dat” OUTPUT_FILE”output_${SLURM_ARRAY_TASK_ID}.dat” ./my_program -i $INPUT_FILE -o $OUTPUT_FILE提交后Slurm會調(diào)度100個子任務(wù)。你可以用squeue看到它們作業(yè)ID類似123456_[1-100]?？梢杂胹cancel 123456_[50]取消單個子任務(wù)或用scancel 123456取消整個數(shù)組。7.3 環(huán)境變量與工作目錄在sbatch腳本中Slurm會設(shè)置一系列有用的環(huán)境變量SLURM_JOB_ID當(dāng)前作業(yè)ID。SLURM_SUBMIT_DIR提交作業(yè)的目錄。SLURM_JOB_NODELIST分配給作業(yè)的節(jié)點(diǎn)列表。SLURM_ARRAY_TASK_ID數(shù)組作業(yè)的當(dāng)前索引。SLURM_CPUS_PER_TASK每個任務(wù)分配的CPU數(shù)。一個常見的坑你的程序可能依賴某些環(huán)境變量如PATH,LD_LIBRARY_PATH這些在登錄節(jié)點(diǎn)設(shè)置好了但計(jì)算節(jié)點(diǎn)可能沒有。最佳實(shí)踐是在腳本中使用module load命令顯式加載所需環(huán)境或者使用絕對路徑調(diào)用程序和庫。7.4 輸出與錯誤日志管理#SBATCH --output和#SBATCH --error務(wù)必重定向。否則輸出會混在一起難以調(diào)試。對于長時間運(yùn)行或輸出量大的作業(yè)可以考慮在腳本內(nèi)部將輸出重定向到文件而不是完全依賴Slurm的重定向。使用tail -f slurm-123456.out可以實(shí)時跟蹤運(yùn)行中的作業(yè)輸出在登錄節(jié)點(diǎn)執(zhí)行。7.5 資源請求的黃金法則時間盡可能準(zhǔn)確地估計(jì)并加10-20%緩沖。申請時間過長會降低調(diào)度優(yōu)先級申請時間過短會被強(qiáng)制殺死。內(nèi)存通過測試小規(guī)模任務(wù)用seff估算MaxRSS然后按比例放大到全規(guī)模并增加20-30%的安全余量。不要盲目申請超大內(nèi)存。CPU/GPU匹配你的程序并行能力。一個只能串行的程序申請16個核心只會浪費(fèi)15個核心。使用性能分析工具如gprof,nvprof了解你的程序。分區(qū)選擇合適的隊(duì)列。在debug隊(duì)列做短測試在gpu隊(duì)列跑GPU任務(wù)。7.6 當(dāng)作業(yè)出問題時作業(yè)一直PD用squeue --start看預(yù)計(jì)時間。用scontrol show job看詳細(xì)信息。用sinfo檢查目標(biāo)分區(qū)資源是否緊張或節(jié)點(diǎn)是否drain/down?？紤]調(diào)整資源請求或換分區(qū)。作業(yè)運(yùn)行失敗狀態(tài)為FAILED首先檢查錯誤日志文件slurm-jobid.err。常見原因內(nèi)存超限Out Of Memory、運(yùn)行超時、依賴的軟件模塊未加載、輸入文件路徑錯誤、權(quán)限問題。作業(yè)被終止?fàn)顟B(tài)為CANCELLED可能是你或他人用scancel終止了也可能是系統(tǒng)管理員因維護(hù)需要終止的。檢查郵件通知或聯(lián)系管理員。程序運(yùn)行慢登錄計(jì)算節(jié)點(diǎn)通過srun --pty bash使用top、htop、nvidia-smiGPU作業(yè)等命令查看資源實(shí)際使用情況?？赡苁荌/O瓶頸、內(nèi)存交換、或者程序本身并行效率低。掌握這些命令和技巧你就能從Slurm的“用戶”進(jìn)階為“管理者”從容應(yīng)對集群上的各種計(jì)算任務(wù)。記住清晰的資源請求、高效的代碼和定期的效率分析不僅是對自己負(fù)責(zé)也是對共享集群資源的其他用戶的尊重。