26Y06n1

Young-Kyoo Kim·2026년 7월 6일

DirectPV 기반의 MinIO AIStor와 같은 고성능·대규모(1,000노드급) 온프레미스 스토리지 환경에서 free -h 명령어의 Used 수치가 프로세스 RSS나 Slab(SReclaimable/SUnreclaim) 및 Cache의 합산보다 비정상적으로 높게 나오는 현상은 SRE 실무에서 매우 중요하게 다루어지는 '숨겨진 커널 및 시스템 자원 점유' 문제입니다.

결론부터 말씀드리면, 수식 상으로 Used 수치에는 잡히지만 일반적인 프로세스 감시 도구(ps, top)나 커널 슬랩 감시 도구(slabtop)에 명시적으로 덤프되지 않는 4대 핵심 범주가 원인일 확률이 99%입니다. Linux 커널의 메모리 회계(Memory Accounting) 구조를 바탕으로 이 미스매치의 원인과 진단 방법을 분석해 드립니다.

1. Linux 메모리 수식의 맹점 (왜 계산이 맞지 않는가?)

현대 Linux(procps-ng v3.3.10+)에서 free 명령어가 계산하는 Used 수식은 다음과 같습니다.

Used=Total−Free−Buffers−Cached−SReclaimable\text{Used} = \text{Total} - \text{Free} - \text{Buffers} - \text{Cached} - \text{SReclaimable}

즉, 커널은 Free, Buffers, Cached(Shmem 포함), SReclaimable(회복 가능한 슬랩)을 제외한 모든 시스템 점유 자원을 전부 Used 하나로 뭉뚱그려 표현합니다.

따라서 프로세스들의 실효 메모리(RSS)와 slabtop에 나오는 메모리를 다 더해도 Used보다 턱없이 부족하다면, 아래의 커널 독립 영역 및 대형 가드레일 자원에 메모리가 묶여 있는 것입니다.

2. MinIO AIStor + DirectPV 환경의 4대 숨겨진 범인

운영 중이신 스토리지 아키텍처 특성상, 다음과 같은 요소들이 일반 도구 몰래 메모리를 대량으로 선점하고 있을 가능성이 가장 큽니다.

① HugePages (대용량 페이지 사전 예치 자원) — 최우선 의심

고성능 분산 오브젝트 스토리지(AIStor)나 NVMe 드라이브를 다이렉트로 정밀 통제하는 CSI(DirectPV) 환경에서는 디스크 I/O 병목 및 커널 콘텍스트 스위칭을 줄이기 위해 SPDK(Storage Performance Development Kit), DPDK 또는 Go 런타임 최적화용 HugePages(2MB 또는 1GB 단위)를 시스템 레벨에서 사전 할당(sysctl -w vm.nr_hugepages)하여 가동하는 경우가 많습니다.

  • 증상: HugePages가 커널에 의해 확보되면, 그 즉시 시스템 버디 할당자(Buddy Allocator)에서 격리되어 Used로 고정됩니다. 이 자원은 프로세스 RSS나 standard Cache, Slab 어디에도 속하지 않기 때문에 수십~수백 GB의 메모리가 증발한 것처럼 보입니다.

② PageTables (페이지 테이블 오버헤드)

MinIO AIStor는 대규모 Go 기반 멀티스레딩 아키텍처를 가집니다. 수천 개의 고성능 I/O 고루틴(스레드)이 수십 TB~PB급 NVMe 블록 스토리지 공간을 가상 메모리 공간과 매핑(mmap 또는 대규모 가상 주소 할당)할 때, 가상 주소를 물리 RAM 주소로 변환해 주는 페이지 테이블 구조체(PageTables) 자체의 크기가 비대해집니다.

  • 증상: 스레드 수가 수천 개로 치솟고 프로세스의 가상 메모리(VIRT) 영역이 비대할 경우, 프로세스 RSS와 별개로 커널이 관리하는 PageTables 용량만 노드당 수십 GB에 육박할 수 있습니다. 이는 slabtop에 나오지 않습니다.

③ Percpu (CPU별 메모리 할당량) 및 좀비 Cgroups (Kubernetes 고질병)

1,000노드급 대규모 클러스터에서 Pod의 생성과 소멸(High Pod Churn Rate)이 빈번하게 일어날 때 발생하는 커널 릭(Leak)의 일종입니다.

  • 증상: 컨테이너가 삭제되었음에도 불구하고, 완전히 정리되지 않은 커널 내부의 구조체(예: 열려 있는 파일 디스크립터 흔적, 네트워크 소켓 등)가 남아 있으면 쿠버네티스의 해당 Memory Cgroup이 좀비(Zombie) 상태로 커널에 묶입니다. 이 과정에서 slabtop이 아닌 /proc/meminfo의 Percpu 영역 메모리가 삭제되지 않고 누적 가비지로 남아 호스트의 Used를 지속적으로 상승시킵니다.

④ VmallocUsed (커널 vmalloc 할당 영역)

DirectPV 전용 로컬 드라이버 및 NVMe 가상화 컨트롤러 드라이버가 커널 내부적으로 연속되지 않은 대형 물리 버퍼를 확보하기 위해 vmalloc() 커널 API를 호출한 경우입니다. 이 영역 역시 물리적인 Slab 할당 풀 외부에 존재하므로 slabtop으로는 추적이 불가능합니다.

3. SRE 실무 진단 플레이북 (Ground Truth 찾기)

이 주범들을 명확히 색출해 내기 위해 호스트 노드의 배스천(Bastion)에서 아래 명령어를 즉시 실행하십시오. Linux 메모리의 가공되지 않은 진짜 원천 데이터인 /proc/meminfo를 직접 정밀 타격하여 합산하는 방식입니다.

# 1. 커널의 숨겨진 5대 핵심 지표 즉시 추출
egrep -i "HugePages_Total|HugePages_Free|Hugepagesize|PageTables|VmallocUsed|Percpu|SUnreclaim" /proc/meminfo

📊 팩트 체크 및 독해 가이드라인:

위 명령어의 산출물을 받아 아래 공식으로 대조해 보면 사라진 메모리의 물리적 위치가 100% 입증됩니다.

  1. HugePages_Total ×\times Hugepagesize 계산: 이 값이 수십 GB 규격으로 나온다면, 스토리지/네트워크 바이패스 버퍼용으로 시스템이 메모리를 미리 떼어놓은 상태입니다. (HugePages_Free 수치가 높다면 예약만 해두고 안 쓰고 있는 자원 가비지 상태임을 뜻합니다.)
  2. PageTables 수치 확인: 이 수치가 수십 GB 이상으로 높다면 MinIO의 Go 런타임/스레드 폭주 또는 과도한 파일 매핑 오버헤드가 발생하고 있는 것입니다.
  3. Percpu 수치 확인: 이 수치가 노드 스펙 대비 비상식적으로 높다면 쿠버네티스 Pod Churn에 따른 Cgroup Reap 미흡(좀비 cgroup 자산 적체) 상황으로 판단할 수 있습니다.

이 진단을 통해 특정 지표가 과다 점유된 것이 확인되면, 그것은 논리적 Garbage가 아니라 고성능 대규모 스토리지를 지탱하기 위해 커널 레벨에서 필연적으로 점유하고 있는 거버넌스 비용이거나 cgroup 수명 주기 누수 둘 중 하나로 좁혀 가이드를 수립할 수 있습니다.

profile
Young-Kyoo Kim
engineer
이전 포스트

26Y06m4

다음 포스트

26Y06n2

0개의 댓글