VmmemWSL 높은 메모리: RAM 회수 전에 작업부터 파악하기

작업 관리자의 VmmemWSL는 WSL 가상 머신 환경이 사용하는 리소스를 나타냅니다. 이 메모리에는 활성 Linux 작업과 캐시가 포함될 수 있습니다. Docker, AI 모델 서버 또는 개발 도구가 그곳에서 실행 중이라면 Windows 편집기를 종료해도 해당 작업이 반드시 멈추지는 않습니다.

먼저 메모리가 실행 중인 작업에 속하는지, 아니면 작업이 끝난 뒤 캐시로 남아 있는지 판단하세요. WSL 가상 디스크를 삭제하는 것은 메모리 해결책이 아니며 Linux 환경과 그 데이터를 파괴할 수 있습니다.

WSL 내부의 작업 찾기

PowerShell에서 설치된 환경을 확인합니다:

wsl --version
wsl --list --verbose
wsl --list --running

해당 Linux 배포판 내부에서 다음 읽기 전용 보기를 사용합니다:

free -h
ps -eo pid,comm,rss --sort=-rss

Linux 수치는 작업 관리자의 VM 전체와 범위가 정확히 같지 않습니다. 모든 수치를 억지로 맞추려 하지 말고 프로세스를 찾고 사용 가능한 메모리와 파일 캐시를 구분하는 데 사용하세요. Docker가 소유한 작업은 Docker Desktop의 실행 중인 컨테이너를 확인하고 해당 정상 제어를 통해 원하는 작업을 중지하세요.

AI 서버는 응답 후에도 모델을 계속 로드해 둘 수 있습니다. 더 이상 필요하지 않다면 해당 작업을 의도적으로 중지하세요. 이름이 낯설다는 이유만으로 임의의 프로세스를 종료하지 마세요.

모든 캐시를 누수라고 부르지 않고 Linux 메모리 샘플 읽기

free -h 출력에서는 available, used, buff/cache에 주의하세요. Linux는 유휴 메모리를 파일 데이터에 사용하며, 그중 일부는 애플리케이션이 필요로 할 때 회수할 수 있습니다. 따라서 free 값이 작다는 것만으로는 Linux에 메모리가 부족하다고 판단하기에 충분하지 않습니다.

프로세스 목록은 RSS를 KiB 단위로 보고하지만 free -h는 사람이 읽기 쉬운 단위를 사용합니다. 또한 공유 페이지와 VM 오버헤드 때문에 프로세스 행을 모두 더한 값이 작업 관리자의 VmmemWSL 수치와 반드시 같지는 않습니다. 합계를 억지로 맞추기보다 가장 큰 행으로 소유자를 식별한 뒤 해당 워크로드를 살펴보세요.

Docker가 관련되어 있다면 다음 읽기 전용 명령으로 실행 중인 컨테이너를 확인하고 리소스 샘플을 한 번 수집할 수 있습니다(Docker stats reference):

docker ps
docker stats --no-stream

조사 중인 Docker 백엔드에 연결된 환경에서 실행하세요. 다른 Docker 컨텍스트는 원격 머신을 가리킬 수 있으므로 작업 전에 대상을 확인해야 합니다. 컨테이너에 표시되는 메모리 수치와 전체 WSL VM 합계는 범위가 다릅니다.

세 가지 상태를 비교하세요. AI 작업 시작 전, 실행 중, 그리고 애플리케이션이 정상적으로 모델을 언로드하거나 작업을 중지한 후입니다. 큰 프로세스가 계속 살아 있다면 캐시 회수는 그 프로세스가 계속 실행되어야 하는지를 결정하는 대안이 아닙니다. 프로세스는 줄었지만 캐시가 남아 있다면 회수 동작이 더 관련 있는 질문이 됩니다.

현재 회수 설정 확인

Microsoft의 WSL 구성 참조는 전역 WSL 2 설정을 %USERPROFILE%\.wslconfig에 둡니다. 이는 배포판 내부의 /etc/wsl.conf와 다릅니다.

현재 참조는 autoMemoryReclaim를 [experimental] 아래에 나열하며, 기본값은 dropCache이고 gradual도 지원되는 또 다른 모드입니다. 보편적으로 비활성화된 기본값을 활성화하라는 오래된 조언은 따라서 낡은 것일 수 있습니다. 무엇이든 추가하기 전에 설치된 WSL 버전과 기존 구성을 확인하세요.

해당 설정을 지원하는 버전에서 점진적 캐시 회수를 의도적으로 원한다면 이 항목을 기존 파일에 병합하세요:

[experimental]
autoMemoryReclaim=gradual

관련 없는 설정을 덮어쓰거나 중복 섹션을 만들지 마세요. 이는 캐시된 메모리가 회수되는 방식을 바꿀 뿐, 활성 모델이나 데이터베이스의 메모리 요구량을 줄이지 않습니다. 변경을 유지할지 결정하기 전에 동일한 작업으로 비교하세요.

기존 구성을 편집하되 되돌릴 수단을 남겨 두기

파일 탐색기에서 %USERPROFILE%를 열고 .wslconfig를 만들거나 편집하기 전에 파일 이름 확장명을 활성화하세요. 실수로 .wslconfig.txt로 저장된 파일은 의도한 구성이 아닙니다. 기존 구성을 먼저 백업으로 복사하고 메모리와 무관한 섹션은 보존하세요.

기존 [experimental] 섹션 하나 아래에서 테스트 중인 회수 항목만 변경합니다. 구성이 없고 의도적인 설정 변경이 정당화되는 경우에만 새 파일이 필요합니다. 서로 다른 문서의 예시를 복사한 뒤 dropCache와 gradual 줄을 모두 추가하거나 섹션을 중복해서는 안 됩니다.

Microsoft가 문서화한 기본값은 이미 캐시를 회수합니다. 이를 gradual로 바꾸는 것은 항상 메모리를 더 절약하는 업그레이드가 아니라 정책 실험입니다. 즉시 회수하는 것보다 캐시를 더 오래 상주시킬 수 있습니다. 현재 동작에 입증된 문제가 없다면 기본값을 그대로 두고 활성 워크로드를 조사하세요.

안전한 WSL 재시작을 통해 변경을 적용한 뒤 같은 작업을 반복하고 Windows 응답성, Linux 가용 메모리, 작업 완료 여부를 관찰하세요. 변경이 도움이 되지 않으면 백업에서 이전 항목을 복원하고, 동일한 저장과 재시작 주의 사항에 따라 복원을 적용하세요. 실험적인 줄 하나를 제거하려고 구성을 통째로 지우지 마세요.

작업을 저장한 뒤에만 WSL 재시작

구성 변경은 WSL 환경이 재시작될 때 적용됩니다. Microsoft의 기본 명령은 전역 종료 명령을 문서화합니다:

wsl --shutdown

사용하기 전에 파일을 저장하고, 학습 또는 추론 작업을 중지하며, 영향을 받는 컨테이너나 데이터베이스를 정상적으로 종료하세요. 이 명령은 Docker Desktop 뒤의 작업을 포함해 실행 중인 모든 배포판과 WSL 2 VM을 중지합니다. 선택적 메모리 정리 버튼이 아닙니다.

종료 후 VmmemWSL 메모리가 사라진다면 중지된 환경이 그 메모리를 소유했음을 확인해 줍니다. 그것이 누수인지 활성 작업인지 유용한 캐시인지는 구분하지 못합니다. 필요한 서비스를 재시작하고 동일한 작업이 완료된 뒤 비교하세요.

메모리 상한은 복구가 아닌 예산으로 사용

.wslconfig memory 설정은 WSL 2가 사용할 수 있는 메모리를 제한합니다. 상한이 너무 낮으면 Linux 애플리케이션이 실패하거나 스왑을 과도하게 사용할 수 있습니다. 프로그램의 요구량을 없애지는 않습니다. 작업량과 Windows에도 필요한 RAM을 측정한 뒤에만 선택하고, 애플리케이션이 정상적으로 완료되는지 확인하세요.

Docker Desktop의 WSL 지침은 해당 WSL 백엔드의 메모리 회수를 다룹니다. 관련 없는 Hyper-V 지침을 적용하지 말고 그 백엔드에서 구성을 유지하세요.

메모리 상한이 실제로 적용되었는지 확인하기

상한이 필요하다면 기존 구성에서 [wsl2] 아래에 memory를 넣으세요. 예를 들어 memory=8GB는 8 GB 제한을 뜻하며, 배포판마다 8 GB가 예약된다는 뜻이 아닙니다. 이는 구문 예시일 뿐 모든 PC에 권장되는 예산이 아닙니다. 여러 WSL 2 배포판은 전역 VM 예산을 공유하므로 선택할 때 동시에 수행되는 작업을 함께 고려하세요.

작업을 저장하고 WSL을 재시작한 뒤 배포판 안에서 free -h가 보고하는 합계를 확인하고 시스템 오버헤드를 감안해 의도한 제한과 비교하세요. 그다음 실제 모델이나 빌드를 실행하세요. Linux 작업이 종료되거나 스와핑에 시간을 쓴다면 작업 관리자 수치가 작아진 것이 성공은 아닙니다.

제한이 무시되는 것 같다면 파일을 소유한 Windows 계정, 파일 확장명, 대상 배포판이 WSL 2인지, 이전 VM이 완전히 중지되었는지 확인하세요. 이러한 점검은 숫자를 반복해서 낮추는 것보다 더 많은 정보를 줍니다. 두 번째 실험을 동시에 하려고 스왑을 끄지 마세요. 그러면 워크로드가 예산에 도달했을 때의 동작이 달라집니다.

Docker 워크로드의 경우 Docker의 정상 종료와 데이터 지속성 동작을 유지하세요. 터미널을 닫는 것이 반드시 해당 컨테이너를 중지하지는 않으며, 전역 WSL 종료는 여러 무관한 서비스를 중단시킬 수 있습니다. VM 전체 변경을 적용하기 전에 데이터베이스와 학습 작업을 해당 애플리케이션의 자체 제어를 통해 저장하세요.

RAM과 가상 디스크 공간은 별개로 유지

Windows 메모리 가이드는 호스트 측 수치를 다룹니다. 디스크 용량은 별도의 Docker 및 WSL 저장 공간 가이드를 사용하세요. 정리 지름길로 wsl --unregister를 절대 사용하지 마세요. 높은 메모리 수치를 해결하는 것이 아니라 배포판과 그 데이터를 제거합니다.