[Chapter 2] 왜 서버가 느리지? (1)

 

서버에서 볼 수 있는 대부분의 문제는 네트워킹에서 비롯되어 발생한다. 하지만, 어떤 문제는 여전히 로컬호스트와 관련이 있다. 

이 장에서는 호스트에서 발생하는 문제를 다뤄보자. 

 

| 응답이 느려질 때 

호스트에서 찾을 수 있는 가장 흔한 문제는 응답이 느려지는 증상이다. 

• 과부하가 걸린 네트워크와 과부하가 걸린 로컬호스트 장비의 차이점을 파악할 수 있어야 한다. 

 

종종, 시스템이 느려질 때는 시스템의 특정 자원을 모두 소비했기 때문일 수도 있다. 

• 시스템의 주요 자원은 CPU, RAM, 디스크 I/O 그리고 네트워크이다. 
• 이러한 리소스를 남용하면, 최후의 수단인 재부팅이 빈번하게 일어날 수 있다. 

 

| 시스템 부하

시스템의 평균 부하는 느려진 시스템의 문제를 해결하기 위해 기초적인 지표가 된다. 

 

| uptime

느린 시스템의 문제 해결을 위해 사용되는 명령어이다. 

uptime
15:40  up 20:38, 2 users, load averages: 1.96 2.07 2.06

• load average(평균 부하) 다음에 나오는 3개의 숫자(1.96 2.07 2.06)는 시스템에서의 1분, 5분, 15분 동안의 평균 부하를 각각 나타낸다. 

 

시스템의 평균 부하는 실행 가능한 상태 혹은 중단 불가능한 상태의 프로세스들의 평균 개수와 같다. 

• 실행 가능한 상태 : 현재 CPU를 사용하고 있거나 CPU 사용을 위해 대기 중인 상태
• 중단 불가능한 상태 : I/O를 기다리고 있는 프로세스 

 

예시를 들어보자. 

• 단일 CPU 환경의 시스템
  • 평균 부하 1 : 1개의 CPU가 끊임없이 일을 하고 있다. 
  • 평균 부하 4 : 처리할 수 있는 부하보다 4배의 부하가 시스템에 걸려 있다는 의미 (4개의 프로세스 중, 3개는 CPU 자원을 사용하기 위해 대기 중) 
• 시스템의 평균 부하는 CPU 수에 따라 변하지 않는다. 
  • CPU 2개 & 평균 부하 1 : 2개 중 1개의 CPU만 일을 하고 있고, 평균 부하는 50%이다. 
• 단일 CPU 환경에서의 평균 부하 1은 4개의 CPU에서 평균 부하 4와 사용 가능한 자원의 양적인 측면에서 동일하다. 

 

1분, 5분, 15분 동안의 평균 부하는 각각의 시간 경과에 따라 부하의 평균적인 양을 나타낸다. 

• uptime을 여러 번 실행해 부하가 올라가고 있는지 내려가는 중인지 파악할 수 있다. 

 

| 평균 부하가 높다? 

어떤 평균 부하가 높은 축에 속할까? 

• 원인에 따라 달라진다. 

 

부하는 자원을 사용 중인 활성화된 프로세스의 평균 개수이다. 부하의 최대치는 몇 가지 의미를 가질 수 있다.

• 부하가 CPU에 집중된 것인지 (프로세스가 CPU 자원을 대기하고 있는 것)
• RAM에 집중된 것인지 (높은 RAM 사용률로 인해 프로세스가 RAM 영역이 아닌 SWAP 영역으로 옮겨졌을 경우) 
• I/O에 집중된 것인지 

 

예를 들어보자, 동시에 여러 지점에서 많은 수의 스레드를 사용하고 있는 애플리케이션을 실행하고 있고, 이 모든 스레드가 동시에 시작된다면, 시스템의 자원을 사용하기 위해 경합을 해야한다. 

• 이때, 시스템의 부하는 20, 40, ... 등으로 높아질 수 있다. 
• 스레드의 작업이 완료되면, 시스템 부하는 원상태로 돌아온다. 

 

시스템은 CPU에 집중된 부하를 받을 때가 I/O에 집중된 부하를 받을 때보다 더 빠르게 응답하는 것처럼 보인다. 

• CPU에 집중된 수백개의 부하를 받는 시스템은 실행 속도가 꽤 괜찮고, 디스크 I/O의 완전한 부하가 있는 시스템은 로그인 하는 데만 몇 분이 걸린다. 
• RAM이 다 소진된 시스템은 종종 I/O에 집중된 부하를 받는 것처럼 보이는데, 시스템이 디스크의 swap 영역을 사용하기 시작하면 디스크를 소모하게 되고 프로세스가 서서히 멈추게 되면서 악순환이 발생하는 것이다. 

 

| top 

과부하가 일어났을 때 사용할 수 있는 도구이다. 

• top을 입력하고 실행하면, 많은 시스템 정보를 한번에 살펴볼 수 있다. 
• top은 기본적으로 프로세스의 CPU 사용량에 따라 정렬해서 보여준다. 

 

+) top에서 모든 CPU 자원을 소비하는 프로세스를 발견했을 때 어떻게 해당 프로세스를 종료시킬 수 있을까? 

top을 입력했을 때, 프로세스의 고유 ID인 PID(시스템에서 할당 받은 모든 프로세스에 대한 고유한 번호)로 프로세스를 종료시키면 된다. 

 

kill <PID>

 

 

top으로 부하 진단 시 기본적인 단계는 top의 출력 정보로 어떤 리소스(CPU, RAM, 디스크 I/O)가 고갈 됐는지 파악하는 것이다. 

top - 07:24:43 up 1 min,  0 users,  load average: 0.71, 0.24, 0.09
Tasks:   2 total,   1 running,   1 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni, 99.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   7841.3 total,   6874.5 free,    474.2 used,    492.5 buff/cache
MiB Swap:   1024.0 total,   1024.0 free,      0.0 used.   7183.9 avail Mem
 
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  1 root      20   0    4116   2944   2688 S   0.0   0.0   0:00.00 bash
  8 root      20   0    6712   2560   2176 R   0.0   0.0   0:00.00 top

• 첫번째 줄은 uptime 명령어를 사용해서 볼 수 있는 것과 같다. 
• Cpu(s) : CPU가 현재 하고 있는 일들에 관한 정보를 제공한다. 
  • us : user CPU time, *nice가 적용되지 않은 사용자 프로세스가 소비한 CPU 사용량을 시간의 비율로 나타낸 것이다. 
  • sy : system CPU time, 커널과 커널 프로세스의 CPU 사용량을 시간의 비율로 보여준다. 
  • ni : nice CPU time, nice를 적용한 프로세스가 있을 경우 해당 프로세스의 CPU 사용량을 시간의 비율로 보여준다. 
  • id : CPU idle time, 우리가 수치를 높이고자 하는 것 중 하나이다. CPU가 사용되지 않은 유휴 상태의 비율이다. 시스템에서 이 수치가 높게 나타난다면, 시스템이 느려진 원인이 CPU 부하가 아니다. 
  • wa : I/O wait, CPU가 I/O를 기다리면서 소비한 시간의 비율을 나타낸 것이다. 느려진 시스템의 원인을 찾을 때 중요하다. 이 값이 낮으면, 디스크 혹은 네트워크 I/O가 원인에서 배제된다. 
  • hi : hardware interrupts, 하드웨어 인터럽트를 제공하는 데 CPU가 소비한 시간의 비율을 나타낸 수치이다. 
  • si : software interrupts, 소프트웨어 인터럽트를 제공하는 데 CPU가 소비한 시간의 비율을 나타낸 수치이다. 
  • st : steal time, 가상 머신을 실행 중일 경우 이 수치는 가상머신을 위해 다른 task에서 사용된 CPU 사용량에 대한 시간의 비율을 나타낸 수치이다. 

 

*nice : 다른 프로세스에 우선순위를 적용하는 것 

 

 

위와 같은 top 정보에서 살펴볼 수 있는 정보의 우선순위는 다음과 같다. 

• I/O 대기값 (wa) - CPU 유휴 상태(id) - 높은 사용자 CPU 사용률(us) 
• 낮은 I/O 대기값과 높은 CPU 유휴 상태라면, 이는 CPU의 문제가 아니다.
  • MySQL에서 속도가 느린 쿼리, 네트워크 문제, 웹서버의 문제를 살펴보는 것이 좋을 것 같다. 

 

 

데브옵스 책을 읽고 정리한 내용입니다. 
실습 환경은 ubuntu:22.04 입니다.