Linux Hard Lockup 오류가 발생하는 원인과 해결 방법

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 문제를 확인하는 순서

실무에서는 다음 순서대로 점검하는 것이 효율적입니다.

  1. dmesg 확인
  2. journalctl -k 확인
  3. Call Trace 분석
  4. CPU 사용률 확인
  5. Load Average 확인
  6. 인터럽트 확인
  7. IPMI 로그 확인
  8. CPU 온도 확인
  9. Crash Dump 분석
  10. BIOS 및 펌웨어 확인

이 순서대로 점검하면 대부분의 원인을 빠르게 파악할 수 있습니다.

Soft Lockup과 Hard Lockup의 차이

구분Soft LockupHard 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 버전까지 함께 확인하면 재발 방지와 장애 대응에 큰 도움이 됩니다.

댓글 남기기