연구과제로 모델을 훈련시키는 데 잘 돌아가다가 evaluation step에서 사진과 같이 갑자기 중단되었다. SIGTERM, Cuda out-of-memory 오류도 뜨지 않고 Killed 라고만 떠서 설마 또 해커가 침입해서 프로세스를 죽인 건지 당황스러웠는데 찾아보니 그건 아니었다.
# 둘 중 하나의 명령어로 프로세스가 죽은 것을 확인할 수 있다
dmesg
cat /var/log/syslog 알고보니 프로그램의 virtual memory consumption이 매우 크고, 따라서 동작이 매우 느린 경우 예외적으로 커널이 mem+swap 부족으로 우선순위에 따라 강제로 프로세스를 종료할 수도 있는 것이었다. (시스템 프로그래밍 좀 열심히 들을 걸...) 내가 훈련시키던 모델의 경우, 연구과제의 데이터들이 기하급수적으로 늘어나면서 단순히 8:1:1로 나누기에는 valid set이 너무 커져 있었다. 예전의 경험을 참고하여 eval_accumulation_steps를 설정해놓았었는데, 덕분에 GPU에는 문제가 없었지만 GPU <==> CPU 통신 과정에서 RAM 부담이 너무 컸던 것으로 보인다.
이 경우 다음 3가지 방법이 있는 것으로 보인다.
- RAM 크기 늘리기 (내 서버도 아니고 VM도 아니라 나의 경우 불가능.)
- OOM Killer이 다른 프로세스를 고르도록 변경
- OOM Killer 무효화시키기
- 코드를 memory-efficient하게 다시 짜기
그러나 커널을 건드리고 싶지는 않았고, 단순히 데이터 양의 문제였기 때문에 valid set을 확 줄이고 다시 훈련시켰다.
유용한 사이트:
1. https://stackoverflow.com/questions/726690/what-killed-my-process-and-why
2. https://www.baeldung.com/linux/what-killed-a-process
3. https://anencore94.github.io/2020/09/29/disable-oom-killer.html
4. https://medium.com/@EJSohn/out-of-memory-killer-%ED%9A%8C%ED%94%BC%ED%95%98%EA%B8%B0-9efc65f88c92
5. https://redpanda.com/blog/solve-out-of-memory-killer-events
6. https://gist.github.com/t27/ad5219a7cdb7bcb977deccbc48a480d5
7. https://stackoverflow.com/questions/18423762/python-script-gets-killed-by-oom-killer
8. https://unix.stackexchange.com/questions/614950/python-programs-suddenly-get-killed
