HPC 운영에서 프로세스 관리가 중요한 이유
HPC 클러스터 운영에서 가장 기본이자 동시에 가장 중요한 관리 포인트 중 하나가 바로 프로세스 관리입니다.
Job 스케줄러(Slurm 등)가 노드에 작업을 배치하면, 결국 각 Job은 개별 프로세스 단위로 실행됩니다. 하지만 예상치 못한 상황 – 무한 루프, 메모리 누수, 잘못된 자원 할당 – 이 발생하면, 해당 Job은 단순히 “사용자 Job 실패”로 끝나는 것이 아니라 전체 노드의 성능 저하를 초래할 수 있습니다.
따라서 운영자는 ps, top, htop 같은 기본 프로세스 관리 도구를 능숙하게 다루어야 하며, 이를 통해 시스템 자원 사용 상태를 실시간으로 파악하고 문제 프로세스를 빠르게 식별할 수 있어야 합니다.
ps – 정적인 프로세스 상태 확인
ps는 가장 단순하면서도 강력한 프로세스 확인 도구입니다. 특정 시점의 프로세스 정보를 정적으로 출력하여, 원하는 필터링 조건을 붙이면 원인 분석의 기초 데이터로 활용할 수 있습니다.
자주 쓰는 명령어
# 현재 사용자 프로세스 확인
ps -u $USER
# 전체 프로세스 확인 (모든 사용자 포함)
ps -ef
# 메모리 사용량 기준 정렬
ps aux --sort=-%mem | head -10
# CPU 사용률 높은 프로세스 TOP10
ps aux --sort=-%cpu | head -10
HPC 운영 포인트
- 특정 Job이 Slurm에선 “RUNNING” 상태인데 실제 CPU 사용이 전혀 없는 경우, ps로 프로세스가 살아 있는지 바로 확인 가능합니다.
- MPI Job 실행 시 rank별 프로세스가 모두 뜨는지 확인할 때 유용합니다.
top – 실시간 시스템 모니터링
top은 시스템의 CPU, 메모리, load average, 프로세스 상태를 실시간으로 보여주는 도구입니다. HPC 노드에서는 Job 실행 중 CPU 코어가 균등하게 사용되는지, 특정 프로세스가 리소스를 독점하는지 확인할 때 필수적으로 활용됩니다.
주요 화면 해석
- load average: 1분, 5분, 15분 평균 부하를 나타내며, CPU 코어 수보다 현저히 높으면 과부하 상태를 의미합니다.
- %CPU: 개별 프로세스가 차지하는 CPU 비율. 멀티스레드 Job은 100%를 넘을 수 있습니다.
- %MEM: 프로세스 메모리 점유율. 메모리 누수 진단에 활용됩니다.
HPC 운영 포인트
- GPU Job이 정상적으로 CPU 자원을 요청했는지 확인할 수 있습니다. 예를 들어 GPU를 사용하지만 CPU 자원 요청을 잘못 지정해 불필요하게 다른 Job 실행을 막는 경우를 쉽게 잡아낼 수 있습니다.
- I/O 대기(wa 값)가 높게 표시된다면, 네트워크 스토리지 병목 문제로 이어질 가능성을 의심해야 합니다.
htop – 직관적인 시각화 모니터링
htop은 top을 대체하는 시각화 툴로, 색상과 인터페이스가 추가되어 한눈에 시스템 상태를 파악할 수 있습니다. HPC 운영자 입장에서는 멀티코어·멀티소켓 CPU 구조에서 자원 분포를 확인할 때 특히 유리합니다.
장점
- CPU 코어별 사용률이 색상 막대 그래프로 표시 → NUMA 노드 간 불균형 확인 가능
- 마우스/키보드로 프로세스 검색 및 종료 가능
- 스레드 단위로 세부 모니터링 가능
HPC 운영 포인트
- 병렬 Job이 실행될 때 코어 활용도가 균등한지 즉시 확인 가능합니다.
- 특정 Job이 전체 코어 중 일부만 사용하는 현상 → 스케줄러 설정 오류나 Job 스크립트 문제로 빠르게 추적할 수 있습니다.
- 운영자가 Job을 강제로 kill해야 할 때 직관적인 인터페이스를 제공하여 ps + kill 조합보다 편리합니다.
세 도구 비교
| 구분 | ps (정적) | top (실시간) | htop (시각화 실시간) |
| 출력 특성 | 한 시점 스냅샷 | 실시간 업데이트 | 실시간 + 인터페이스 |
| 주요 활용 | 특정 프로세스 식별 | 부하 및 자원 모니터링 | 직관적 시각화, 코어별 확인 |
| 장점 | 간단, 필터링 다양 | 표준 툴, 해석 용이 | 직관적, 조작 편리 |
| 한계 | 변화 추적 불가 | UI 한계, 검색 어려움 | 별도 설치 필요 |
HPC 운영 사례
반도체 시뮬레이션 클러스터에서 사용자 Job이 “계속 돌아간다”는 민원이 접수된 적이 있었습니다.
- Slurm 상에서는 RUNNING 상태였지만, ps 확인 결과 해당 Job 프로세스는 이미 종료된 상태였습니다. 이는 스케줄러와 노드의 상태 싱크가 맞지 않는 경우였습니다.
- 다른 사례에서는 특정 노드에서 load average가 항상 높게 유지되어 top을 확인했더니, 한 사용자의 잘못된 Job이 무한 루프를 돌며 CPU를 100% 점유하고 있었습니다.
- 마지막으로, 대규모 CFD 시뮬레이션 실행 중 일부 MPI 프로세스만 CPU를 활용하지 않는 현상이 발생했는데, htop으로 확인한 결과 NUMA 바인딩 문제였습니다. 이후 Slurm 설정을 수정하여 균등하게 자원 배분되도록 개선했습니다.
실무 팁
- 정적 확인 → 동적 확인: 먼저 ps로 문제가 되는 프로세스를 확인한 후, top/htop으로 상태를 추적하는 방식이 가장 효과적입니다.
- Slurm와의 연계: Slurm에서 할당된 JobID와 ps 출력 결과를 매핑하여 관리하면, 사용자 요청 대응이 빨라집니다.
- 자동화: 반복적인 모니터링은 Ansible/cron과 연계하여 특정 기준(load average > 10 등)에 도달하면 관리자에게 알림을 주도록 설정하는 것이 좋습니다.
- GPU Job 확인: ps로 CUDA 관련 프로세스(python, nvidia-smi로 매칭)를 확인하면 GPU 자원과의 연계 문제를 쉽게 추적할 수 있습니다.
정리하며
HPC 운영자는 단순히 “Job이 잘 실행된다”는 수준을 넘어, 프로세스 단위에서 자원 활용을 이해하고 관리할 수 있어야 합니다.
- ps로 정적인 상태를 확인하고,
- top으로 실시간 자원 부하를 관찰하며,
- htop으로 직관적인 코어 활용도를 점검하는 것,
이 세 가지를 조합하면 HPC Job 실행 안정성과 자원 효율성을 극대화할 수 있습니다.
운영 현장에서 이 도구들은 단순 모니터링 이상의 의미를 가지며, HPC 클러스터의 안정성과 신뢰성을 지탱하는 기본 도구라 할 수 있습니다.