리눅스에서 CPU, Memory 점검 가이드

리눅스에서 CPU와 메모리를 점검할 때는 단순히 사용률 숫자만 보면 안 됩니다. CPU가 바쁜 것인지, I/O wait 때문에 느린 것인지, 메모리 부족으로 swap이 발생하는지, 특정 프로세스가 자원을 독점하는지를 분리해서 봐야 합니다. 장애 대응 중 바로 사용할 수 있도록 실시간 확인, 프로세스별 확인, 과거 통계 확인 순서로 정리합니다.

먼저 남겨야 할 기본 스냅샷

장애 시점에는 명령 결과를 나중에 비교할 수 있게 시간, 호스트, 부하, CPU 개수, 메모리 용량을 먼저 남기는 것이 좋습니다.

date
hostnamectl 2>/dev/null || hostname
uptime
nproc
lscpu | egrep 'Model name|CPU\\(s\\)|Thread|Core|Socket|NUMA'
free -h
swapon --show

uptime의 load average는 CPU 사용률이 아니라 실행 대기열의 평균입니다. CPU 2개인 서버에서 load average가 2 근처면 꽉 찬 상태에 가깝고, CPU 16개인 서버에서 2라면 여유가 있는 편입니다. 그래서 load average는 반드시 nproc 결과와 같이 봐야 합니다.

top으로 실시간 상태 보기

top

top에서는 다음 항목을 우선 봅니다.

top 실행 중에는 P로 CPU 사용률 정렬, M으로 메모리 사용률 정렬, 1로 CPU 코어별 보기, q로 종료할 수 있습니다.

vmstat으로 CPU 대기와 swap 확인

vmstat 1 10

vmstat은 1초 간격으로 10번 찍어 흐름을 보는 명령입니다. 첫 줄은 부팅 이후 평균일 수 있으므로 두 번째 줄부터 보는 편이 안전합니다.

mpstat으로 코어별 CPU 확인

mpstat은 sysstat 패키지에 포함됩니다. 전체 CPU 평균만 보면 특정 코어에 몰린 병목을 놓칠 수 있으므로 코어별로 확인합니다.

# RHEL/CentOS
sudo yum install -y sysstat

# Ubuntu/Debian
sudo apt-get update
sudo apt-get install -y sysstat

mpstat -P ALL 1 5

특정 CPU만 100%에 가깝고 나머지는 낮다면 단일 스레드 프로세스, IRQ 쏠림, CPU affinity 설정을 확인합니다.

free와 /proc/meminfo로 메모리 확인

free -h
cat /proc/meminfo | egrep 'MemTotal|MemFree|MemAvailable|Buffers|Cached|SwapTotal|SwapFree|Slab|SReclaimable|SUnreclaim'

Linux에서는 사용하지 않는 메모리를 page cache로 적극 활용합니다. 그래서 free의 free 값이 낮다고 바로 메모리 부족은 아닙니다. 운영 판단은 보통 available, swap in/out, OOM 로그를 같이 봅니다.

dmesg -T | egrep -i 'out of memory|oom|killed process'
journalctl -k --since "1 hour ago" | egrep -i 'out of memory|oom|killed process'

프로세스별 원인 찾기

ps -eo pid,ppid,user,stat,pcpu,pmem,rss,vsz,etime,comm --sort=-pcpu | head -20
ps -eo pid,ppid,user,stat,pcpu,pmem,rss,vsz,etime,comm --sort=-pmem | head -20

특정 PID가 의심되면 프로세스 단위로 더 봅니다.

PID="<PID>"
top -H -p "$PID"
pmap -x "$PID" | tail -20
cat /proc/"$PID"/status | egrep 'Name|State|Threads|VmRSS|VmSize|VmSwap|voluntary|nonvoluntary'

top -H는 프로세스 내부 스레드까지 보여주므로 Java, DB, 웹서버처럼 스레드가 많은 서비스에서 유용합니다.

sar로 과거 사용률 확인

장애가 이미 지나간 뒤라면 현재 명령만으로는 원인을 보기 어렵습니다. sysstat이 활성화되어 있으면 sar로 과거 CPU와 메모리 흐름을 볼 수 있습니다.

sar -u 1 5
sar -r 1 5
sar -S 1 5

# 오늘 저장된 과거 CPU/메모리 통계
sar -u
sar -r
sar -S

RHEL 계열은 /var/log/sa/saDD, Debian/Ubuntu 계열은 /var/log/sysstat/saDD에 일자별 통계가 저장됩니다.

# 예: 23일 통계 파일 확인
sar -u -f /var/log/sa/sa23 2>/dev/null || sar -u -f /var/log/sysstat/sa23

PSI로 시스템 압박 확인

최신 커널에서는 Pressure Stall Information으로 CPU, memory, I/O 대기 압박을 볼 수 있습니다. 컨테이너나 고부하 서버에서 평균 사용률보다 실제 대기 시간을 보는 데 도움이 됩니다.

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

장애 시점 수집용 간단 스크립트

#!/usr/bin/env bash
set -euo pipefail

OUT="/tmp/cpu-memory-check-$(hostname)-$(date +%Y%m%d-%H%M%S).log"
{
 date
 hostnamectl 2>/dev/null || hostname
 uptime
 nproc
 free -h
 swapon --show
 echo
 echo "## vmstat"
 vmstat 1 5
 echo
 echo "## top cpu processes"
 ps -eo pid,ppid,user,stat,pcpu,pmem,rss,vsz,etime,comm --sort=-pcpu | head -20
 echo
 echo "## top memory processes"
 ps -eo pid,ppid,user,stat,pcpu,pmem,rss,vsz,etime,comm --sort=-pmem | head -20
 echo
 echo "## oom logs"
 dmesg -T | egrep -i 'out of memory|oom|killed process' || true
} | tee "$OUT"

echo "saved: $OUT"

판단 기준 정리

• CPU 사용률이 높고 vmstat r도 높으면 CPU 병목 가능성이 큽니다.
• CPU idle이 남아 있는데 wa가 높으면 스토리지나 네트워크 파일시스템 지연을 의심합니다.
• free의 free 값만 낮고 available이 충분하면 page cache 사용일 수 있습니다.
• si/so가 계속 발생하면 단순 캐시가 아니라 메모리 압박입니다.
• OOM 로그가 있으면 죽은 프로세스, cgroup/container 제한, 애플리케이션 메모리 증가 추이를 같이 봐야 합니다.