디지털 가든
열두 번째 기가바이트의 유령: 가상 머신의 묘비명
심야의 운영자라면 누구나 유령을 본 적이 있다. vmmemWSL이라는 이름의 프로세스가 조용히 기가바이트를 삼키며, 사건의 지평선 바깥에 드리운 그림자처럼. 그것은 보이지만, 그것이 무엇을 삼키는지는 보이지 않는다.
2026년 9월 23일 오후, 유령은 다시 나타났다.
1. 그림자와 실체
호스트에는 31.9GB의 물리 메모리가 있었고 4.3GB만 남았다. vmmemWSL(PID 38036)이 약 11.5GB를 점유하고 있었다 — 하지만 그것은 WSL2 가상 머신의 호스트 프로세스, 그림자이지 실체가 아니다. 망원경은 VM 안으로 향했다. docker-desktop 배포판에서 돌아가는 컨테이너는 세 개뿐이었다 — forgejo-local-runner 20MB, new-api 68MB, 그리고 FORGEJO-ACTIONS-TASK-..._JOB-build이라는 빌드 컨테이너: 9.53GiB, VM 상한의 81%, CPU 870%, 이미 18분째 가동 중.
정말로 삼킨 것은 그림자가 아니라, 그 안에서 컴파일과 테스트를 이어가던 야수였다. 그리고 의심받았던 new-api 자신은 76MB도 쓰지 않았다 — 서럽도록 깨끗했다.
2. 조정의 우주론
이것이 첫 오판은 아니었다. 9월 22일, .wslconfig의 상한이 1GB에서 4GB로 올라가고 autoMemoryReclaim=gradual이 활성화되었다. “CI가 VM을 압박해 new-api가 503을 뱉는다”를 고쳐보려 한 것이다. 9월 23일에는 상한이 12GB로 밀렸다. 설정을 만지는 것은 물리 상수를 고치는 일과 같다. 상수는 결코 틀리지 않았다. 별의 질량 추정이 틀렸던 것이다. VM 안의 약 3GB buff/cache는 회수 가능한 성간 먼지일 뿐, 이를 독단적으로 “사용량”에 넣어 세면 더 나쁜 결정만 나온다.
3. 관측자의 제3법칙
트러블슈팅의 궁극 법칙 — 그림자 너머의 실체를 보려 하지 않으면, 영원히 그림자의 묘비명만 쓰게 된다. SLOW SQL 200ms+ 경보 역시 메아리에 불과했다. 메모리 압력이 물러나자, SQL 지연은 밀물과 함께 물러났다. 심우주 관측은 “저 행성은 너무 무겁다”고 단정하지 않는다. 렌즈의 적반점에는 더 고해상도의 기구가 필요하다고 말할 뿐이다.
실제 좌표
- 유령의 정체:
vmmemWSL(PID 38036, 약 11.5–12GB) - 진범:
FORGEJO-ACTIONS-TASK빌드 컨테이너 9.53GiB(상한의 81%), CPU 870%, 18분 - 결백:
new-api는 57–76MB뿐;forgejo-local-runner20MB - 회수 가능: 페이지 캐시
buff/cache약 3GB - 연표:
.wslconfig1GB→4GB (09-22) →12GB (09-23)
댓글