Cases2 cases

1 to 2 of 2

1. IL-0411 Lemon nodes in Meta's RSC-1 and RSC-2 GPU clusters failed job after job without being caught by health checks

   Meta2024

   Symptoms

   In Meta's RSC-1 and RSC-2 research GPU clusters, certain nodes had above-average rates of job failures. After each failure the same nodes kept attracting new jobs and failing them too, while health checks and repair workflows did not flag them. Meta calls these servers lemon nodes.

   Training job failure

   Root cause

   Hardware failure

   Component

   GPU hardware and memorySlurm job scheduler

   Contributing factor

   Monitoring blind spot

   Detection

   Meta's lemon detection flags nodes from their history in per-node signals such as excl_jobid_count, xid_cnt, tickets, out_count and node failure counts, because the periodic health checks and repair workflows did not catch them.

   Remediation

   • Built lemon detection to proactively identify, isolate and replace lemon nodes in the Slurm scheduler
   • Identified 40 faulty nodes, 24 on RSC-1 and 16 on RSC-2

   Lessons

   Finding defective nodes needs historic data, and lemon node detection can improve the completion rate of large jobs by over 30%. A defective node that cannot be removed from capacity leads to restart loops that make large gang-scheduled jobs impossible to run, so recovery from random failures only works once defective nodes are reliably rotated out.

   View case
2. IL-0427 A GPU with uncorrectable ECC errors crashed tr1-13B training, and Slurm's next job went to the same node and crashed too

   BigScience2021

   Symptoms

   After many hours of training, one job of the tr1-13B Slurm job array crashed at iteration 43680 of 311541 during the backward pass. The next job in the array started by itself and crashed right away, before training began.

   Training job failureGPU unavailable

   Trigger

   One GPU on one node of the allocation developed a hardware problem that produced uncorrectable ECC errors.

   Root cause

   Hardware failure

   Component

   GPU hardware and memorySlurm job scheduler

   Contributing factor

   Automation amplificationMonitoring blind spot

   Detection

   Nobody was around to notice the first crash, and the Slurm scheduler started the next job in the array on its own, which crashed too.

   Remediation

   • Contacted the JZ administrators, who confirmed one of the nodes was faulty
   • Continued training with the next job, which was not placed on the faulty node

   Action items

   • Add %N to the Slurm output setting (#SBATCH --output=%x-%j-%N.out) so each node writes its own log file and the node with a corrupt GPU can be identified
   • Exclude a node known to be faulty from the allocation with sbatch --exclude

   Lessons

   Without a way to link an exception to the hostname of the node that raised it, the scheduler can keep placing the training on the faulty node and the training keeps crashing; per-node log files make the faulty node visible so it can be excluded.

   View case

By root cause1