서버가 느릴 때: 어디서부터 시작할까

“모든 게 느리다”는 진단이 아니에요. 병목은 CPU, 메모리, 디스크, 네트워크 이렇게 네 가지뿐이에요. 아래는 5분 안에 그중 하나를 짚어내는 점검 순서예요.

1단계: 전체 그림

uptime
free -h
df -h

세 개의 명령어로 선택지의 절반이 바로 걸러져요. 평균 부하가 사용 중인 티어의 코어 수보다 눈에 띄게 높다면 대기열이 있는 거예요. 부하 평균을 참고하세요. available이 0에 가깝다면 메모리 문제예요. 파티션이 100% 꽉 찼다면 더 볼 것도 없어요. 공간 부족을 읽어보세요.

2단계: 정확히 무엇이 병목인지

vmstat 2 5

첫 번째 행을 제외한 평균 열들을 보세요.

• us와 sy가 높고 r이 크다면 CPU 병목이에요.
• wa가 높고 b가 크다면 디스크 병목이에요.
• si와 so가 0이 아니라면 스와핑이 일어나고 있다는 뜻이니 메모리가 부족한 거예요.
• st가 높다면 하이퍼바이저가 가져간 시간이에요. 외부 원인이니 지원팀에 문의하세요.

3단계: 원인 찾기

ps aux --sort=-%cpu | head -10
ps aux --sort=-%mem | head -10
iotop -boPan 3 | head -20        # apt install iotop
ss -tn state established | wc -l

실시간 상황은 htop 또는 btop에서 더 읽기 쉬워요. D 상태의 프로세스를 주의 깊게 보세요. 디스크를 기다리며 부하를 끌어올리는 프로세스예요.

원인이 여러분의 애플리케이션이라면 다음 질문은 그쪽으로 넘어가요. 느린 데이터베이스 쿼리, 빠진 인덱스, 너무 많은 워커, 배포 후의 무한 루프 같은 것들이요. 느려지기 시작한 시점을 로그와 맞춰보세요.

journalctl --since "1 hour ago" -p warning

4단계: 기록 확인

제어판의 /hosting/vds/m/<id>에서 “개요”를 열고 지난 하루와 일주일의 그래프를 보세요. 세 가지 전형적인 패턴이 있어요.

• 특정 시점에 한 단계 올라감 — 무언가 바뀐 거예요. 배포, 업데이트, 새 크론 작업 같은 것들이요.
• 일정에 따라 규칙적으로 치솟음 — 백그라운드 작업이에요. 밤으로 옮기거나 nice와 ionice로 제한하세요.
• 몇 주째 평평한 고원 — 여러분이 그냥 티어를 넘어선 거예요.

찾은 결과로 무엇을 할지

디스크 고원은 이렇게 계산해요. 코어당 초당 60MB 쓰기, 최소 60에서 최대 400, 읽기는 그 두 배예요. 계속 고원에 머문다면 위로 올라가지 않고서는 디스크가 빨라지지 않아요. 벤치마크를 참고하세요.

흔한 실수

• 곧바로 머신을 재부팅하기. 재부팅은 상황을 지워버리고, 한 시간 뒤에 똑같이 반복될 거예요. 먼저 수치를 모으세요.
• 한 순간만 믿기. htop을 켠 순간의 치솟음은 아무 의미가 없어요. 1분은 지켜보세요.
• 메모리가 꽉 찬 것을 문제로 보기. free가 아니라 available과 스왑을 보세요.
• 원인도 모른 채 티어 바꾸기. 메모리 누수나 루프 도는 스크립트는 새 티어로 따라갈 거예요. 다시 낮추는 것은 지원되지 않아요.

CPU, 메모리, 디스크가 모두 잠잠한데 애플리케이션이 느리다면 병목은 머신 밖에 있어요. 느린 외부 API, DNS, 클라이언트의 네트워크 같은 것들이요. 필요한 주소로 curl -w '%{time_total}\n' -o /dev/null -s를 확인해보세요.