우분투 실전 명령어 | free, vmstat로 메모리 압박 진단

Last updated on 18 2월 2026

언제 쓰는가

서버가 느려졌는데 CPU 사용률은 높지 않을 때, 메모리 압박부터 확인하면 원인을 빨리 좁힐 수 있다. 특히 스왑이 계속 늘거나 iowait가 같이 튀는 상황이면 응답 지연이 길어지기 쉽다. free와 vmstat을 같이 보면 현재 상태와 추세를 함께 확인할 수 있어서 장애 초동 대응에 유용하다.

바로 쓰는 명령어 (코드블록)

# 1) 현재 메모리/스왑 상태 확인
free -h

# 2) 1초 간격으로 10회 샘플링(런큐, 스왑, IO wait 같이 확인)
vmstat 1 10

# 사용 가능한 메모리 위주로 간단 확인
free -m | awk 'NR==2{printf "used=%sMB, free=%sMB, buff/cache=%sMB, available=%sMB\n", $3,$4,$6,$7}'

# 스왑 사용 중인 프로세스 상위 확인(권한 필요)
for p in /proc/[0-9]*; do 
  pid=${p##*/}
  swap_kb=$(awk '/VmSwap/{print $2}' "$p/status" 2>/dev/null)
  if [ -n "$swap_kb" ] && [ "$swap_kb" -gt 0 ]; then
    cmd=$(tr -d '\0' < "$p/cmdline" 2>/dev/null | cut -c1-80)
    printf "%10s KB  pid=%-7s %s\n" "$swap_kb" "$pid" "$cmd"
  fi
done | sort -nr | head -20

핵심 옵션/패턴

free -h: 사람이 읽기 쉬운 단위로 메모리와 스왑을 바로 확인
free -m: MB 기준 수치 비교가 필요할 때 유용
vmstat 1 10: 1초 간격으로 10번 측정해서 순간값이 아니라 추세 확인
vmstat에서 볼 항목
- r: 실행 대기 프로세스 수
- si/so: 스왑 in/out, 0이 아닌 값이 계속 나오면 메모리 압박 신호
- wa: I/O 대기 비율, 높게 유지되면 디스크 병목 가능성

명령 출력 예시

$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        18Gi       1.2Gi       512Mi        12Gi        11Gi
Swap:          2.0Gi       1.1Gi       896Mi

$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0 1126400 124000  92160 12500480    0    0     5    12  210  430 12  4 80  4  0
 4  1 1130240 118200  92160 12490000   32   96   140   220  510 1090 18  6 58 18  0

자주 하는 실수

free의 free 컬럼만 보고 메모리 부족이라고 단정하는 경우. available 컬럼을 같이 봐야 실제 여유를 판단할 수 있다.
vmstat을 1회만 보고 결론 내리는 경우. 최소 5~10회는 관찰해서 지속적인 스왑이나 대기 패턴을 확인해야 한다.
si/so가 잠깐 튄 한 줄만 보고 바로 재시작하는 경우. 배치 작업 시점인지, 특정 프로세스 급증인지 먼저 확인하는 게 안전하다.

검증 방법 (결과 확인 명령어)

# 10초 관찰 후 스왑 in/out 발생 여부 확인
vmstat 1 10

# 메모리 많이 쓰는 프로세스 확인
ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%mem | head -15

# OOM 킬 로그 확인
journalctl -k --since "-2h" | grep -Ei "out of memory|oom-killer|killed process"

운영 팁 (선택)

메모리 압박이 의심될 때는 먼저 원인 프로세스를 식별하고, 재시작 전에 트래픽 피크 시간대와 배치 스케줄을 같이 확인하는 편이 좋다. 단기 대응으로 캐시 정리나 스케일 아웃을 검토할 수 있지만, 반복되면 애플리케이션 메모리 제한과 누수 점검을 우선순위로 두는 게 재발 방지에 효과적이다.

출처

Ubuntu Manpage free
procps-ng vmstat 문서
Linux kernel OOM 관련 문서