- 인공지능기초다지기
- Oracle
- boostcourse
- Django
- 오라클
- unsub
- 부스트코스
- 기초다지기
- 데이터베이스
- DB
- 이것이 취업을 위한 코딩테스트다 with 파이썬
- 코딩테스트
- Ai
- r
- SQL
- PY4E
- boostcoures
- 네이버부스트캠프
- python
- 빅분기
- 이기적
- 파이썬
- 코딩테스트 python
- 정보처리기사
- 데이터 분석 기반 에너지 운영 관리자 양성 및 취업과정
- 프로그래머스
- AI 플랫폼을 활용한 데이터 분석
- 빅데이터분석기사
- 빅데이터 분석 기반 에너지 운영 관리자 양성 및 취업과정
- [멀티잇]데이터 시각화&분석 취업캠프(Python)
- Today
- Total
매일공부
[작업 기록] NAS 호스트 메모리 진단 — VS Code Remote-SSH가 먹는 몫 본문
배경
지난번 장애 대응 기록에서 컨테이너별 메모리 제한과 watchdog 스크립트를 도입한 뒤에도, 여유 메모리가 하루 500~600MB씩 꾸준히 줄어드는 패턴이 계속 관찰됐다. docker stats로 확인한 컨테이너 사용량은 정상 범위(합계 약 400MB)였기 때문에, 원인은 컨테이너 안이 아니라 호스트 레벨에 있는 게 분명했다.
진단 — 무엇이 호스트 메모리를 먹고 있었나
ps aux --sort=-%mem으로 확인한 주요 사용처:
원인 메모리 비고
| VS Code Remote-SSH (extensionHost + Pylance + 언어 서버) | 약 1.9GB | 가장 큰 원인 |
| Claude Code 세션 (여러 개 동시 실행) | 세션당 약 200~280MB | VS Code 창 개수만큼 상시 존재 |
| SMB 파일공유(smbd) 프로세스 다수 | 약 1.1GB | 정상적인 직원 접속 세션 |
| 특정 컨테이너 (자동 시작 켜져 있던 것) | 1.1GB | 자동시작 옵션 꺼서 조치 완료 |
| 고아 상태 manage.py runserver | 약 110MB | 아래 참고 |
고아 프로세스 하나 발견
manage.py runserver 프로세스가 두 개 떠 있어서 처음엔 "중복 실행 아닌가" 싶었는데, 확인해보니 하나는 다른 하나의 자식 프로세스였다 — Django runserver가 기본으로 쓰는 auto-reloader가 부모/자식 쌍으로 뜨는 정상 구조라 인스턴스는 1개뿐.
다만 진짜 문제는 따로 있었다: 이 프로세스가 고아 프로세스였다.
- 부모 셸(터미널 세션)에 물려 있었는데, 그 셸은 이미 종료된 상태
- 터미널 창을 닫았지만 runserver는 계속 살아서 포트를 리슨 중이었음
- who -a로 확인해도 해당 터미널에 연결된 로그인 세션이 없었음
메모리 자체는 110MB로 크지 않았지만, "안 쓰는데 계속 떠 있는" 전형적인 케이스라 종료 조치했다.
VS Code Remote-SSH 1.9GB, 새는 건가 원래 드는 비용인가
8GB 램 기준으로 1.9GB면 전체의 약 25%. 처음엔 "이게 새로 생긴 문제 아닌가" 싶었는데, 따져보니 결론은 **"원래 있던 비용"**에 가까웠다.
- VS Code Remote-SSH + 언어 서버(Pylance 등) 조합은 원래 메모리를 꽤 먹는 도구다. 로컬 PC에서 VS Code로 개발할 때도 비슷하게 먹는데, 지금은 그게 로컬이 아니라 NAS 위에서 돌고 있는 것뿐이다. 즉 "개발하려면 어차피 드는 비용"이지, 뭔가 잘못돼서 새는 양이 아니다.
- 실제로 문제였던 건 별도로 켜져 있던 컨테이너 쪽 1.1GB였고, 이건 끄자마자 바로 회복됐다. VS Code 쪽은 "지금 실제로 쓰고 있어서" 나가는 비용이라 성격이 다르다.
다만 진짜 문제가 되는 지점은 따로 있었다 — "얼마나 오래 켜두는가".
8GB 중 시스템 기본 + SMB 등 고정 비용이 2~3GB, 컨테이너들이 최대 5.5GB까지 쓸 수 있는 상태에서, 개발할 때만 VS Code가 1.9GB를 얹는 구조였다. 그런데 퇴근 후·주말에도 Remote-SSH 연결을 계속 열어두는 습관이 있었다면, 이게 지난번 사고의 "숨은 공범"이었을 가능성이 있다. 필요할 때만 쓰는 도구가 며칠씩 상시 상주하며 1.9GB를 깔고 있으면, 그만큼 컨테이너들이 쓸 수 있는 여유가 줄어드는 셈이기 때문이다.
결론
- 개발하는 동안 VS Code Remote-SSH가 1.9GB를 쓰는 것 자체는 정상 — 문제는 이게 아님
- 문제는 개발이 끝난 뒤에도 연결을 계속 열어두는 것. VS Code Remote-SSH의 enable-remote-auto-shutdown 옵션이 켜져 있으면 클라이언트가 완전히 끊겼을 때 서버 프로세스가 정리되긴 하지만, 터미널에서 직접 백그라운드로 띄운 프로세스(runserver 같은)는 이 메커니즘 밖이라 알아서 정리되지 않는다
- 근본적으로는 "NAS 위에서 직접 개발하는 방식" 자체가 호스트에 상시 1.9GB+를 물려두는 구조라는 게 드러났다 → 이 진단 결과를 계기로 개발 방식 자체를 바꾸기로 했다 (다음 글에서 이어짐)
'IT > 작업기록' 카테고리의 다른 글
| [Git CI] pre-receive의 비밀키 복사 코드, 왜 필요한지 헷갈렸던 것 바로잡기 (0) | 2026.08.04 |
|---|---|
| [작업 기록] NAS 원격개발 → 로컬개발 전환 기록 (0) | 2026.08.04 |
| [장애 대응 기록] Synology NAS 공유폴더 접속 불가 사태 — 원인 분석과 재발 방지 (2026.07.30) (0) | 2026.07.30 |
| [NAS] SSH 접속 → 컨테이너 진입 → 안 쓰는 프로세스 정리, 명령어 모음 (0) | 2026.07.30 |
| [Linux] SSH 연결이 끊겨도 계속 도는 모니터링 — nohup / screen (0) | 2026.07.30 |