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

 

| 사용자 시간 진단

높은 사용자 CPU 사용률로 일어나는 과부하는 흔히 일어나고 진단하기가 비교적 간단한 문제이다. 

• 서버의 특정 서비스가 대량의 시스템 부하를 차지할 가능성이 높고, 이것들은 사용자 프로세스이기 때문이다. 
• 사용자 CPU 사용 시간이 높지만 I/O 대기 시간은 낮은 경우 시스템의 프로세스 중 어떤 프로세스가 대부분의 CPU 자원을 사용하는지 확인할 필요가 있다. 

 

기본적으로 top은 모든 프로세스를 CPU 사용률을 기준으로 정렬한다. 

 

 

가장 흔히 볼 수 있는 CPU 과부하 상황은 하나 혹은 두 개의 프로세스 혹은 많은 수의 프로세스에 의해 모든 CPU 자원이 소비되고 있는 경우이다. 

• 하나 혹은 두 개의 프로세스 : 맨 위에 있는 프로세스 혹은 두 번째 프로세스가 매우 높은 CPU 사용률을 차지할 것이고, 나머지는 상대적으로 사용률이 낮을 것이다. 
  • 이럴 경우에는 kill을 통해 CPU를 점유하고 있는 프로세스를 종료시킬 수 있다. 
• 많은 수의 프로세스 : 하나의 시스템에서 너무 많은 작업을 하게 한 경우이다. 이러한 모든 프로세스는 거의 같은 양의 CPU 자원을 소모하고 있을 것이다. 
  
  • 로그 분석, 특정 프로세스 강제 종료, 시스템 자원 증설, 하나 이상의 서버 분리, ... 등 장기간에 걸쳐 해법이 까다로워진다. 

 

| 메모리 고갈 문제

top의 결과를 다시 한 번 봐보자. 

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

• Cpu(s) 줄의 다음 2줄을 보면 다음과 같다. 
  • Mem : ... (사용 가능한 RAM의 크기가 얼마나 되는지, RAM이 얼마나 사용됐는지, 얼마나 여유가 남았는지, 얼마나 버퍼로 사용됐는지) 
  • Swap : ... (swap 영역의 사용량에 대해 해당 정보를 유사하게 보여준다.) 
• 출력된 정보에서 사용된 부분(used)과 사용 가능한 부분(free)의 수치에 속을 수 있는데 이것은 리눅스 파일 캐시 때문이다. 
  • 리눅스에서는 파일을 RAM으로 불러오고 나면, 해당 프로그램의 실행을 완료했더라도 반드시 RAM에서 제거하지 않는다. 
  • 이용 가능한 RAM이 남아있다면 리눅스는 해당 파일에 또 다시 접근할 때 훨씬 더 빨리 접근할 수 있게 RAM에 해당 파일 캐시를 남겨둘 것이다. 
  • 시스템의 활성화된 프로세스가 RAM을 필요로 하는 경우, 리눅스는 필요에 따라 캐시로 저장된 파일을 제거하거나 새로운 프로세스를 위한 메모리를 확보한다.
  • 따라서, 장시간 실행되는 서버는 시간이 지남에 따라 파일 캐시가 증가하면서 사용 가능한 RAM이 점점 줄어든 것처럼 보이는 현상이 보이는 것은 흔하다. 
• 세부적인 문제를 진단하기 전에 메모리 문제를 배제할 수 있는지 살펴보는 것은 매우 중요하다. 

 

위의 내용을 간단히 요약해보자면, RAM이 실제로 프로세스에 의해 얼마나 사용되고 있는지 파악하고 싶다면 사용된 RAM에서 파일 캐시 부분을 제외해야 한다는 것이다. 

예를 들어, 997,408k RAM이 사용됐고 286,040k의 리눅스 파일 캐시가 사용됐다면 실제로는 711,368k 만큼의 RAM이 사용됐다는 뜻이다. 

• swap이 일부 사용 중인 것이 발견되는 것은 당장의 문제는 아니다. 
• 만약, 실제 사용된 메모리에서 파일 캐시를 뺀 값도 크고 스왑 사용도 크다면 이때는 아마 메모리에 문제가 발생한 것으로 판단될 수 있다. 

 

위와 같은 방법으로 메모리 문제를 파악했다고 가정해보자. 

그럼, 그 다음은 어느 프로세스가 RAM을 고갈시키고 있는지를 파악하는 것이다. 

 

top에서는 기본으로 프로세스의 CPU 사용률을 기준으로 정렬을 시킨다고 하였다. 

• 이를 RAM 사용률 기준으로 변경해보자. 
• top을 실행한 상태에서 m 키를 누르는 것이다. 
• %MEM 컬럼을 살펴보고 상단에 위치한 프로세스가 RAM의 대부분을 사용하고 있는지 눈여겨 보자. 
  • 만약, 높은 RAM 사용률을 보이는 프로세스를 찾았다면, 해당 프로세스들을 강제 종료할 지 결정할 수 있다. 

 

추가적으로, 리눅스 커널에서는 out-of-memory(OOM) killer도 제공한다. 

이것은 시스템이 위험할 정도로 낮은 RAM을 확보한 상태에서 실행되고 있을 때 작동한다.

• RAM이 거의 고갈됐을 때 OOM Killer는 프로세스를 강제 종료하기 시작한다. (OOM Killer가 작동했으면, /var/log/syslog에 Out of Memory: Killed process 라는 log가 생긴다.) 
• OOM Killer는 RAM을 모두 소모하고 있는 프로세스를 종료시키기 위해 작동하지만, 이렇게 작동하지 않는 경우도 있다.
  • 실제 원인인 프로세스의 종료가 아닌 sshd 같은 프로그램이나 다른 프로세스를 강제 종료시킬 수도 있다. 
• 이러한 이벤트가 발생하게 되면, 시스템이 불안정해진다. 따라서, 모든 시스템 프로세스가 제대로 실행되게 하기 위해서 시스템을 재부팅 해야 한다.