[Slurm] 노드 not responding 문제
팀에서 운영하던 GPU 클러스터에서 노드들이 간헐적으로 통신이 되지 않는 문제가 있었다.
Idle*, drain*, down* 이런식으로 떠있는 노드들이 종종 발생하였고, 이로 인해 노드와 통신이 되지 않으면서 prolog error 및 학습이 종료되었다. prolog error는 job 종료하자마자 바로 학습을 재시작했을 때 발생하는 경우였는데, 이번에는 로그를 확인했을 때 노드와 connection이 맺어지지 않으면서 prolog 스크립트를 실행하지 못해서 발생하였다.
왜.. 커넥션이...되지 않았을까? ㅂㄷㅂㄷ..
Idle* drain* down* 이 뜨는 이유...
* 이 뜨는 이유는 서버가 unreachable 상태일때 발생한다. * 상태에서 지속되면 노드가 drain상태가 된다. drain상태가 되면 노드를 더이상 학습에 투입시킬 수 없게 된다. down*은 slurmd와 더이상 통신할 수 없을 때 down 상태가 되고 거기에 노드까지 연결이 되지 않으면 down* 상태가 된다.
발생한 로그
Slurm 노드에서는 failed to _forward_thread No route to host 가 발생하고 slurm 컨트롤러 노드에서는 not responding, now responding 로그가 남은 상태였다.
해결방안
로그가 너무 간략해서 원인파악을 하는게 힘들었다. Slurm 클러스터를 여러 사용자가 사용하고 있는데 최근들어 job 사용패턴이 달라지고 gpu, cpu를 많이 사용하는 작업들을 실행했다. 또한 array job을 실행하면서 여러 thread를 생성하는 작업을 실행했다.
1. Timeout 설정 조정
Slurm의 경우에는 작업 실행시 그 작업의 리더 노드가 배정되고 이 리더노드가 노드들의 작업 상태나 healthcheck 결과를 취합해서 컨트롤러로 보내는 역할을 한다. CPU 사용량이 높은 경우 healthcheck에 응답을 할 수 없어 timeout내로 응답하지 못하는건 아닐까라는 생각으로 아래 파라미터를 조정했다
MessageTimeout 60
SlurmdTimeout 300
SlurmctldTimeout 120
MessageTimeout은 hc 메시지를 보냈을 때 그에 대한 응답이 올때까지 얼만큼 기다릴지를 의미한다. 기본값은 10이므로 60까지 조정하였다.
SlurmdTimeout은 slurmd가 응답하지 않을때 얼만큼 기다릴건지를 의미한다. 그 안에 응답이 오지 않으면 해당 노드는 down 상태가 된다. 기본값이 300초다
SlurmctldTimeout는 설정한 시간 내로 응답이 없으면 backup controller가 primary가 된다. 120초가 기본값이다. 컨트롤러가 바쁠경우 120초 내로 응답이 오지 않을 수 있고 잦은 controller 전환이 더 slurm controller에 영향을 미칠것으로 생각되어 120초로 두었다.
위 timeout 값들을 조정한 후에 drain* down*까지 떨어지는 노드들은 없었지만... array job을 돌리는 경우 동일 문제가 재발하였다.
2. ARP cache 커널 파라미터 조정
커널의 기본 arp cache 값은 512이다. Arp cache는 ip랑 mac주소를 맵핑시켜 저장해놓은 캐시이다. 이 ARP cache가 꽉 차는 경우 즉, 512가 되는경우에는 arp cache entry를 삭제하는데 이 때 간헐적으로 통신이 끊길 수 있다.
cat /proc/net/arp | wc -l 로 확인했을 때 512는 충분히 넘었고 256대 서버 * 10 (ib마다 arp cache에 등록되는듯)하면 이미 2560이다. 너무 부족한 값으로 확인된다. 아래 값들을 그래서 조정하였다.
net.ipv4.neigh.default.gc_stale_time 60 -> 3600
net.ipv4.neigh.default.gc_thresh1 128 -> 8192
net.ipv4.neigh.default.gc_thresh2 512 -> 16384
net.ipv4.neigh.default.gc_thresh3 1024 -> 16384
gc_stale_time은 stale한 상태로 간주하기까지 걸리는 시간을 의미한다. 오래되었다 하면 arp entry 삭제함. 기본 60초는 짧은 것으로 생각되어 3600초로 증가
gc_thresh1 이 값보다 낮으면 GC를 전혀 실행하지 않는다. GC를 실행하기 위한 최소값으로 보면 된다. 기본 128에서 8192로 증가하였다.
gc_thresh2 는 soft limit으로 생각하면 되는데 커널이 가비지 컬렉션을 적극적으로 시도하기 시작하는 한계치로 보면 된다. 약간 초과해도 문제는 생기지 않는데 GC의 빈도가 높아진다. 기본 512에서 16384로 설정하였다.
gc_thresh3은 더 이상 엔트리를 추가할 수 없을 정도로 꽉 찬 경우 설정하는 hard limit이다. 기본 1024에서 16384로 증가하였다.
arp cache의 gc로 인해 간헐적인 통신이 되지 않을 수 있다는 사실을 처음 알았고.. 나중에 비슷한 경우가 생기는 경우 튜닝 포인트로 생각해봐도 좋을 듯 하다.