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 메시지가 없었고, 멈춘 프로세스에 붙으려다 실패한 커널 스택만 있었다.
원인
원인 의존성 장애
- 촉발
- HPC 클러스터의 파일 시스템이 멈춰 응답하지 않게 됐다. 그때 node0 의 rank 0 프로세스가 로그를 쓰려고 부른 시스템 콜이 돌아오지 않았다.
감지
작성자가 마침 자리에 있다가 메인 로그가 더 써지지 않는 것을 보고 알아챘다. 파일 시스템이 원인이라는 것은 다음 날 시스템 관리자의 공지로 알았다.
조치
–
후속 조치
–
교훈
–
출처
관련 사례
같은 원인 · 공통 PyTorch
IL-0134AUS01 데이터센터에 전력 문제가 생겨 GPU 노드 246대와 스파인 스위치, VAST 스토리지가 한꺼번에 재부팅됐고, 워크로드가 실패하고 NFS 마운트가 끊겼다.Lambda · 2026 · sev1같은 원인 · 공통 공유 네트워크 파일 시스템
IL-0025H100 4,088개 클러스터를 구축하는 동안 InfiniBand 배선 오류, 링크 플래핑, GPU 와 PCIe 하드웨어 결함이 학습을 멈추거나 늦췄다Imbue · 2024같은 원인 · 공통 PyTorch
같은 원인 · 공통 공유 네트워크 파일 시스템
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0426
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0426/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.