조회수: 3

리눅스에서 proc 파일시스템은 디스크에 저장된 일반 파일이 아니라 커널 내부 상태를 실시간으로 보여주는 가상 파일이다. 메모리 사용량 또한 대부분 이곳에서 확인할 수 있다. 메모리 관련 도구들이 내부적으로 참고하는 정보의 원천이기도 하다.

시스템 메모리를 깊이 있게 이해하고 싶다면 먼저 다음 명령으로 proc이 어떻게 마운트되어 있는지 확인할 수 있다.

mount | grep proc

보통 루트 아래 proc 경로에 마운트되어 있으며, 메모리 정보는 그 안의 여러 파일로 노출된다. 이 중 핵심이 meminfo이며 각 프로세스별 메모리 정보는 개별 프로세스 디렉터리에서 확인한다.

proc meminfo 구조 이해

시스템 전체 메모리 상태를 한 번에 보고 싶다면 가장 먼저 살펴볼 곳이 meminfo다.

cat /proc/meminfo

실제 출력에는 여러 줄이 나오며 각 줄이 하나의 항목을 의미한다. 주요 항목을 이해하면 전체 메모리 흐름을 읽는 데 큰 도움이 된다.

MemTotal과 MemFree의 의미

많은 사람이 전체 메모리와 남은 메모리를 단순히 두 값으로 계산해 사용량을 구하려고 한다. 하지만 리눅스 메모리 구조를 고려하면 이렇게 보는 방식은 실제와 다를 수 있다.

• MemTotal
  시스템에 장착된 물리 메모리 전체 용량을 의미한다. 스왑이 아니라 실제 램 크기다.
• MemFree
  완전히 비어 있는 페이지의 용량이다. 그러나 리눅스는 메모리를 최대한 적극적으로 캐시로 활용하기 때문에 MemFree 값이 낮다고 해서 메모리가 부족하다는 뜻은 아니다.

이 두 값만 보고 사용량을 계산하면 캐시와 버퍼를 무시하게 되어 시스템이 메모리를 과도하게 사용하는 것처럼 보이기 쉽다.

Buffers와 Cached의 역할

버퍼와 캐시는 파일 시스템 I O와 관련된 영역이다. 자주 사용하는 데이터를 메모리에 쌓아 두어 성능을 높이기 위해 사용된다.

• Buffers
  메타데이터나 블록 장치 버퍼 등 파일 시스템 자체가 사용하는 영역이다.
• Cached
  실제 파일 데이터 페이지 캐시다. 자주 읽는 파일 내용을 메모리에 올려두는 부분이 여기에 포함된다.

이 두 영역은 필요할 경우 언제든지 다른 용도로 회수될 수 있는 일종의 여유 자원에 가깝다. 따라서 시스템이 여유 메모리를 계산할 때는 다음처럼 보는 것이 더 현실적이다.

• 실질적 여유 메모리
  MemFree에 Buffers와 Cached 일부를 더해 파악한다.

최근 리눅스에서는 이 개념을 보다 직관적으로 보여주기 위해 별도의 available 항목도 제공한다.

MemAvailable을 활용한 여유 메모리 판단

meminfo에 available 항목이 있다면 이것을 기준으로 시스템 여유 메모리를 보는 것이 좋다. 이 값은 현재 워킹셋을 크게 건드리지 않고도 새 프로세스가 사용할 수 있는 대략적인 메모리량을 추정한 값이다.

즉 free 등 단순 수치보다 available을 기준으로 부담 없이 사용할 수 있는 메모리 비율을 보는 편이 운영상 더 현실적이다.

스왑 관련 정보 해석

스왑 사용 여부를 보려면 meminfo에서 스왑 관련 항목을 확인한다.

• SwapTotal
  설정된 전체 스왑 영역 크기
• SwapFree
  아직 사용되지 않은 스왑 남은 용량

스왑 사용량이 많다고 해서 무조건 나쁜 것은 아니다. 오랫동안 사용하지 않는 페이지가 스왑으로 밀려나고 자주 쓰는 페이지가 램에 남아 있다면 크게 문제 되지 않는다. 다만 다음과 같은 상황이라면 주의해야 한다.

• SwapFree가 계속 빠르게 줄어드는 경우
• top이나 htop 등에서 실제로 자주 쓰이는 프로세스 페이지가 스왑에 머무르는 경우
• load average와 디스크 I O가 함께 치솟는 경우

이럴 때는 메모리가 심하게 부족해 스왑을 과도하게 사용하고 있는지 점검할 필요가 있다. 단순히 스왑이 조금 사용되었다는 이유만으로 즉시 메모리 증설을 판단하기보다는 스왑 패턴과 함께 전체 메모리 구조를 함께 봐야 한다.

프로세스별 메모리 사용 status 읽기

시스템 전체 값만으로는 어떤 프로세스가 메모리를 많이 쓰는지 정확히 파악하기 어렵다. 이때는 각 프로세스 디렉터리에서 status 파일을 확인한다.

대상 프로세스의 PID가 있다면 다음처럼 확인할 수 있다.

cat /proc/PID/status

여기에는 메모리와 관련된 여러 항목이 나타난다.

• VmSize
  프로세스가 논리적으로 확보한 주소 공간 전체 크기다. 실제 물리 메모리 사용량과는 다를 수 있다.
• VmRSS
  실제 램에 올라온 물리 메모리 사용량이다. 프로세스의 실질적인 메모리 점유를 파악할 때 가장 많이 보는 값이다.
• VmData VmStack VmExe 등
  각 세그먼트별 사용량을 나타내며 메모리 사용 패턴을 분석할 때 참고한다.

여러 프로세스를 비교할 때는 VmRSS를 기준으로 정렬해 보는 것이 일반적이다. 다만 공유 라이브러리 메모리가 여러 프로세스에 나누어 잡히는 구조인 만큼 단순 합산만으로 시스템 전체 값과 정확히 일치시키기는 어렵다.

smaps로 세부 메모리 구조 파악

특정 프로세스가 왜 많은 메모리를 사용하는지 더 자세히 알고 싶다면 smaps 파일을 활용한다.

cat /proc/PID/smaps

이 파일은 메모리 매핑 영역별로 사용량과 rss 공유 비율 등을 상세히 보여준다. 예를 들어

• 어떤 파일 매핑이 메모리를 많이 차지하는지
• 익명 메모리가 얼마나 되는지
• 공유와 전용 메모리 비율이 어떤지

등을 세밀하게 분석할 수 있다. 다만 출력량이 매우 많으므로 단순 확인보다는 스크립트나 분석 도구와 함께 사용하는 편이 효율적이다.

free vmstat와 proc의 관계 이해

많은 관리자들이 free vmstat와 같은 명령을 먼저 확인하고 이상 징후가 있을 때 proc 안으로 들어가 더 깊게 보는 식으로 접근한다. 이때 두 값이 서로 다르게 보이는 이유를 이해하는 것이 중요하다.

• free
  내부적으로 meminfo를 기반으로 보기 좋게 가공한 결과를 보여준다. 버퍼 캐시 영역을 따로 분류해 보여 주기 때문에 전체 흐름을 빠르게 파악하기 좋다.
• vmstat
  메모리뿐 아니라 스왑과 페이지 인 아웃 상황을 함께 보여준다. 단발성 출력보다는 일정 간격으로 반복 출력해 추이를 보는 데 유용하다.

이들 도구와 meminfo status smaps를 함께 사용하면 시스템 수준과 프로세스 수준을 동시에 관찰하면서 메모리 이슈를 추적할 수 있다.

실전에서 proc 기반으로 메모리 진단하는 순서

실제 장애 대응이나 성능 분석 상황에서 proc 파일시스템을 활용해 메모리를 진단하는 흐름을 예시로 정리해 보자.

• 먼저 free나 vmstat로 전체 메모리 상황과 스왑 사용 여부를 확인한다.
• meminfo에서 available 값과 캐시 버퍼의 비중을 보고 실제 여유 메모리가 어느 정도인지 파악한다.
• top이나 ps로 메모리 사용 상위 프로세스를 찾고 각 프로세스의 status 파일에서 VmRSS를 비교한다.
• 특정 프로세스가 유난히 크다면 해당 프로세스의 smaps를 분석해 어느 영역이 크게 증가했는지 확인한다.
• 필요하다면 프로파일링 도구나 애플리케이션 로그와 연계해 어떤 기능이 메모리를 많이 요구하는지 역추적한다.

이러한 단계적 접근을 반복해 보면 숫자들 간의 상관관계가 눈에 익으면서 proc에서 보이는 값만으로도 시스템 상태를 빠르게 추정할 수 있게 된다.

proc 파일시스템을 통한 메모리 모니터링 습관 만들기

메모리는 CPU와 함께 시스템 성능에 직결되는 자원이다. 그러나 단순히 남은 용량만 보고 판단하면 리눅스의 공격적인 캐시 전략을 이해하지 못한 채 불필요한 불안감이나 잘못된 튜닝으로 이어질 수 있다.

• meminfo에서 available 중심으로 여유 메모리를 본다.
• 스왑 사용량은 절대값보다 패턴과 추이를 기준으로 평가한다.
• 프로세스별 메모리는 status에서 VmRSS를 중심으로 파악한다.
• 이상 징후가 있을 때는 smaps까지 내려가 어느 영역이 문제인지 확인한다.

이 흐름을 꾸준히 연습하면 단순한 명령 결과를 외우는 수준을 넘어 커널이 메모리를 어떻게 바라보고 관리하는지 감각적으로 이해하게 된다. 결국 이것이 안정적인 서버 운영과 성능 최적화의 기반이 된다.