메모리 단편화 Heap fragmentation

원인 ID mem-fragment · 주 담당 게임개발팀·서버 개발

할당과 해제를 반복해 빈 공간이 잘게 쪼개지면, 실제로 쓰는 양보다 훨씬 많은 메모리를 점유합니다.

왜 크기가 제각각인 메모리를 여러 스레드가 오랫동안 할당·해제 → 그러면 빈 공간이 잘게 흩어져 OS에 돌려주지 못하고 사용량이 누수처럼 계속 늘어남 → 화면에서는 오래 켤수록 스왑·메모리 부족으로 느려지다 강제 종료

증상: 슬로우모션, 접속 끊김
요인: 정체
누가 겪나: 서버 전체
언제: 오래 켜 둘수록
담당: 주 담당 게임개발팀·서버 개발
게임개발팀 할 일: 크기별 메모리 풀, 단편화에 강한 할당기(jemalloc, mimalloc 등).
그래프에서는: 서서히 오름 · 프로세스 메모리(RSS)
확인할 곳: 같은 빌드의 서버 둘을 띄워 하나만 환경 변수 MALLOC_ARENA_MAX로 glibc 아레나 수를 줄이거나 jemalloc 같은 다른 할당기로 바꾸고, 며칠 동안 pidstat -r의 RSS를 비교함
이러면 맞음: 인원·개체 수는 비슷한데 바꾼 서버만 RSS 증가가 멈추거나 크게 줄어듦
이러면 아님: 할당기를 바꿔도 똑같이 오르면 해제하지 않는 메모리(mem-leak)
확인 수단: 인프라 도구로 확인(게임 코드 불필요)
더 알아보기: 누수와 모양이 같아서 힙 분석으로는 누수 지점이 안 보입니다. 리눅스 기본 할당기(glibc)는 스레드가 많은 서버에서 특히 심해, 할당기만 바꿔도 사용량이 크게 줄기도 합니다.

출처

mallopt(3) — Linux manual page Linux man-pages
glibc malloc은 스레드 경합을 줄이려고 아레나를 CPU 수의 배수까지 만들고, 아레나가 많을수록 메모리 사용이 늘어남(M_ARENA_MAX로 제한, 환경 변수 MALLOC_ARENA_MAX로도 설정)
jemalloc memory allocator jemalloc
단편화 회피와 동시성 확장을 중시하는 범용 malloc 구현
pidstat(1) — Linux manual page sysstat
-r: 프로세스별 RSS(실제 램에 올라 있는 메모리)