Incident Library

IL-0426 Hugging Face · 2023-03-04ai-infra

64 GPU 학습이 3.5시간 뒤 멈췄고 30분 c10d 타임아웃이 지나도 끝나지 않았다

실험 3.1 은 8개 노드의 GPU 64개로 pt-1.12, `CUDA_LAUNCH_BLOCKING=1`, num_workers=2 설정에서 돌았다. 학습은 3.5시간쯤 지나 멈췄다. node0 의 rank 0 프로세스가 uninterruptible sleep 상태에 빠져 응답하지 않았고, 나머지 프로세스는 barrier 에서 그 프로세스를 기다렸다. c10d 는 30분 타임아웃이 지나도 작업을 중단하지 않아서 작업은 끝없이 멈춰 있었다.

작성자는 py-spy 로 모든 노드를 덤프해 jean-zay-iam06 을 찾았고, nvidia-smi 로 GPU 0 의 PID 280058 을 찾았다. 이 프로세스에는 strace 와 py-spy 를 붙일 수 없었고 ps 상태는 `Dl` 이었다. 작성자는 노드를 재부팅하는 것 말고는 이 프로세스를 어떻게 할 방법이 없다고 판단했다. GPU 의 온도, ECC 오류, 커널 로그에는 이상이 없었다.

다음 날 시스템 관리자가 파일 시스템에 큰 장애가 있었다고 알렸다. 파일 시스템이 멈춰 응답하지 않는 동안 rank 0 프로세스가 로그를 쓰려 했고, 그 시스템 콜이 돌아오지 않아 프로세스가 uninterruptible sleep 상태에 빠졌다. 이 프로세스 하나 때문에 학습 전체가 멈췄다.

심각도
–
영향 범위
A 64-GPU training run on 8 Jean Zay nodes hung indefinitely; the stuck rank 0 process on jean-zay-iam06 could only be cleared by rebooting the node
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

8개 노드의 GPU 64개로 돌던 학습이 3.5시간쯤 지나 멈췄다. 메인 로그가 더는 써지지 않았고, 30분짜리 c10d 타임아웃이 지나도 작업이 중단되지 않고 계속 멈춰 있었다.

메인 로그의 마지막 줄들은 `PID 280058: After clip in _do_batch` 같은 줄이었다. 마지막으로 돈 단계는 그래디언트 클리핑이었다.

py-spy 로 8개 노드의 프로세스를 덤프하자 응답한 프로세스는 모두 `barrier (torch/distributed/distributed_c10d.py:2784)` 에서 기다리고 있었다. 덤프 뒤에 `sleep 3` 을 넣어 다시 돌리자 다른 노드는 모두 프로세스 8개가 barrier 에 있었고 jean-zay-iam06 만 모자랐다. 그 노드에서는 프로세스 하나의 덤프가 `Error: Failed to suspend process` 와 `Reason: EPERM: Operation not permitted` 로 실패했다.

jean-zay-iam06 의 nvidia-smi 에서 GPU 7개는 사용률 100% 였고 GPU 0 만 0% 였다. GPU 0 의 프로세스는 PID 280058 이었다. 정상 프로세스에 strace 를 붙이면 nvidiactl 장치를 ioctl 로 폴링하는 것이 보였지만, 280058 에 붙이면 `strace: attach: ptrace(PTRACE_SEIZE, 280058): Operation not permitted` 가 났다. ps 의 STAT 칸에서 280058 만 `Dl` 이었고 나머지는 `Rl` 이었다. STAT 의 D 는 대개 IO 를 기다리는 uninterruptible sleep 상태를 뜻한다.

같은 멈춤이 다른 노드에서도 되풀이됐기 때문에, 작성자는 처음에 소프트웨어 문제로 보고 멈춤을 일으키는 계기를 찾았다. GPU 0 자체는 정상으로 보였다. 온도는 28 C 였고 ECC 오류는 0 이었다. 클럭은 1155 MHz 로 다른 GPU 의 1410 MHz 보다 낮았지만, 사용률이 0% 라서 GPU 가 스스로 클럭을 낮춘 것일 수 있다고 봤다. `dmesg -H` 에는 그 시각 전후로 NVRM 이나 nvidia 메시지가 없었고, 멈춘 프로세스에 붙으려다 실패한 커널 스택만 있었다.

증상 학습 작업 실패NCCL 타임아웃

원인

촉발
HPC 클러스터의 파일 시스템이 멈춰 응답하지 않게 됐다. 그때 node0 의 rank 0 프로세스가 로그를 쓰려고 부른 시스템 콜이 돌아오지 않았다.

감지

작성자가 마침 자리에 있다가 메인 로그가 더 써지지 않는 것을 보고 알아챘다. 파일 시스템이 원인이라는 것은 다음 날 시스템 관리자의 공지로 알았다.

조치

–

후속 조치

–

교훈

–

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 공유 네트워크 파일 시스템, PyTorch. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.