목표
시스템 메모리 상태를 분석하고, OOM (Out of Memory) 상황을 진단할 수 있어야 함.
리눅스 메모리 구성
리눅스 메모리는 Used + Free + Buffers + Cached로 이루어져있고, Buffers와 Cached는 즉시 반환이 가능하다. 실제 가용 메모리는 Free + Buffers + Cached의 합이다.
- 모르는 부분에 대한 학습
1. Buffers와 Cached 에 대한 개념이 없음.
2. Buffers는 블록 디바이스 메타데이터 캐시이며, Cached는 실제 파일의 Content에 대한 캐시이며, 즉시 회수가 가능하다.
3. 디스크 접근은 메모리 접근 대비 수천~수만 배 느리다. 그래서 Linux는 사용하지 않는 메모리는 낭비라는 철학을 가지고 있다.
4. 그래서 Linux는 디스크에서 읽은 데이터는 무조건 메모리에 저장하고, 다시 읽는다면 디스크에 접근하지 않고 바로 메모리에 접근해서 빠르게 값을 읽는다.
5. 메모리가 부족해지면 언제든지 reclaim하고 다시 디스크에서 읽는다.
6. 블록 디바이스란 데이터를 블록(보통 4kb)단위로 읽고 쓰는 장치를 뜻하며, HHD/SSD/RAID 등이 있다.
7. 곧 Buffers는 파일의 내용이 아니라 파일 시스템을 운영하기 위한 메타데이터를 캐시하는 메모리
8. Buffers에는 inode, 디렉터리 구조, 블록 위치 정보 같은 데이터를 캐시한다.
9. inode는 파일의 이름과 내용을 제외한 파일타입, 권한, 소유자, 파일 크기 등의 정보를 가진 데이터이며, 디렉터리에 있는 파일을 조회하기 위한 ls 명령어 입력 시, 디스크에 접근하여 파일정보를 가지고 오는 것이 아닌 Buffers 메모리의 inode 정보를 불러와 보여준다. (매번 디스크에 접근하면 위와 마찬가지로 느려진다.)
10. 디렉터리 구조는 inode를 파일이름과 맵핑한 데이터이며, 폴더도 타입이 폴더인 파일이기에 inode가 존재하며, /home/test/app.log 파일에 접근할 때 / 디렉터리를 찾고, home 디렉터리를 찾고, test 디렉터리를 찾은 뒤, app.log의 inode 번호를 찾은 뒤, inode의 디스크 위치에서 실제 app.log의 데이터를 불러오게 된다.
11. 같은 맥락으로 블록 위치 또한 Buffers에 캐시되어있기 때문에 디스크를 사용할 때보다 빠르게 파일에 접근할 수 있다.
12. Cached란 파일의 실제 데이터를 캐싱한 메모리이다. 실제 데이터를 가지고 있기 때문에 크기가 매우 커질 수 있으며, 필요 시 가장 먼저 회수된다.
실습 1

- 모르는 부분
1. Swap used가 0이 아니면 메모리 부족 징후인 것에 대한 이유가 궁금해졌음.
2. swap은 커널이 메모리 압박을 감지하여 일부 페이지를 디스크로 밀어낸 것이며, 쉽게는 메모리의 비상 대피소라고 할 수 있다.
3. 정상상태에서는 사용되지 않는 게 정상적이며, swap used가 0이 아니라는 뜻은 swap으로 밀어낸 메모리가 존재한다는 뜻이며, 이는 과거 또는 현재에 메모리 압박을 받았다는 증거로 생각할 수 있다.
4. swap이 정상상태에서 사용되지 않는 이유는, RAM 보다 수십~수백 배가 더 느리기 때문에 성능 하락을 이유로 사용하지 않는다.
5. swap은 OOM 이전에 고려되며, 존재 이유는 OOM 지연과 메모리 스파이크 흡수를 하기 위한 안전장치라고 보면 된다.
6. swap으로 밀려난 메모리에 다시 접근하게 되면 다시 RAM으로 올라오기 때문에 (swap-in) swap의 용량은 문제가 되지 않지만 사용되었다는 것만으로 메모리 부족의 현상으로 인식할 수 있음.
7. swap-in이 발생하면 자동으로 RAM으로 올라오는데, swap 메모리에 접근했을 때 성능이 왜 중요한지에 대한 궁금증이 생김.
8. java를 예를 들면, 전체 메모리가 부족해져 커널이 jvm의 일부 메모리가 사용되지 않음을 발견하고 그 일부 메모리를 swap-out 함
9. GC가 모든 객체를 접근하게 되고, swap-out된 많은 데이터에 접근하게 됨.
10. swap에서 디스크를 읽게 되고, 많은 데이터를 읽고, RAM에 다시 적재하기 때문에 순간 지연이 발생함.
실습 2: vmstat 으로 실시간 모니터링

암기 필요 명령어

학습 간 느낀점
기존엔 free 명령어를 통해 메모리를 판단하는 과정만 거쳐본 경험이 있었는데, 상세 분석이나 특정 프로세스의 OOM 점수 등을 확인하여 미리 해당 프로세스의 OOMKilled나 swap-out 등을 감지 할 수 있을 것 같아 실제 업무에도 도움이 되는 학습이였다.
또한, 리눅스의 메모리 구조에 대해 파악할 수 있어서 리눅스의 철학을 하나씩 알아가는 것이 재밌다고 생각되었다.
'DevOps' 카테고리의 다른 글
| Day2: /proc 파일시스템으로 프로세스 분석 (0) | 2026.01.10 |
|---|---|
| Day 1: strace로 시스템 콜 분석하기 (0) | 2026.01.08 |