Python 서버 RSS가 줄지 않을 때 malloc_trim을 적용한 과정

진행 기간: 2026.05–2026.06

개념은 Python 서버의 RSS가 줄지 않는 이유: CPython, gc.collect(), malloc_trim에서 다룬다. 이 글은 Document Parser에 적용한 판단과 운영 검증만 기록한다.

왜 시작했나

Document Parser 워커의 RSS가 시간당 약 1.4GB 늘어나는 구간을 발견했다. 한 워커를 5분과 32분 시점에 비교했을 때 RSS는 2.05GB에서 2.73GB로 증가했다.

당시에는 워커가 작업 세 건을 처리하면 프로세스를 종료하도록 설정했다. 프로세스가 끝나면 운영체제가 메모리를 회수하므로 상한은 만들 수 있었지만, 새 워커가 모델과 캐시를 다시 준비하는 비용을 자주 치러야 했다.

코드에는 이미 청크 처리가 끝날 때마다 gc.collect()가 있었다. 호출 횟수를 늘리는 것으로는 해결되지 않았고, Python 객체가 해제된 뒤에도 RSS가 남는 계층을 따로 살펴봐야 했다.

무엇을 확인했나

운영 환경은 소스에서 빌드한 CPython 3.11.7과 Linux glibc를 사용했다. 이 조합에서는 gc.collect()가 순환 참조를 정리해도, glibc가 해제된 메모리를 다시 쓰려고 보관하면 RSS가 바로 줄지 않을 수 있다.

다만 당시 자료만으로 glibc 단편화를 원인으로 확정하지는 못했다. 살아 있는 Python 객체나 C 확장 내부 메모리도 후보였다. 확인할 수 있었던 사실은 다음 두 가지였다.

• 청크 처리 뒤 gc.collect()를 호출해도 RSS 증가가 이어졌다.
• 프로세스가 종료되면 RSS가 내려갔다.

이 관측을 바탕으로 워커 재활용은 안전장치로 유지하고, glibc가 관리하는 빈 페이지의 반환을 요청하는 malloc_trim(0)을 추가하기로 했다.

메모리 정리를 한 함수로 모았다

흩어져 있던 gc.collect() 호출 8곳을 release_unused_memory()로 교체했다. 함수는 다음 순서로 동작한다.

1. gc.collect()로 순환 참조 수집을 요청한다.
2. Linux와 glibc 환경이면 malloc_trim(0)을 호출한다.
3. 호출 전후 RSS와 반환값을 지표로 남긴다.

로컬 macOS처럼 지원하지 않는 환경에서는 malloc_trim()을 호출하지 않는다. 운영에서 문제가 생기면 기능을 끌 수 있도록 환경변수도 뒀다. 환경변수를 바꾸려면 컨테이너 재시작이 필요하므로 즉시 반영되는 설정은 아니다.

호출부를 함수로 모은 이유는 메모리 회수 방식보다 호출 경계를 관리하기 위해서였다. 이후 중복 호출이 발견됐을 때도 처리 흐름 전체를 뒤지지 않고 이 함수의 호출 위치를 정리할 수 있었다.

첫 배포에서는 안전성만 확인했다

인스턴스 한 대를 분리해 새 코드를 배포하고 180건을 호출했다.

• 180건 모두 HTTP 200 응답
• 기능 회귀 없음
• 호스트 메모리 제한과 워커 재시작 기준 미도달

RSS는 부하 중 오르내렸지만 계속 증가하는 모습은 보이지 않았다. 그러나 이때 워커당 처리 건수를 20건으로 함께 높였고, 시험 중 워커 여섯 개가 한 번씩 재활용됐다. 프로세스 종료가 메모리를 회수했으므로 이 결과만으로 malloc_trim()의 효과를 분리할 수 없었다.

첫 배포에서 확인한 것은 “기능을 깨뜨리지 않고 운영할 수 있다”는 점까지였다.

워커당 100건으로 높인 뒤 다시 확인했다

이후 워커당 처리 건수를 20건에서 100건으로 높였다. 약 79일의 운영 지표를 다시 조회해 다음 결과를 확인했다.

• 성공 요청 100만 건 이상 처리
• malloc_trim()이 메모리를 반환했다고 보고한 호출 약 146만 회
• 워커의 정상 재활용으로 분류되는 지표는 성공 요청 약 94.5건마다 한 번 발생
• 기간 시작과 끝의 호스트별 일일 최대 메모리 사용률은 비슷한 범위

성공 요청 100건에 가까운 주기로 워커가 재활용된 결과는 설정값 100과 대체로 맞는다. 다만 현재 지표의 unknown 사유에는 정상 재활용뿐 아니라 배포와 분류되지 않은 종료가 섞일 수 있어 정확히 100건마다 종료됐다고 단정하지 않았다.

호스트 메모리에는 일시적으로 90%를 넘은 날도 있었다. 장기간 계속 높아지는 추세는 보이지 않았지만, 항상 낮고 안정적이었다고 표현할 수는 없다. Document Parser 호스트로 한정한 OOM 지표도 조회되지 않아 OOM이 한 번도 없었다는 결론은 내리지 않았다.

정리 함수의 비용도 측정했다

별도 성능 측정에서는 요청 25건을 처리하는 동안 메모리 정리 함수가 180번 호출됐다. gc.collect()와 malloc_trim()을 합친 평균 시간은 호출당 약 0.327초였다.

이 측정은 malloc_trim()만의 비용이 아니다. 또한 청크별 정리가 겹쳐 한 요청 안에서 같은 함수를 여러 번 호출하고 있었다. 이후 정상 요청의 정리 경로를 요청 경계 한 곳으로 모아 중복 호출을 줄였다.

메모리가 줄어든다는 이유만으로 자주 호출하면 처리 시간을 낭비할 수 있다. RSS와 함께 호출 횟수, 정리 시간과 요청 지연을 봐야 한다는 점을 이 측정에서 확인했다.

어디까지 말할 수 있나

운영 결과는 malloc_trim()을 도입한 뒤에도 워커당 100건 이상을 처리하도록 설정할 수 있었고, 관측 기간에 호스트 메모리의 장기 누적 상승이 보이지 않았다는 점을 뒷받침한다.

하지만 다음 조건 때문에 안정화의 원인을 malloc_trim() 하나로 분리할 수는 없다.

• 기능을 끈 비교군이 없었다.
• 워커 재활용이 계속 함께 동작했다.
• 정리 전후 RSS에는 gc.collect() 효과도 포함됐다.
• 배포와 요청 구성이 기간마다 같지 않았다.

따라서 결론은 “malloc_trim()이 누수를 해결했다”가 아니다. 명시적 메모리 반환과 워커 재활용을 함께 두고, 워커당 처리 건수를 100으로 높인 뒤에도 장기 누적 상승이 보이지 않았으며 malloc_trim()의 실제 반환도 지표로 확인했다가 현재 근거에 맞는 표현이다.

내가 한 일

• RSS 증가 구간과 기존 gc.collect() 호출 위치를 확인했다.
• CPython과 glibc의 메모리 반환 경계를 조사했다.
• 메모리 정리 함수를 만들고 기존 호출 8곳을 교체했다.
• 기능 비활성 설정과 호출 결과 지표를 추가했다.
• 인스턴스 한 대에서 부하 시험을 진행한 뒤 전체에 적용했다.
• 워커당 처리 건수를 100으로 높이고 장기 운영 지표를 다시 확인했다.
• 중복된 정리 호출을 요청 경계로 모았다.

남은 검증

malloc_trim()의 순수 효과를 확인하려면 같은 이미지와 부하에서 기능을 켠 그룹과 끈 그룹을 비교해야 한다. 두 그룹의 워커 재활용 기준을 같게 두고 다음 값을 함께 측정하면 된다.

• 작업 전후 RSS
• malloc_trim() 반환값과 반환량
• 워커 재시작 횟수와 사유
• 정리 함수 실행 시간
• 요청 지연과 처리량

지금 가진 운영 지표는 도입 이후의 안정성을 설명하기에는 충분하지만, 단일 원인의 인과관계를 증명하는 자료는 아니다.