여기서는 멈추세요
- 명령 출력의 서버·서비스·경로가 예상 대상과 다르면 변경 단계로 넘어가지 않습니다.
- 현재 접속 세션, 백업 또는 콘솔 복구 경로를 확보하지 못했다면 상태 변경 명령을 실행하지 않습니다.
MEMORY
메모리 부족과 OOM 종료를 확인할 때
가용 메모리, Swap, 프로세스 점유율과 커널 OOM 기록을 순서대로 확인합니다.OOM killed메모리 부족swapfreeKilled process
환경systemd 기반 GNU/Linux
분류CPU·메모리
검토일2026-08-27
진행5단계 · 조회 우선
SAFE OPERATING BOUNDARY
중단·복구 기준부터 확인하세요
복구 기준
변경 전 설정과 출력값을 기록하고, 예상과 다른 결과가 나오면 추가 변경을 멈춘 뒤 승인된 운영 복구 절차로 되돌립니다.
담당자에게 전달할 자료
- 장애 발생 시각·정상화 시각과 원문 오류 메시지
- 민감정보를 제거한 조회 명령 출력과 변경 전후 차이
- 조치 후 동일 조건으로 수행한 재검증 결과
BEFORE YOU START
이런 증상에서 시작합니다
- 프로세스가 갑자기 종료
- Killed 표시
- 응답 지연
- 컨테이너 OOMKilled
CHECK THE BRANCH
놓치기 쉬운 원인 분기
호스트 OOM인지 확인
커널 journal에 Killed process 기록이 있으면 호스트 OOM 흐름을 우선 확인합니다.
컨테이너·서비스 제한인지 확인
호스트에 여유가 있어도 cgroup의 memory.max 또는 Docker 메모리 제한에 도달하면 해당 작업만 종료될 수 있습니다.
일시적 급증과 누수 구분
한 시점의 RSS가 아니라 시간에 따른 증가, 재시작 후 회복 여부, 동일 요청에서의 반복 여부를 기록합니다.
FOLLOW THE FLOW
순서대로 확인하기
조회시스템을 변경하지 않는 확인 단계
가용 메모리와 Swap 확인
free의 free 열만 보지 말고 available과 Swap 사용량을 봅니다.
메모리 요약
free -hSwap 장치
swapon --show결과 읽기
available이 지속적으로 낮고 Swap이 급증하면 메모리 압박 가능성이 큽니다.
다음 판단
다음 단계에서 점유 프로세스를 찾습니다.
조회시스템을 변경하지 않는 확인 단계
메모리 상위 프로세스 확인
RSS와 실행 시간을 함께 확인합니다.
메모리 상위 20개
ps -eo pid,ppid,user,%mem,rss,etime,comm --sort=-%mem | head -205초간 메모리·I/O 흐름
vmstat 1 5결과 읽기
특정 프로세스 RSS가 계속 증가하면 누수 가능성을 검토합니다.
다음 판단
프로세스와 서비스 이름을 기록합니다.
조회시스템을 변경하지 않는 확인 단계
커널 OOM 기록 확인
재부팅 전후 기록 범위를 구분합니다.
오늘의 OOM 흔적
journalctl -k -g 'Out of memory|Killed process' --since today --no-pager현재 부팅의 커널 경고
journalctl -k -p warning -b --no-pager결과 읽기
Killed process의 PID·프로세스 이름과 당시 메모리 사용량을 확인합니다.
다음 판단
컨테이너라면 해당 컨테이너 제한도 확인합니다.
조회시스템을 변경하지 않는 확인 단계
서비스 제한과 반복 패턴 확인
systemd unit에 설정된 메모리 제한을 확인합니다.
서비스 메모리 설정
systemctl show SERVICE_NAME -p MemoryCurrent -p MemoryMax -p MemoryHigh최근 서비스 로그
journalctl -u SERVICE_NAME --since '-1 hour' --no-pager결과 읽기
MemoryMax가 예상보다 작거나 재시작 루프가 있는지 봅니다.
다음 판단
설정 변경 전에 애플리케이션의 정상 요구량을 산정합니다.
변경데이터·서비스 상태가 달라질 수 있는 단계
조치 후 안정화 확인
Swap 추가나 MemoryMax 변경은 성능과 장애 양상을 바꾸므로 별도 변경 계획으로 진행합니다.
변경 단계입니다. 실행 전 대상 이름과 경로, 서비스 중단 영향, 복구 방법을 다시 확인하세요.
서비스 재시작이 승인된 경우
sudo systemctl restart SERVICE_NAME조치 후 추적
free -h && systemctl is-active SERVICE_NAME결과 읽기
available 메모리가 회복되고 OOM 로그가 다시 생성되지 않아야 합니다.
다음 판단
재발 시 누수 분석 또는 용량 증설이 필요합니다.
PRIMARY REFERENCES
공식 문서
- Linux Kernel — Out Of Memory Handling
- procps-ng 공식 문서
- systemd systemctl 공식 매뉴얼
- systemd journalctl 공식 매뉴얼
- Linux Kernel — cgroup v2
- Docker — 컨테이너 리소스 제한
배포판과 버전에 따라 옵션·로그 위치가 다를 수 있습니다. 실행 전 서버의 --help와 로컬 매뉴얼을 함께 확인하세요.