메모리 누수는 컴퓨터 문제가 아닙니다
오래된 드라이버, Windows 11의 특이점, 폭주하는 Chrome 탭 등 컴퓨터 문제인지 궁금하셨다면, 아닙니다. 메모리 누수는 Monosnap 내부에 있으며 수년 동안 지속되어 왔습니다. 검색해 보세요. r/monosnap 그러면 동일한 패턴을 설명하는 수많은 게시물을 찾을 수 있을 것입니다.
내부적으로 어떤 일이 일어나는지 설명해 드리겠습니다. Monosnap이 영역을 캡처할 때마다 원시 픽셀 데이터를 담을 수 있을 만큼 큰 프레임 버퍼를 할당합니다. 2560 x 1440 화면의 경우 약 14MB입니다. 편집기가 닫히면 해당 버퍼는 OS로 다시 해제되어야 합니다. 하지만 Monosnap에서는 종종 그렇지 않습니다. Electron 렌더러의 힙에 남아 가비지 컬렉션이 실행되기를 기다리지만, 가비지 컬렉션은 아예 실행되지 않거나 너무 늦게 실행됩니다. 하루 40회 이상의 캡처 작업을 하는 동안, 남아있는 버퍼는 수백 메가바이트의 유령 RAM으로 축적됩니다.
해결책은 다른 앱입니다
Monosnap의 아키텍처는 메모리 누수를 Electron 자체와 연결하며, 이를 패치하려면 캡처 파이프라인을 다시 작성해야 합니다. 이 재작업은 5년 동안 이루어지지 않았습니다. 실질적인 해결책은 애초에 이러한 문제가 없도록 설계된 도구를 사용하는 것입니다.
Maxisnap은 PyQt6를 기반으로 구축되었으며 PyInstaller로 단일 Win32 실행 파일로 컴파일됩니다. Chromium 프로세스가 없습니다. 각 캡처는 QImage를 할당하고, 편집기가 이를 참조하며, 창이 닫히면 참조가 해제되고 메모리가 즉시 OS로 반환됩니다. 이는 PyQt의 소유권 모델과 Python의 참조 카운팅이 모두 세대별 GC를 기다리지 않고 즉시 해제하기 때문입니다.
경험적으로: Maxisnap은 시작 시 유휴 상태에서 약 50MB를 사용합니다. 정기적인 캡처와 함께 72시간 연속 실행 후에도 여전히 약 50MB를 사용합니다. 위 차트는 실제 로그에서 가져온 것입니다.
전환 절차
- 0:00Maxisnap 다운로드. 다운로드 페이지로 이동하여 Maxisnap을 설치하세요. 다운로드 페이지. 한 번 클릭, 63MB.
- 0:15Monosnap을 종료하세요. 트레이 아이콘을 마우스 오른쪽 버튼으로 클릭하고 '종료'를 선택하세요. RAM이 600MB 감소하는 것을 확인하세요.
- 0:30설치 프로그램을 실행하세요. 기본 설치 경로, 재부팅 필요 없음.
- 0:45Ctrl+Alt+5를 누르세요. 항상 사용하던 동일한 단축키로 첫 번째 캡처를 해보세요. 편집기가 즉시 열립니다.
- 0:60완료. 서버 업로드를 원하시면 설정에서 SFTP/S3 자격 증명을 붙여넣으세요.
메모리 누수 관련 질문
하루에 스크린샷을 5개만 찍습니다. 그래도 누수의 영향을 받나요?
덜 심각하지만, 그렇습니다. 캡처하지 않을 때도 Monosnap이 클립보드와 시스템 트레이를 폴링하기 때문에 유휴 메모리는 계속 증가합니다. 사용량이 적을 때는 증가 속도가 느리지만 멈추지 않습니다.
앱을 다시 시작하면 도움이 되나요?
일시적으로는 그렇습니다. 종료하고 다시 시작하면 약 180MB로 돌아갑니다. 하지만 메모리 누수를 인지하는 대부분의 사용자는 스크린샷 도구를 하루 종일 실행하기 때문에 그렇게 된 것이며, 여러 번 다시 시작하는 것은 그들이 원하는 바와 정반대입니다.
macOS의 Monosnap은 어떤가요?
macOS에서는 메모리 모델이 다르기 때문에 누수가 덜 심각하지만, 사용자들은 여전히 점진적인 증가를 보고합니다. Maxisnap의 macOS 빌드는 실험적입니다. Windows 사용자는 오늘 바로 전환하세요.