靠口头约定分 GPU 会出什么事
一句话总结
排程器是不是通过人的共识而是通过政策来决定“谁什么时候做什么”的系统。
为什么需要这个？
GPU服务器一台的时候是这样做的。“现在在用吗？”“不，请用。”运行得很好。
如果两台，用户达到五人，Slack就会出现预约线程。如果三台，用户达到十人，就会发生这种情况。
- 谁
nvidia-smi确认后发布了，但在这期间，其他人先发布了，结果OOM，两人都死了。 - 整晚的石雕工作在凌晨3点结束，但GPU一直玩到早上9点。
- 有紧急实验，但没有人知道前面的人的工作什么时候能结束。
- 有人不小心拿了8张都忘了。
这些问题的共同点是资源分配没有被管理为状态。调度器将其转换为队列和策略。
怎么行动
Slurm的组成要素
| 组成要素 | 角色 | 无论在哪里 |
|---|---|---|
slurmctld |
中央控制器。队列管理、调度决定 | 1台管理节点（HA时2台） |
slurmd |
每个计算节点的代理。执行工作 | 所有计算节点 |
slurmdbd |
账户·使用量数据库（选择） | 管理节点 |
munge |
节点间认证 | 所有节点 |
munge在这幅画中最经常引起问题。聚类的所有节点必须具有相同的munge键，时间表也必须正确（基本允许误差为分钟）。键不同或时间表不一致的话Munge decode failed离开后节点无法通信。
ls -l /etc/munge/munge.key # 0400, munge:munge 여야 한다
如果权限稍微松懈一点，munged就完全不会弹出。
日程安排的基本概念
- 节点(Node) — 计算资源的单位。具有CPU、内存、GRES(GPU等)。
- 分区(Partition) — 节点的组和政策单位。决定最大执行时间、优先级、访问权限。对应其他调度器的“队列”。
- 工作（Job） — 用户提交的资源请求 + 要执行的内容。
- 工作步骤（Step） — 在工作中
srun以执行的单位。
背填（backfill）
基本调度器按优先级顺序安排工作。但是，当大型工作等待资源时，节点可能会闲逛。Backfill在“不延迟前一个工作的开始时间范围内”先填充后面的小工作。
白笔要正常运行，用户必须**--time必须诚实**地写。如果每个人都写最大的值，日程安排器就无法计算空闲时间。所以成熟的群集将“写短一点就能赚快钱”的激励措施作为政策。
请求资源的意义
sbatch --nodes=1 --ntasks=1 --cpus-per-task=8 --mem=64G --gres=gpu:a100:2 --time=04:00:00 train.sh
--nodes— 节点数量--ntasks— 要执行的任务（进程）数量。对应MPI排名数--cpus-per-task— 每项任务的CPU核心。与PyTorch DataLoader worker数密切相关--mem/--mem-per-cpu— 内存。只使用其中一个--gres=gpu:<타입>:<개수>— GPU
**无法使用未请求的资源。**因为是强制用cgroup，--gres=gpu:1收到后，如果想在代码中使用2张，第二张就完全看不见了。
阅读Q不动的理由的方法
安装排程器后，最常听到的话就是“我的工作不正常”。 Slump会用状态字符串告诉你原因，所以只要知道表格，大部分都可以自己解决。
squeue -u $USER -o "%.10i %.9P %.20j %.8T %.10M %R"
scontrol show job <작업번호> | grep -E 'JobState|Reason|NodeList'
| 理由 | 意思 | 大部分解决 |
|---|---|---|
Resources |
请求的资源现在不空 | 正在等待。减少请求会加快速度。 |
Priority |
前面有优先级高的工作 | 公正共享政策的问题 |
QOSMaxJobsPerUserLimit |
那个QoS的同步执行上限 | 绑定到阵列操作 |
AssocGrpCPUMinutesLimit |
账户的分配量用完了 | 给管理员 |
ReqNodeNotAvail |
该节点正在预约·停止中 | 解除节点指定 |
PartitionTimeLimit |
请求的时间比分区上限长 | --time减少 |
**要求越大，等待的时间就越长。**如果请求4台节点8小时，就会有相应的
等待出现空窗。backfill Scheduler 短小的工作
因为塞进缝隙里，所以，--time诚实地（虽然充足但不要过分）写出来的话
开始得要快得多。把上限写得尽可能高，这种习惯会让自己推迟。
节点是drain里面写着理由。
sinfo -R # drain 사유 목록
scontrol show node <노드> | grep -E 'State|Reason'
大部分是磁盘不足、GPU错误、健康检查失败。没有删除原因，只有节点 恢复的话，在下次检查中会再次被排除。
**如果工作停滞不前，不知道原因时，可以查看会计记录。**标准输出中没有任何内容。
没有留下消失的情况，sacct和结束代码一起OUT_OF_MEMORY我
TIMEOUT告诉你。
sacct -j <작업번호> --format=JobID,State,ExitCode,MaxRSS,Elapsed,ReqMem
MaxRSS去ReqMem粘在上面的话，是内存的原因。
在现场相遇的样子
**在家庭实验室中也有意义。**即使是两块GPU的服务器，如果要依次进行多次实验，则Scheduler会更好。如果放在队列中过夜，就会自动连续运行。而且这种经验会直接转化为大规模群集。
**节点掉入DRAIN。**如果检测到硬件错误或GRES不一致，Slurm会自动删除该节点。修复原因后scontrol update NodeName=... State=RESUME必须将其恢复到。不会自动返回——如果不知道这一点，一个节点就会玩几天。
在下次确认中看到的东西
在接下来的测验中，分区、白笔、资源请求分别做出什么样的日程安排决定。
先确认。通过那个标准后，从下一个模块开始slurm.conf撰写，GPU GRES定义，
按照顺序练习sbatch脚本和破损设置诊断。