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