내부 Job 로그: 문제가 발생했을 때 확인할 항목
Source: Dev.to
종료 코드
모든 작업은 종료 코드와 함께 끝납니다, 이는 발생한 일을 가장 간단히 알 수 있는 신호입니다.
0– 성공- 0이 아닌 값 – 실패
Slurm에서는 다음과 같은 형식을 자주 볼 수 있습니다:
ExitCode=1:0첫 번째 숫자는 작업의 종료 상태이며, 두 번째는 시그널입니다. 0이 아닌 시그널은 보통 강제 종료(예: kill 또는 크래시)를 의미합니다.
로그 위치
Slurm은 표준 출력 및 오류 스트림을 다음과 같은 파일에 기록합니다:
slurm-.out작업 스크립트에서 사용자 정의 경로를 지정할 수도 있습니다:
#SBATCH --output=job.out
#SBATCH --error=job.err이 파일들이 가장 신뢰할 수 있는 원본입니다.
- stdout – 일반 프로그램 출력
- stderr – 경고, 오류, 및 크래시
팁: 디버깅 시 항상 stderr를 먼저 읽으세요.
로그를 효율적으로 읽는 방법
흔히 저지르는 실수는 로그의 마지막 줄만 보는 것입니다. 근본 원인은 보통 더 앞에 나타납니다.
예시
File not found: input.dat
Segmentation fault (core dumped)세그멘테이션 오류는 결과일 뿐이며, 파일이 없다는 것이 실제 문제입니다.
메모리 관련 실패
메모리 문제는 시스템이 제한을 적용하는 방식에 따라 여러 형태로 나타납니다:
Out Of MemoryKilledoom‑kill event
Slurm에서는 다음과 같은 메시지를 볼 수 있습니다:
slurmstepd: error: Detected 1 oom‑kill event(s)이런 경우 작업이 할당된 메모리를 초과했을 가능성이 높습니다. --mem 옵션을 늘리거나 메모리 사용을 최적화하세요.
코드 및 환경 문제
코드나 환경에 문제가 있음을 나타내는 일반적인 메시지:
- Segmentation faults
- Python tracebacks
- Missing libraries (
libXYZ.so: cannot open shared object file) - Command not found (
module: not found)
이는 보통 다음을 의미합니다:
- 모듈 누락
- 환경 설정 오류
- 잘못된 소프트웨어 버전
조치: module load 명령과 환경 변수를 다시 확인하세요.
노드, I/O 및 스케줄러 문제
하드웨어 또는 파일시스템 문제를 암시하는 오류:
Block device requiredI/O errorNode unreachable
동일한 노드에서 여러 작업이 실패한다면 노드 수준의 문제일 가능성이 높습니다.
병렬 작업 함정
병렬 작업의 로그는 잡음이 많을 수 있습니다. 다음과 같은 패턴을 찾아보세요:
- 랭크별 실패
- 통신 오류
- 타임아웃
예시
MPI_ABORT was invoked
NCCL error: connection timed out이는 보통 네트워크 문제, 설정 오류, 혹은 라이브러리 버전 불일치를 의미합니다.
비효율 및 자원 제한
작업이 크래시하지는 않지만 제한이나 비효율에 부딪히는 경우도 있습니다:
- 작업이 정확히 할당된 시간 제한에 도달해 종료
- 시작이 느리거나 오래 대기하는 경우
- 랭크 간 자원 사용 불균형
sacct, seff 같은 Slurm 회계 도구를 사용하면 로그와 함께 이러한 문제를 파악할 수 있습니다.
일관된 디버깅 워크플로우
- 종료 코드 확인
stderr를 위에서 아래로 읽기- 첫 번째 실제 오류 식별 (하위 증상이 아니라)
- 자원 사용량 및 작업 설정과 연관짓기 (
sacct,seff) - 환경 및 의존성 확인 (모듈, 라이브러리 경로)
이 체계적인 접근 방식을 따르면 시간이 지남에 따라 패턴을 파악할 수 있어 디버깅이 더 빠르고 신뢰성 있게 됩니다.
요약
로그는 단순한 잡음이 아니라 무엇이 어떻게 잘못됐는지를 알려주는 구조화된 단서입니다. 로그를 이해하는 데 시간을 투자하면 추측을 줄이고 귀중한 HPC 자원을 절약할 수 있습니다.