사례2건

2건 중 1~2번째

1. IL-0428 GPU 320~384개로 돌린 대형 모델 시험 학습이 멈추고 그때마다 노드가 내려갔다

   BigScience2022

   증상

   A100 GPU 320~384개로 돌린 대형 모델 시험 학습이 멈췄다. 몇몇 GPU 가 무작위로 응답하지 않았고 시스템 전체가 타임아웃이 날 때까지 멈춰 있었다. 멈출 때마다 노드 몇 대가 내려갔다.

   학습 작업 실패NCCL 타임아웃GPU 인식 불가노드 NotReady

   촉발

   100B 이상 모델을 20~40개 노드에 걸쳐 돌려 노드 사이 NCCL 트래픽이 어느 수준을 넘으면 멈춤이 시작됐다.

   원인

   unknown

   구성 요소

   NCCLPyTorch

   기여 요인

   디버그 접근 제한

   조치

   • `CUDA_LAUNCH_BLOCKING=1` 을 설정하자 멈춤이 사라졌다. 성능을 여러 번 확인해 보니 이 규모에서는 속도 저하가 거의 없었고, 팀은 이 우회책을 당분간 쓰기로 했다.

   교훈

   멈춘 프로세스가 어디서 멈췄는지 알려면 py-spy 로 모든 프로세스의 호출 스택을 뜨거나 파이썬 trace 모듈로 모든 호출을 기록할 수 있다. trace 를 켜면 속도는 느려졌지만 멈춤은 그대로 일어났다. 작성자는 trace 가 멈춘 프로세스를 디버깅하는 데 아주 쓸모 있었다고 봤다. 다만 처음부터 추적하면 데이터 로더와 준비 코드의 쓸모없는 기록까지 쌓이므로 `train_step` 바로 앞에서 추적을 시작하는 편이 나았다. 멈춘 작업을 살피는 두 번째 `srun` 에는 `--gres=gpu:0` 을 줘야 첫 `srun` 이 끝날 때까지 막히지 않는다. 먼저 `salloc` 으로 GPU 를 잡아 두면 SLURM 이 프로세스를 죽여도 그 노드에 들어갈 수 있다.

   사례 보기
2. IL-0402 GKE 노드가 고장 나 NodeLost 가 된 JupyterHub 파드가 hub DB 의 PVC 를 놓지 않아 mybinder.org 가 몇 시간 동안 새 사용자를 받지 못했다

   Binder Project2018

   증상

   2018년 3월 13일 07:28 CET 에 mybinder 의 launch 성공률이 몇 시간째 0인 것을 Grafana 대시보드에서 알아챘다. JupyterHub 가 새 사용자를 하나도 받지 못하고 있었다.

   서비스 중단노드 NotReady파드 Terminating 정체파드 ContainerCreating 정체

   원인

   unknown

   구성 요소

   영구 볼륨과 스테이트풀셋노드 풀

   기여 요인

   온콜 호출 미전달

   감지

   07:28 CET 에 mybinder 의 launch 성공률이 몇 시간째 0인 것을 Grafana 대시보드에서 알아챘다. Stackdriver 알림 메일은 오지 않았다. Stackdriver 메일은 스팸으로 분류되곤 했고 알림이 몇 시간 늦게 도착했다.

   조치

   • 07:33 에 상태가 나쁜 노드를 cordon 했다.
   • Unknown 상태의 hub 파드와 5시간째 ContainerCreating 이던 두 번째 hub 파드를 지워, 정상 노드에 다시 스케줄되는지 봤다.
   • GCP 웹 화면에서 노드 gke-prod-a-ssd-pool-32-134a959a-n2sk 를 손으로 reset 해 PVC 를 강제로 풀려고 했다. 08:05 에 새 hub 파드가 다른 노드에 떠 실행됐다.
   • 13:34 에 kubectl --namespace=prod delete pod <pod-name> --grace-period=0 --force 로 Unknown, NodeLost 상태 파드를 모두 강제 삭제했고, 그 파드에서 돌던 서비스들이 회복했다.

   후속 조치

   • 장애가 왜 시작됐는지 조사한다. 문제를 일으킨 파드가 있었는지, GCE 장애였는지 Stackdriver 로그와 Google Cloud 장애 공지를 살핀다.
   • Stackdriver 가 아닌 알림 서비스를 두어 이런 문제를 더 일찍 잡는다. 이 일은 지금 #365 에 막혀 있다.
   • PVC 가 풀리지 않았는지 확인하는 방법을 문서로 남겨, 다음에 이 문제를 빨리 알아볼 수 있게 한다.
   • 명령이 대부분 통하지 않을 때 노드를 손으로 재시작하는 방법을 문서로 남긴다.
   • Unknown 상태가 된 파드를 지우는 방법을 문서로 남긴다. 이 문서는 #512 에서 다룬다.

   교훈

   문제를 찾은 뒤에는 조치를 잘 기록했고, 필요에 따라 더 강한 조치로 빠르게 넘어가서 hub 가 멈춘 시간은 짧았다. 오류를 알아채기까지는 꽤 오래 걸렸다. Stackdriver 메일이 오지 않았는데, Stackdriver 메일은 스팸으로 분류되고 알림이 몇 시간 뒤에야 도착했다.

   사례 보기

원인별1