Linux 서버를 운영하다 보면 커널 로그에 Hard LOCKUP, NMI watchdog: Watchdog detected hard LOCKUP과 같은 메시지가 출력되는 경우가 있습니다. Hard Lockup은 Soft Lockup보다 훨씬 심각한 장애로, CPU가 인터럽트조차 처리하지 못하는 상태를 의미합니다.
이 문제가 발생하면 시스템이 완전히 멈추거나 SSH 접속이 불가능해지고, 키보드 입력에도 반응하지 않는 경우가 많습니다. 특히 데이터베이스 서버나 가상화 서버에서는 서비스 전체가 중단될 수 있으므로 빠른 원인 분석이 필요합니다.
이번 글에서는 Linux Hard Lockup의 원인과 실무에서 사용하는 진단 및 해결 방법을 자세히 알아보겠습니다.
Hard Lockup이란 무엇인가?
Hard Lockup은 CPU가 일정 시간 이상 인터럽트를 처리하지 못하는 상태를 말합니다.
Linux의 NMI(Non-Maskable Interrupt) Watchdog이 CPU 응답을 감시하다가 일정 시간 이상 인터럽트가 발생하지 않으면 Hard Lockup을 감지합니다.
대표적인 로그는 다음과 같습니다.
NMI watchdog: Watchdog detected hard LOCKUP on cpu 3
또는
BUG: hard LOCKUP - CPU#1 stuck for 23s
이 상태에서는 운영체제가 정상적으로 작업을 수행하기 어렵습니다.
Hard Lockup이 발생하는 대표적인 원인
다음과 같은 경우에 자주 발생합니다.
- CPU 하드웨어 오류
- 커널 버그
- 무한 루프에 빠진 커널 코드
- 인터럽트 처리 실패
- BIOS 문제
- CPU 과열
- 메모리(ECC) 오류
- 잘못된 디바이스 드라이버
- 가상화(Hypervisor) 문제
- 오래된 펌웨어
실무에서는 CPU와 하드웨어 상태를 가장 먼저 확인해야 합니다.
1. 커널 로그 확인하기
Hard Lockup 로그를 확인합니다.
dmesg | grep -i "hard lockup"
또는
journalctl -k | grep -i "hard lockup"
Watchdog 관련 메시지도 함께 확인합니다.
dmesg | grep -i watchdog
2. Call Trace 분석하기
Hard Lockup에는 대부분 Call Trace가 함께 출력됩니다.
journalctl -k | grep -A 50 "Call Trace"
또는
dmesg | grep -A 50 "Call Trace"
CPU가 어떤 함수에서 멈췄는지 확인합니다.
3. CPU 상태 확인하기
CPU 사용률을 확인합니다.
top
또는
mpstat -P ALL 1
CPU 하나만 사용률이 100%로 고정되어 있는지도 확인합니다.
4. Load Average 확인하기
uptime
또는
cat /proc/loadavg
Load Average가 CPU 개수보다 훨씬 높다면 CPU 병목이 발생했을 가능성이 있습니다.
5. 인터럽트 상태 확인하기
인터럽트 처리 상태를 확인합니다.
cat /proc/interrupts
특정 CPU에 인터럽트가 몰려 있거나 인터럽트 증가가 멈춘 경우를 확인합니다.
6. 하드웨어 이벤트 로그 확인하기
서버에서는 BMC/IPMI 로그를 반드시 확인합니다.
ipmitool sel list
다음 항목을 확인합니다.
- CPU Error
- ECC Error
- Machine Check Exception
- Thermal Event
- Power Failure
이 정보는 Hard Lockup의 원인을 파악하는 데 매우 중요합니다.
7. CPU 온도 확인하기
CPU 과열 여부를 확인합니다.
sensors
또는
ipmitool sdr
온도가 비정상적으로 높다면 냉각 시스템을 점검해야 합니다.
8. 커널 버전 확인하기
uname -r
커널 업데이트 직후 발생했다면 버그 여부를 확인합니다.
RPM 계열
rpm -qa | grep kernel
Debian 계열
dpkg -l | grep linux-image
필요하면 이전 커널로 부팅하여 비교합니다.
9. Crash Dump 분석하기
kdump가 활성화되어 있다면 Crash Dump를 확인합니다.
ls /var/crash
분석
crash vmcore
Crash Dump는 Hard Lockup 당시의 CPU 상태와 커널 정보를 확인하는 데 매우 유용합니다.
10. BIOS 및 펌웨어 확인하기
오래된 BIOS나 CPU 마이크로코드도 Hard Lockup을 유발할 수 있습니다.
다음 항목을 확인합니다.
- BIOS 최신 버전
- CPU Microcode
- RAID Firmware
- BMC Firmware
운영 서버에서는 제조사 권장 버전을 사용하는 것이 좋습니다.
Hard Lockup 문제를 확인하는 순서
실무에서는 다음 순서대로 점검하는 것이 효율적입니다.
dmesg확인journalctl -k확인- Call Trace 분석
- CPU 사용률 확인
- Load Average 확인
- 인터럽트 확인
- IPMI 로그 확인
- CPU 온도 확인
- Crash Dump 분석
- BIOS 및 펌웨어 확인
이 순서대로 점검하면 대부분의 원인을 빠르게 파악할 수 있습니다.
Soft Lockup과 Hard Lockup의 차이
| 구분 | Soft Lockup | Hard Lockup |
|---|---|---|
| CPU 상태 | 스케줄링 지연 | 인터럽트 처리 불가 |
| 시스템 응답 | 일부 가능 | 대부분 불가능 |
| SSH 접속 | 가능한 경우 있음 | 대부분 불가능 |
| 심각도 | 높음 | 매우 높음 |
| 주요 원인 | CPU 과부하, 커널 코드 | 하드웨어, 커널, 인터럽트 |
Hard Lockup은 Soft Lockup보다 훨씬 심각한 상태이므로 즉시 원인 분석이 필요합니다.
Hard Lockup을 예방하는 방법
다음과 같은 관리 방법을 권장합니다.
- BIOS 및 펌웨어 최신 상태 유지
- 커널 안정 버전 사용
- CPU 온도 모니터링
- ECC 메모리 사용
- RAID 및 스토리지 점검
- 정기적인 하드웨어 진단
- Watchdog 활성화
- 서버 내부 먼지 및 냉각 상태 점검
특히 장시간 고부하 서버에서는 CPU 온도와 하드웨어 이벤트 로그를 정기적으로 확인하는 것이 중요합니다.
자주 묻는 질문
Hard Lockup이 발생하면 재부팅만 하면 되나요?
재부팅으로 일시적으로 복구될 수 있지만, 커널 버그나 하드웨어 문제가 원인이라면 다시 발생할 가능성이 높습니다.
Hard Lockup은 CPU 불량 때문인가요?
CPU 불량도 원인이 될 수 있지만, 커널 버그, BIOS, 드라이버, 메모리 오류 등 다양한 원인이 있으므로 로그를 종합적으로 분석해야 합니다.
Soft Lockup보다 더 위험한가요?
네. Hard Lockup은 CPU가 인터럽트조차 처리하지 못하는 상태이므로 일반적으로 Soft Lockup보다 훨씬 심각한 장애로 분류됩니다.
마무리
Hard Lockup은 Linux 서버에서 가장 심각한 CPU 관련 장애 중 하나입니다. dmesg, journalctl, Call Trace, ipmitool, sensors, crash 등을 활용하면 원인을 체계적으로 분석할 수 있습니다. 특히 하드웨어 로그와 CPU 온도, BIOS 버전까지 함께 확인하면 재발 방지와 장애 대응에 큰 도움이 됩니다.