ACTIVE INCIDENT
00:00 elapsed
LABLAB-LINUX-07-PROCESS-RESOURCESSEV-3
프로세스 CPU/메모리 — top/htop/sar로 병목 특정
ELAPSED
00:00
PHASE
0 / 5
SLA
30분
🐧 Linux
← 목록
INCIDENT RESPONSE
0 / 6 단계 완료
📚 PREREQUISITES
Theorylinux/process-management
Theorylinux/system-monitoring
TRACK
LINUX
SLA
30분
SEV
SEV-3
PHASES
4단계
ENV
local
INCOMING TICKET
“팀 채널 긴급 메시지: "운영 서버가 엄청 느려요. 페이지 로딩이 10초 넘게 걸리고 있어요."”
YOUR ROLE
인프라/SRE 엔지니어
IMPACT IF UNRESOLVED
현재 SLA 위반 중. 분 단위로 해결 못하면 CS 에스컬레이션 + 경영진 보고 대상. CPU 또는 메모리 병목 원인을 특정하지 않으면 장애 장기화
🚨INCIDENT BRIEF
오후 2시, 마케팅팀에서 프로모션 메일을 발송하고 30분 후부터 서비스 응답이 급격히 느려지기 시작했습니다.
모니터링 알림은 없었지만 사용자 민원이 쏟아지고 있고, CS팀에서 "서버 뭔가 이상한 것 같아요"라는 메시지가 날아왔습니다.
서버에 SSH로 접속해 보니 명령어 입력 후 응답이 수 초씩 지연됩니다.
CPU 100%인지 메모리 부족인지 아니면 다른 원인인지를 빠르게 구분하여 원인 프로세스를 특정해야 합니다.
top, ps, dmesg, sar를 순서대로 활용해 병목 지점을 찾아내고 적절한 조치 방향을 결정합니다.
⏱ 30분📊 입문🔧 4단계#top#htop#ps#sar
MISSION
1
top으로 전체 리소스 현황 스냅샷 확인
top 출력의 load average, CPU 사용률(%us, %sy, %wa), 메모리 사용량을 읽어 병목 유형(CPU vs 메모리 vs I/O)을 판단한다
2
특정 프로세스 상세 확인 — ps aux와 htop
top에서 발견한 고부하 프로세스의 전체 명령행, 실행 경로, 스레드 수 등 상세 정보를 ps aux로 확인한다
3
OOM killer 발동 여부 확인 — dmesg
dmesg 로그에서 OOM(Out of Memory) killer 발동 기록을 찾아 메모리 부족으로 프로세스가 강제 종료되었는지 확인한다
4
sar로 리소스 히스토리 분석
sar로 시간대별 CPU/메모리 사용률 추이를 확인하여 병목이 발생한 정확한 시간과 증가 패턴을 파악한다
📌 선수 지식
• [이론] linux/process-management
• [이론] linux/system-monitoring
ℹ️ 실습 환경
환경: local
필요 도구: top, ps, dmesg, free, sar
검증 스크립트: /labs/lab-linux-07-process-resources/scripts/verify.sh
🔒
실습 실행은 Pro 플랜 전용입니다
인시던트 브리프와 학습 자료는 지금 바로 확인할 수 있습니다. 실제 실습 진행 및 터미널 사용은 Pro 플랜에서 가능합니다.
Pro로 업그레이드 →
>_ LAB TERMINAL↔ 너비 조절
NOTES