리눅스 메모리 사용량 확인 : 5가지 필수 명령어 완벽 가이드 (top, ps, free, htop, vmstat)

운영하던 웹 서버가 갑자기 느려지거나, 특정 애플리케이션이 예고 없이 종료되는 경험은 시스템 관리자나 개발자라면 누구나 한 번쯤 겪어봤을 문제입니다. 이러한 성능 저하의 원인은 다양하지만, 가장 흔한 용의자 중 하나는 바로 '메모리'입니다. 프로세스가 필요로 하는 메모리가 부족해지면 시스템은 급격히 느려지고, 최악의 경우 OOM(Out Of Memory) Killer에 의해 중요 프로세스가 강제 종료되어 서비스 장애로 이어질 수 있습니다.

따라서 리눅스 시스템의 메모리 사용량을 정확히 파악하고 관리하는 능력은 단순한 문제 해결 기술을 넘어, 시스템의 안정성과 성능을 보장하는 핵심 역량입니다. 이는 장애 발생 시 원인을 찾는 반응적인 조치일 뿐만 아니라, 잠재적인 문제를 사전에 파악하고 예방하는 능동적인 시스템 상태 관리의 첫걸음입니다.

이 글에서는 리눅스 메모리 관리에 필요한 모든 것을 담았습니다. 시스템 전체의 메모리 현황을 빠르게 파악하는 free와 vmstat, 특정 프로세스를 정밀 추적하는 ps와 top, 그리고 이 모든 것을 더 편리하게 만들어주는 htop까지, 5가지 필수 명령어의 사용법을 심도 있게 다룹니다. 또한, 명령어 출력을 제대로 해석하기 위해 반드시 알아야 할 리눅스 메모리의 핵심 개념부터 메모리 누수(Memory Leak)를 진단하는 실전 시나리오까지, 초보자부터 숙련된 엔지니어까지 모두에게 유용한 지식을 체계적으로 제공하는 것을 목표로 합니다.

리눅스 메모리의 핵심 개념 : 제대로 알아야 제대로 본다.

명령어 사용법을 배우기 전에, 리눅스가 메모리를 어떻게 다루는지 이해하는 것이 중요합니다. 개념을 제대로 알지 못하면 명령어의 출력 결과를 잘못 해석하여 엉뚱한 결론을 내릴 수 있습니다.

물리 메모리(RSS) vs 가상 메모리(VSZ) : 보이는 게 전부가 아니다.

프로세스의 메모리 사용량을 이야기할 때 가장 먼저 마주하는 두 가지 용어는 RSS와 VSZ입니다.

• VSZ (Virtual Set Size, 가상 메모리 크기) : 프로세스가 접근할 수 있는 '가상' 메모리 공간의 총량입니다. 여기에는 현재 물리 메모리(RAM)에 올라와 있는 코드와 데이터뿐만 아니라, 스왑 영역에 내려가 있는 부분, 그리고 프로그램이 사용하겠다고 약속은 했지만 아직 실제로 할당되지 않은 공간까지 모두 포함됩니다. 따라서 VSZ는 프로세스의 잠재적인 메모리 크기를 보여주지만, 실제 물리 메모리 사용량과는 거리가 먼, 종종 오해를 불러일으키는 큰 값입니다.
• RSS (Resident Set Size, 상주 메모리 크기) : 프로세스가 사용하는 메모리 중 '실제로' 물리 메모리(RAM)에 상주하고 있는 양을 의미합니다. 시스템의 물리 메모리를 얼마나 차지하고 있는지 보여주기 때문에 VSZ보다 훨씬 실용적인 지표입니다.

하지만 RSS조차 완벽하지는 않습니다. 리눅스에서는 효율성을 위해 여러 프로세스가 동일한 라이브러리(예: libc.so)를 공유해서 사용합니다. 예를 들어, 웹 서버 프로세스 10개가 모두 동일한 라이브러리를 사용한다면, 이 라이브러리는 물리 메모리에 단 한 번만 로드됩니다. 그러나 ps나 top 같은 도구는 각 프로세스의 RSS를 계산할 때 이 공유 라이브러리의 크기를 모두 포함시켜 계산합니다. 결과적으로, 모든 프로세스의 RSS 값을 단순히 더하면 시스템의 실제 메모리 사용량보다 훨씬 부풀려진 값이 나오게 됩니다. 이 점을 이해하는 것은 나중에 ps와 top의 출력을 정확하게 분석하는 데 매우 중요합니다.

버퍼(Buffer)와 캐시(Cache) : 성능을 위한 똑똑한 메모리 활용법

리눅스 시스템의 메모리 사용량을 확인하면 free 메모리가 매우 적게 남아있는 경우가 많아 당황할 수 있습니다. 하지만 이는 문제가 아니라, 리눅스가 성능 향상을 위해 매우 똑똑하게 동작하고 있다는 증거입니다. 리눅스는 "사용되지 않는 메모리는 낭비되는 메모리다"라는 철학을 가지고, 여유 메모리를 적극적으로 버퍼와 캐시로 활용합니다.

• 버퍼 (Buffers) : 디스크에 데이터를 쓰기 전에 데이터를 잠시 보관하는 공간입니다. 주로 파일 시스템의 메타데이터(파일 이름, 권한 등)와 같은 작은 데이터 조각들을 모아서 한 번에 처리하기 위해 사용됩니다.  
• 캐시 (Cache, 정확히는 페이지 캐시) : 디스크에서 읽어온 파일의 내용을 저장해두는 공간입니다. 만약 동일한 파일에 다시 접근해야 할 경우, 느린 디스크를 다시 읽는 대신 훨씬 빠른 메모리(캐시)에서 데이터를 바로 가져와 I/O 성능을 극적으로 향상시킵니다.

이 버퍼와 캐시 메모리는 언제든지 다른 프로세스가 메모리를 필요로 하면 즉시 공간을 비워주고 양보할 수 있는 '유연한' 메모리입니다. 따라서 free 메모리가 적다고 해서 시스템에 여유 공간이 없는 것은 아닙니다.

스왑(Swap) 메모리 : 비상금을 써야 할 때

스왑은 물리 메모리(RAM)가 가득 찼을 때를 대비해 하드 디스크의 일부 공간을 마치 메모리처럼 사용하는 기술입니다. 일종의 비상금과 같습니다.

• 스왑 아웃 (Swap-out, so) : 물리 메모리가 부족해지면, 커널은 당장 사용하지 않는 메모리 페이지(데이터 조각)를 디스크의 스왑 공간으로 내보내 물리 메모리 공간을 확보합니다.
• 스왑 인 (Swap-in, si) : 스왑 공간으로 나갔던 데이터가 다시 필요해지면, 디스크에서 해당 데이터를 다시 물리 메모리로 불러옵니다.

스왑 덕분에 시스템은 물리 메모리보다 더 큰 프로그램을 실행할 수 있고, 메모리 부족 상황에서도 안정성을 유지할 수 있습니다. 하지만 디스크는 RAM보다 수백, 수천 배 느리기 때문에 스왑이 빈번하게 발생하면 시스템 성능이 심각하게 저하됩니다. 따라서 스왑 사용 여부는 시스템의 메모리 상태를 판단하는 중요한 지표가 됩니다.

가장 중요한 차이 : free vs available 메모리

리눅스 메모리 모니터링에서 가장 흔하게 발생하는 오해는 free와 available의 차이를 모르는 데서 비롯됩니다.

• free : 말 그대로 '아무도 사용하지 않는' 순수한 빈 공간입니다. 앞서 설명했듯이, 리눅스는 여유 공간을 캐시로 적극 활용하기 때문에 건강한 시스템에서도 이 값은 매우 낮게 유지될 수 있습니다. 따라서 free 값만 보고 메모리 부족을 판단하는 것은 큰 실수입니다.
• available : '실질적으로 사용 가능한' 메모리의 추정치입니다. 순수한 free 공간에 더해, 필요 시 즉시 회수할 수 있는 버퍼 및 캐시 메모리의 양을 포함합니다. 즉, 스와핑 없이 새로운 애플리케이션을 시작할 때 할당받을 수 있는 메모리의 크기를 나타냅니다.

이 개념은 비유를 통해 쉽게 이해할 수 있습니다. free 메모리는 아무것도 놓여있지 않은 '텅 빈 책상'과 같습니다. 반면, available 메모리는 현재 참고 서류들이 펼쳐져 있지만, 새로운 작업을 위해 언제든 서류를 치우고 공간을 만들 수 있는 '정리 가능한 책상'과 같습니다. 책상 위에 서류가 있다고 해서 일을 못하는 것이 아니듯, 메모리가 캐시로 사용되고 있다고 해서 새로운 프로그램을 실행할 수 없는 것이 아닙니다.

과거에는 free 명령어의 출력이 혼란스러워 많은 사용자들이 시스템 상태를 오판했습니다. 이러한 문제를 해결하기 위해 커널 개발자들은 available이라는 더 직관적인 지표를 도입했고, 이는 최신 free 명령어의 표준 출력이 되었습니다. 따라서 현대 리눅스 시스템에서는 available 값을 기준으로 메모리 여유 공간을 판단하는 것이 가장 정확합니다.

시스템 전체 메모리 사용량 한눈에 보기

이제 핵심 개념을 이해했으니, 시스템의 전반적인 메모리 상태를 확인하는 명령어들을 살펴보겠습니다.

free : 가장 빠르고 간단한 메모리 현황 브리핑

free 명령어는 시스템의 전체 메모리와 스왑 메모리 사용 현황을 가장 빠르고 간단하게 보여주는 도구입니다.

터미널에 간단히 명령어를 입력하는 것만으로 현재 메모리 상태를 즉시 확인할 수 있습니다. 주로 사람이 읽기 편한 단위로 출력해주는 -h 옵션과 함께 사용됩니다.

free -h

실행 결과

---

total used free shared buff/cache available Mem: 3.6Gi 490Mi 2.7Gi 11Mi 682Mi 3.1Gi Swap: 3.9Gi 0B 3.9Gi

• Mem 행 (물리 메모리) :
  • total : 시스템에 설치된 전체 물리 메모리 크기입니다.
  • used : 현재 사용 중인 메모리입니다. total - free - buff/cache와 거의 일치합니다.
  • free : 어떤 용도로도 사용되지 않는 순수한 여유 메모리입니다.
  • shared : 여러 프로세스가 공유하는 메모리(주로 tmpfs)의 크기입니다.
  • buff/cache : 버퍼와 캐시로 사용 중인 메모리의 합계입니다.
  • available : 스와핑 없이 새로 할당 가능한 실제 여유 메모리 추정치입니다. 이것이 가장 중요한 값입니다.
• Swap 행 (스왑 메모리) :
  • total, used, free : 스왑 공간의 전체 크기, 사용량, 남은 양을 보여줍니다.

• free -m, free -g : 각각 메가바이트, 기가바이트 단위로 고정해서 보고 싶을 때 사용합니다.
• watch -n 1 free -h : watch 명령어와 함께 사용하면 1초마다 화면을 갱신하며 실시간으로 메모리 변화를 모니터링할 수 있습니다.

vmstat : 시간의 흐름에 따른 메모리 변화와 병목 현상 추적

free가 특정 시점의 스냅샷을 보여준다면, vmstat(Virtual Memory Statistics)은 일정 시간 간격으로 시스템 리소스의 변화 '추이'를 보여주는 강력한 도구입니다. 특히 메모리 압박이 다른 시스템 영역(CPU, I/O)에 어떤 영향을 미치는지 종합적으로 파악하는 데 매우 유용합니다.

vmstat은 메모리뿐만 아니라 프로세스, I/O, CPU 활동까지 한 줄에 요약해서 보여주므로, 시스템 성능 저하의 원인이 메모리 때문인지, 아니면 다른 문제와 복합적으로 얽혀 있는지 진단할 때 사용합니다.

다음 명령을 실행하면 2초 간격으로 5번 리포트를 출력합니다.

vmstat 2 5

실행 결과

---

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 0 0 0 2784068 3772 695092 0 0 0 0 9 10 0 0 100 0 0 0 0 0 2784068 3772 695132 0 0 0 0 57 84 0 0 100 0 0 0 0 0 2784068 3772 695132 0 0 0 0 45 73 0 0 100 0 0 0 0 0 2784068 3772 695132 0 0 0 0 53 76 0 0 100 0 0 0 0 0 2784068 3772 695132 0 0 0 0 43 72 0 0 100 0 0

메모리 관점에서 주목해야 할 컬럼은 다음과 같습니다.

• memory 영역 :
  • swpd : 사용 중인 가상 메모리(스왑)의 양.
  • free, buff, cache : free 명령어와 유사한 정보를 제공합니다.
• swap 영역 (가장 중요) :
  • si (swap-in) : 디스크(스왑)에서 메모리로 데이터를 가져오는 양 (KB/s).
  • so (swap-out) : 메모리에서 디스크(스왑)로 데이터를 내보내는 양 (KB/s).

vmstat의 진정한 가치는 각 지표를 연결하여 해석할 때 드러납니다. 만약 so 컬럼의 값이 지속적으로 0보다 크게 나타난다면, 이는 물리 메모리가 부족하여 시스템이 비상금인 스왑을 계속 사용하고 있다는 강력한 신호입니다.

여기서 한 단계 더 나아가, so 값이 높게 유지될 때 cpu 영역의 wa(I/O 대기 시간) 비율도 함께 높아지고, procs 영역의 b(I/O 대기로 블록된 프로세스 수) 값도 증가한다면, 이는 완벽한 메모리 병목 현상을 가리킵니다. 즉, '메모리 부족 → 빈번한 스왑 아웃 발생 → 느린 디스크 I/O 작업 증가 → CPU가 디스크 작업을 기다리며 대기하는 시간 증가 → 시스템 전체 성능 저하'라는 연쇄 반응을 vmstat 출력 하나로 진단할 수 있는 것입니다.

/proc/meminfo : 모든 메모리 정보의 근원

리눅스에서 free, top 등 대부분의 메모리 모니터링 도구는 사실 /proc/meminfo라는 가상 파일에서 원시 데이터를 읽어와 가공해서 보여주는 것입니다. 따라서 이 파일의 내용을 직접 확인하면 가장 상세하고 정확한 정보를 얻을 수 있습니다.

가장 상세한 메모리 정보를 확인하거나, 다른 도구의 도움 없이 셸 스크립트 등에서 특정 메모리 값을 정확하게 가져와 사용하고 싶을 때 유용합니다.

# 전체 메모리 정보 확인
cat /proc/meminfo

# 특정 항목만 필터링해서 확인
grep MemAvailable /proc/meminfo

/proc/meminfo에는 수십 개의 항목이 있지만, 가장 중요한 몇 가지와 free 명령어의 대응 관계는 다음과 같습니다.

시스템 관리자가 총 메모리와 사용 메모리, 그리고 사용량을 확인하는 스크립트를 작성한다고 가정해 봅시다. free -h의 출력을 파싱하는 것은 비효율적이고, 시스템 업데이트에 따라 형식이 바뀔 위험이 있습니다. 이럴 때 /proc/meminfo를 직접 읽으면 훨씬 안정적이고 효율적인 스크립트를 만들 수 있습니다.

다음과 같이 /proc/meminfo를 사용하여 메모리를 확인하는 memory_check.sh 스크립트 파일을 작성합니다.

#!/bin/bash

# /proc/meminfo에서 전체 메모리(MemTotal)와 사용 가능 메모리(MemAvailable) 값을 KB 단위로 읽어오기
TOTAL_KB=$(awk '/MemTotal/ {print $2}' /proc/meminfo)
AVAILABLE_KB=$(awk '/MemAvailable/ {print $2}' /proc/meminfo)

# 사용 중인 메모리 계산 (KB)
# 사용 중 = 전체 - 사용 가능
USED_KB=$(( TOTAL_KB - AVAILABLE_KB ))

# 사용률 계산 (%)
# Bash는 정수 연산만 지원하므로 (사용량 * 100 / 전체) 순서로 계산해야 오차를 줄일 수 있음
USED_PERCENT=$(( USED_KB * 100 / TOTAL_KB ))

# 보기 편하게 MB 단위로도 변환 (1MB = 1024KB)
TOTAL_MB=$(( TOTAL_KB / 1024 ))
USED_MB=$(( USED_KB / 1024 ))


# 요청하신 형식으로 결과 출력
echo "--- System Memory Status ---"
echo "총 메모리  : ${TOTAL_MB} MB"
echo "사용 메모리 : ${USED_MB} MB"
echo "사용량      : ${USED_PERCENT}%"

그리고 memory_check.sh 파일을 실행하여 출력값을 확인합니다.

sh memory_check.sh

실행 결과

---

--- System Memory Status --- 총 메모리 : 3658 MB 사용 메모리 : 498 MB 사용량 : 13%

이 방식은 외부 명령어를 파싱하는 것보다 빠르고, 커널이 제공하는 원시 데이터를 직접 사용하므로 훨씬 견고합니다. 이는 단순한 도구 사용자를 넘어, 시스템의 동작 원리를 이해하고 응용하는 전문가의 접근 방식입니다.

특정 프로세스의 메모리 사용량 정밀 추적

시스템 전체의 메모리 상태를 파악했다면, 다음 단계는 어떤 '프로세스'가 메모리를 많이 사용하고 있는지 개별적으로 식별하는 것입니다.

ps : 프로세스 메모리 사용량 스냅샷과 맞춤형 리포트 생성

ps(Process Status) 명령어는 현재 실행 중인 프로세스들의 상태를 '스냅샷' 형태로 보여주는 강력한 도구입니다. 특히 원하는 정보만 골라 맞춤형 보고서를 만들거나 스크립트에 활용할 때 매우 유용합니다.

특정 시점에 어떤 프로세스들이 실행 중이고, 각각 얼마나 많은 리소스를 사용하고 있는지 확인하고 싶을 때 사용합니다. ps 명령어는 옵션 스타일에 따라 크게 System V 계열(ps -ef)과 BSD 계열(ps aux)로 나뉩니다.

• 메모리 사용량 순으로 정렬하기 : --sort 옵션을 사용하면 특정 컬럼을 기준으로 출력을 정렬할 수 있습니다. 메모리 사용량이 높은 프로세스를 찾을 때 필수적입니다.

  # 물리 메모리(RSS) 사용량 높은 순으로 정렬
  ps aux --sort=-rss | head -n 11
  
  # 가상 메모리(VSZ) 사용량 높은 순으로 정렬
  ps aux --sort=-vsz | head -n 11

  head -n 11은 헤더를 포함한 상위 10개 프로세스를 보여줍니다.
• 원하는 정보만 골라 맞춤형 리포트 만들기 : -eo(-o와 동일) 옵션을 사용하면 출력할 컬럼을 직접 지정할 수 있습니다. 이를 통해 불필요한 정보는 빼고 핵심 정보만 담은 깔끔한 보고서를 만들 수 있습니다.

  # 사용자, PID, 물리 메모리(RSS), 가상 메모리(VSZ), 메모리 사용률(%MEM), CPU 사용률(%CPU), 명령어 순으로 정렬하여 상위 10개 출력
  $ ps -eo user,pid,rss,vsz,pmem,pcpu,cmd --sort=-rss | head -n 11

  이 명령어는 "현재 시스템에서 물리 메모리를 가장 많이 사용하는 프로세스 TOP 10 리스트"를 즉시 생성해 줍니다.

• RSS : Resident Set Size. 프로세스가 실제 물리 메모리(RAM)를 점유하고 있는 크기(KB 단위)입니다.
• VSZ : Virtual Memory Size. 프로세스가 사용할 수 있는 전체 가상 메모리의 크기(KB 단위)입니다.
• %MEM : 전체 물리 메모리 대비 이 프로세스가 사용하는 메모리의 비율입니다.

top : 실시간으로 움직이는 프로세스 감시자

top은 리눅스의 가장 고전적이고 기본적인 실시간 시스템 모니터링 도구입니다. 실행하면 터미널 화면 전체를 사용하며, 시스템의 전반적인 상태와 개별 프로세스의 리소스 사용량을 주기적으로 갱신하여 보여줍니다.

서버에 접속하여 "지금 당장 무슨 일이 벌어지고 있는지" 실시간으로 확인하고 싶을 때 가장 먼저 사용하는 명령어입니다.

top 화면은 크게 두 부분으로 나뉩니다.

1. 상단 요약 영역 :
   • KiB Mem : 시스템 전체의 물리 메모리 상태를 보여줍니다. (total, free, used, buff/cache)
   • KiB Swap : 전체 스왑 메모리 상태를 보여줍니다.
2. 하단 프로세스 목록 :
   • PID : 프로세스 ID.
   • USER : 프로세스 소유자.
   • VIRT : 프로세스가 사용하는 가상 메모리(Virtual Memory) 크기.
   • RES : 프로세스가 사용하는 실제 물리 메모리(Resident Memory) 크기. 메모리 사용량을 판단할 때 가장 중요하게 봐야 할 값입니다.
   • SHR : 다른 프로세스와 공유하고 있는 공유 메모리(Shared Memory) 크기.
   • %MEM : 물리 메모리 사용률.
   • %CPU : CPU 사용률.
   • COMMAND : 실행된 명령어.

top 실행 중에 아래 키를 누르면 상호작용이 가능합니다.

• Shift + M : 메모리 사용량(%MEM 또는 RES)이 높은 순으로 프로세스를 정렬합니다. 메모리 문제를 분석할 때 가장 먼저 눌러야 할 키입니다.
• Shift + P : CPU 사용량이 높은 순으로 정렬합니다. 메모리를 많이 쓰는 프로세스가 CPU도 많이 쓰는지 확인할 때 유용합니다.
• 1 : CPU 코어별 사용량을 각각 보여주거나 합쳐서 보여줍니다.
• c : 명령어 전체 경로를 보여주거나(toggle) 간단한 이름만 보여줍니다.
• k : 현재 선택된 프로세스를 종료(kill)시킵니다. PID를 입력하고 시그널(보통 9)을 입력해야 합니다.
• q : top을 종료합니다.

htop: 더 강력하고 직관적인 대화형 모니터링

htop은 top의 현대적인 대안으로, 훨씬 더 사용자 친화적이고 강력한 기능을 제공합니다. 대부분의 경우 top보다 htop을 사용하는 것이 더 효율적입니다.

htop은 기본 설치되어 있지 않은 경우가 많아, 패키지 관리자로 설치해야 합니다.

# Debian/Ubuntu 계열
sudo apt install htop

# Red Hat/CentOS/Fedora 계열
sudo dnf install htop

1. 직관적인 시각적 인터페이스 :
   • 화면 상단에 CPU 코어별 사용량, 메모리, 스왑 사용량이 컬러풀한 막대 그래프로 표시되어 시스템 상태를 한눈에 파악할 수 있습니다.
   • 메모리 막대 그래프 색상 의미 : 이 그래프는 리눅스 메모리 개념의 핵심을 시각적으로 보여줍니다.
     • 초록색 : 프로세스가 사용 중인 메모리 (used)
     • 파란색 : 버퍼 메모리 (buffers)
     • 주황색/노란색 : 캐시 메모리 (cache)
     • 이 그래프를 보면 free 메모리가 거의 없어도, 회수 가능한 파란색/주황색 영역이 많다면 시스템에 여유가 있다는 것을 즉시 알 수 있습니다.
2. 강력하고 편리한 상호작용 :
   • 마우스 클릭과 화살표 키 : 위아래로 스크롤하며 프로세스를 선택하고, 컬럼 헤더를 클릭하여 정렬하는 등 직관적인 조작이 가능합니다.
   • F3 (Search) 또는 / : 프로세스 이름으로 빠르게 검색할 수 있습니다.
   • F4 (Filter) 또는 \ : 특정 문자열이 포함된 프로세스만 필터링해서 볼 수 있습니다. 예를 들어, 'nginx'만 필터링하면 웹 서버 프로세스들의 상태만 집중적으로 모니터링할 수 있습니다.
   • F5 (Tree View) 또는 t : 프로세스 간의 부모-자식 관계를 트리 형태로 보여줍니다. 특정 부모 프로세스가 생성한 자식 프로세스들이 리소스를 얼마나 사용하는지 파악하는 데 매우 유용합니다.
   • F6 (Sort By) 또는 <, > : 정렬 기준을 편리한 메뉴에서 선택할 수 있습니다.
   • F9 (Kill) 또는 k : 프로세스를 선택하고 F9 키를 누르면 시그널을 선택할 수 있는 메뉴가 나타나 안전하고 편리하게 프로세스를 종료할 수 있습니다.

top에서 특정 사용자의 프로세스를 메모리 순으로 보려면 u를 누르고 사용자 이름을 입력한 뒤 Shift+M을 눌러야 하지만, htop에서는 'USER'와 'MEM%' 컬럼 헤더를 마우스로 클릭하기만 하면 됩니다. 이처럼 htop은 복잡한 작업을 단순화하여 시스템 관리의 인지 부하를 크게 줄여주는 생산성 향상 도구입니다.

실전 시나리오 : 메모리 누수(Memory Leak) 진단 및 분석

메모리 누수는 프로그램이 메모리를 할당받아 사용한 후, 더 이상 필요 없음에도 불구하고 해제하지 않아 발생하는 버그입니다. 누수가 계속되면 해당 프로세스의 메모리 사용량은 무한정 증가하여 결국 시스템 전체의 메모리를 고갈시키고 심각한 장애를 유발합니다. 기본 도구들을 활용하여 메모리 누수를 진단하는 3단계 과정을 살펴보겠습니다.

1단계 : 의심스러운 프로세스 식별하기 (top, ps 활용)

메모리 누수의 가장 명백한 증상은 특정 프로세스의 물리 메모리 사용량(RSS 또는 RES)이 시간이 지나도 계속해서 증가하고, 결코 줄어들거나 안정되지 않는 것입니다.

1. top이나 htop을 실행합니다.
2. 메모리 사용량 순으로 정렬합니다 (Shift+M 또는 F6).
3. 상위권에 있는 프로세스들의 RES 값의 변화를 장시간 관찰합니다. 다른 프로세스들은 사용량이 오르내리거나 일정 수준을 유지하는 반면, 유독 한 프로세스의 RES 값만 꾸준히 증가한다면 그 프로세스가 메모리 누수의 유력한 용의자입니다.

또는 watch와 ps를 조합하여 특정 프로세스의 RSS 변화를 주기적으로 기록할 수도 있습니다.

# 'rsyslogd'이라는 프로세스의 PID, RSS, 명령어 정보를 1초마다 확인
watch 'ps -o pid,rss,cmd -C rsyslogd'

실행 결과

---

Every 2.0s: ps -o pid,rss,cmd -C rsyslogd infracody.com: Wed Jun 18 13:39:01 2025 PID RSS CMD 839 7960 /usr/sbin/rsyslogd -n

2단계 : pmap으로 프로세스 메모리 맵 정밀 분석

용의자를 특정했다면, pmap 명령어를 사용하여 해당 프로세스의 메모리 지도를 더 상세하게 들여다볼 수 있습니다. pmap은 프로세스가 메모리를 어떤 영역(스택, 힙, 라이브러리 등)에 얼마나 할당했는지 상세히 보여줍니다.

메모리 누수를 확인할 때는 확장된 정보를 보여주는 -x 옵션을 사용하는 것이 매우 유용합니다.

예제로 위에서 확인했던 rsyslogd의 PID로 확인해보겠습니다.

pmap -x 839

실행 결과

---

839: /usr/sbin/rsyslogd -n Address Kbytes RSS Dirty Mode Mapping 0000558e5a64b000 88 88 0 r---- rsyslogd ... (중략) ... ffffffffff600000 4 0 0 --x-- [ anon ] ---------------- ------- ------- ------- total kB 173036 8404 3424

pmap -x 출력의 맨 마지막 줄에는 해당 프로세스의 전체 메모리 할당 정보가 요약되어 있습니다. 여기서 total RSS 값이 바로 ps나 top에서 보던 물리 메모리 사용량입니다. 이 값을 집중적으로 추적해야 합니다.

3단계 : while 루프로 메모리 변화 자동 추적 및 기록

매번 pmap 명령어를 수동으로 입력하는 것은 비효율적입니다. 간단한 while 루프 셸 스크립트를 사용하면 이 과정을 자동화하고 변화를 명확하게 관찰할 수 있습니다.

rss_check.sh 스크립트 파일을 다음 내용으로 생성합니다.

#!/bin/bash

# 1. 감시할 프로세스의 PID를 찾습니다.
# 예: PID=$(pgrep my_leaky_app) 혹은 PID=12345
PID=$(pgrep rsyslogd)

# PID 변수가 비어있는지(프로세스를 찾지 못했는지) 확인합니다.
if [ -z "$PID" ]; then
  echo "Process not found."
  exit 1
fi

echo "Monitoring memory usage for PID: $PID"
echo "Press Ctrl+C to stop."

# 2. 1초마다 pmap을 실행하여 마지막 요약 줄만 출력합니다.
while true; do
  # 현재 시간과 함께 pmap의 요약 정보 출력
  echo -n "$(date '+%Y-%m-%d %H:%M:%S') - "
  pmap -x $PID | tail -n 1
  sleep 1
done

그리고 rss_check.sh파일을 실행하여 결과를 확인합니다.

sh rss_check.sh

실행 결과

---

Monitoring memory usage for PID: 839 Press Ctrl+C to stop. 2025-06-18 14:59:08 - total kB 173036 8408 3428 2025-06-18 14:59:09 - total kB 173036 8408 3428 2025-06-18 14:59:10 - total kB 173036 8408 3428 2025-06-18 14:59:11 - total kB 173036 8408 3428 ^C

이 스크립트를 실행하면 1초마다 시간과 함께 프로세스의 총 RSS 값이 출력됩니다.

위 실습에서는 테스트 서버에서 RSS 값이 증가하지 않았지만, RSS 값이 꾸준히 증가하고, 프로그램이 유휴 상태일 때조차 줄어들지 않는다면 이는 메모리 누수가 발생하고 있다는 매우 강력한 증거입니다.

전문가 팁 : Java 애플리케이션의 메모리 누수는 다르다.

앞서 설명한 방법들은 C/C++처럼 프로그래머가 직접 메모리를 관리하는 언어로 작성된 프로그램에는 매우 효과적입니다. 하지만 Java처럼 가상 머신(JVM) 위에서 동작하는 프로그램의 경우, 해석에 주의가 필요합니다.

Java 애플리케이션의 RSS가 계속 증가하는 것을 보고 바로 메모리 누수라고 단정하기는 어렵습니다. 이는 실제 누수가 아니라, JVM이 성능 최적화를 위해 운영체제로부터 힙(Heap) 메모리를 점진적으로 더 많이 할당받는 정상적인 동작일 수 있기 때문입니다 (-Xmx 옵션으로 설정된 최대 힙 크기까지). JVM은 거대한 '메모리 블랙박스'와 같아서, 리눅스 도구들은 그 내부에서 무슨 일이 일어나는지 상세히 알 수 없습니다.

Java 애플리케이션의 실제 메모리 누수(가비지 컬렉션이 되지 않는 객체가 쌓이는 현상)를 진단하려면, 리눅스 기본 도구와 함께 Java 전용 프로파일링 도구를 사용해야 합니다.

• 1단계 (외부 관찰) : top, pmap 등으로 JVM 프로세스 자체의 전체 메모리(RSS) 사용량을 모니터링하여 비정상적으로 커지는지 확인합니다.
• 2단계 (내부 분석) : jmap으로 힙 덤프를 생성하고, jconsole, VisualVM 또는 Eclipse Memory Analyzer(MAT)와 같은 도구로 힙 내부를 분석하여 어떤 객체가 해제되지 않고 쌓이고 있는지 정밀하게 추적해야 합니다.

이러한 차이점을 이해하는 것은 잘못된 진단으로 개발 시간을 낭비하는 것을 막아주는 전문가의 중요한 통찰력입니다.

상황별 최적의 명령어 선택 가이드

지금까지 여러 명령어를 살펴보았습니다. 각 명령어는 저마다의 장단점과 최적의 사용 사례가 있습니다. 다음 표는 상황에 맞는 최적의 도구를 빠르게 선택할 수 있도록 돕는 가이드입니다.

마무리 : 핵심 요약

지금까지 리눅스 시스템의 메모리 사용량을 확인하고 분석하는 여정을 함께했습니다. 이 글을 통해 얻어 가야 할 핵심은 다음과 같습니다.

• 리눅스 메모리 해석의 핵심은 available : free 메모리가 낮다고 당황하지 마십시오. 실제 사용 가능한 메모리는 available 값을 통해 판단해야 합니다.
• 목적에 맞는 도구 선택 : 빠른 확인은 free, 추이 분석은 vmstat, 정적 보고서는 ps, 실시간 감시는 top 또는 htop을 사용하는 것이 효율적입니다.
• 메모리 누수는 '지속적인 증가'가 핵심 : top, ps, pmap 등을 활용하여 특정 프로세스의 물리 메모리(RSS/RES)가 시간이 지나도 꾸준히 증가하는지를 관찰하는 것이 누수 진단의 첫걸음입니다.

단순히 명령어를 아는 것을 넘어, 그 출력 결과를 정확히 해석하고 시스템의 동작 원리와 연결 지을 수 있을 때 비로소 진정한 전문가로 거듭날 수 있습니다. 문제가 발생했을 때 허둥지둥 해결책을 찾는 '반응적인 관리'에서 벗어나, vmstat으로 미세한 스왑 아웃 증가를 감지하고, /proc/meminfo의 MemAvailable 값을 기준으로 자동화된 경고 시스템을 구축하는 '능동적인 관리'로 나아가시길 바랍니다. 이 글이 여러분의 시스템을 더 안정적이고 효율적으로 운영하는 데 든든한 발판이 되기를 바랍니다.