과부하 현상(Over Load Average)에서 2가지 원인(CPU bound job , I/O bound job)에 따라 발생할 수 있는 시나리오

[whitejh]

• 시나리오 구상 (how가 아니라 what 위주로)
  • monitor: 해당 이슈가 발생했다는 사실을 어떻게 탐지할 것인지
  • identify: 해당 이슈가 어디서 발생했고 시스템에 어떤 영향을 얼마나 끼치고 있는지를 어떻게 식별할 것인지
  • analysis: 해당 이슈가 왜 발생했는지를 어떻게 분석할 것인지
  • suggest: 해당 이슈에 대한 솔루션을 어떻게 제안할 것인지
• 위에서 구상한 시나리오들 하나씩 구현

시나리오 구상 (how가 아니라 what 위주로)

monitor: 해당 이슈가 발생했다는 사실을 어떻게 탐지할 것인지

해당 이슈 -> Load Average 높음 (과부하) 가 예상치 못한 시점에서 발생한 것을 탐지

Load Average 설명 및 코드

Load Average란?

시스템의 부하를 평균치로 알려주는 값

얼마나 많은 프로세스가 실행 중 혹은 실행 대기중인지를 의미하는 수치

running 상태(CPU 자원이 많이 필요한)의 프로세스의 수와 uninterruptible(I/O 자원이 많이 필요한) 프로세스의 수를 합한 값

=> 즉, CPU를 사용하자고 해도 다른 프로세스가 CPU를 사용하고 있어서 기다리고 있는 프로세스와 디스크 입출력이 끝날 때까지 기다려야만 하는 프로세스 2가지로 나타내어지는 값

I/O bound job: I/O 빈도가 많은 프로세스
CPU bound job : I/O 빈도가 낮고, CPU를 오래 사용하는 프로세스

해당 이슈를 탐지한 방법

uptime 명령어로 확인 가능

/proc/loadavg 파일을 열어서 그 파일의 내용을 읽고 화면에 출력해주는 명령

즉, 직접 Load Average 값을 계산하는 게 아니고 커널이 미리 준비해둔 /proc/loadavg를 단순히 읽어서 보여주는 명령

identify: 해당 이슈가 어디서 발생했고 시스템에 어떤 영향을 얼마나 끼치고 있는지를 어떻게 식별할 것인지

해당 이슈 : Load Average 높음 (과부하)

발생 원인1 : CPU 부하가 높은 경우

• 해당 이슈가 어디서 발생?

  • 사용자 프로그램의 처리 부분 혹은 시스템의 프로그램 (top, sar과 같은 명령어 이용)

• 시스템에 어떤 영향을 얼마나 끼치고 있는지 어떻게 식별?

  • 프로세스 상태나 CPU 사용시간 등을 보면서 원인이 되고 있는 프로세스 찾기 (ps 명령어 이용)

발생 원인2 : I/O 부하가 높은 경우

• 해당 이슈가 어디서 발생?

  • 특정 프로그램(프로세스) 혹은 디스크에서 발생

• 시스템에 어떤 영향을 얼마나 끼치고 있는지 어떻게 식별?

  • swap이 발생하고 있는 경우 특정 프로세스가 극단적으로 memory를 소비하고 있지 않는지 ps 명령어로 확인

  • swap : 물리메모리가 부족할 경우를 대비해서 만들어 놓은 영역

  • swap 영역은 물리 메모리가 아니라 디스크의 일부분을 메모리처럼 사용하기 위해 만들어놓은 공간이기 때문에,
    메모리가 부족할때 사용한다고는 하지만 메모리에 비해 접근과 처리 속도가 현저하게 떨어진다.
    그래서 swap 영역을 사용하게 되면 시스템의 성능 저하가 일어난다.

  • free 명령어를 사용해 swap 영역을 사용했는지 확인 가능

  • swap 영역을 사용했다는 것 자체가 시스템에 메모리와 관련해 문제가 있을 수 있다는 의미

  • 아주 적은 양이라도 썼다면 반드시 살펴봐야하고 누가 swap을 사용했는지도 매우 중요한 판단 기준

  • 특정 프로세스가 사용하는 전체 swap 영역에 대한 정보가 필요한 경우
    /proc/< pid > / status 파일을 통해서 확인 가능

  analysis: 해당 이슈가 왜 발생했는지를 어떻게 분석할 것인지

  해당 이슈 : Load Average 높음 (과부하)

  vmstat 명령어로 부하의 정체 파악

  • Load Average만으로는 CPU 작업에 부하가 많은지, I/O 작업에 부하가 많은지 파악하기 힘듦으로 vmstat 명령어로 간단하게 확인가능
    

1. 프로세스
   r: 실행시간을 기다리고 있는 프로세스 수 (CPU 부하 프로세스 수)
   
   b: 인터럽트 안되는 sleep 프로세스 수 (I/O 부하 프로세스 수)
   

2. 메모리
   swpd: 가상메모리 사용량
   
   free: 유휴메모리 양
   
   buff: 버퍼메모리 양
   
   cache: 캐시메모리 양
   
   inact/active: 비활성화/활성화 메모리 양
   

3. 스왑메모리
   si/so: 디스크→메모리 / 메모리→디스크 스왑량 (/s)
   

4. 입출력 IO
   bi / bo: 장치에서 받아오는 블록, 장치로 보내는 블록 (blocks/s).
   

5. 시스템
   in: 초당 인터럽트 수
   
   cs: 초당 문맥교환 수
   

6. CPU 사용률(%)
   us: 비커널 코드 소비 시간 (사용자 시간)
   
   sy: 커널 코드 소비 시간 (시스템 시간)
   
   id: 유휴 시간
   
   wa: 입출력 대기 시간
   
   st: 가상머신으로부터 뺏은 시간
   

• r (CPU 부하 프로세스 수) ,b (I/O 부하 프로세스 수) 를 통해
  CPU 부하가 많은지, I/O 부하가 많은지 파악 가능

• 특히 vmstat 명령어를 통해 중요하게 볼 지표는 bi, bo 지표
  이를 통해 실제로 얼마나 I/O 가 발생하고 있는지 그 절대치 파악 가능
  top과 sar 같은 명령어들은 I/O 대기율까지만 확인 가능

top 명령어로 프로세스 정보 확인

• top 명령어를 통해 Load Average, CPU 사용율, 메모리 사용량 파악 가능

  swap 메모리의 사용 여부가 시스템의 상태에 중요한 영향을 끼친다   
  VIRT: 해당 프로세스가 확보하고 있는 가상 메모리 영역의 크기   
  RES: 해당 프로세스가 확보하고 있는 물리메모리 영역의 크기    
  SHR: 다른 프로세스와 공유 하고 있는 Shared Memory의 양   
  S: 프로세스 상태   
  실 가용 메모리 = free + buffers + cached Mem   
  실 사용 메모리 = used - (buffers + cached Mem)   

1. VIRT는 실제로는 할당되지 않은 가상의 공간이기 때문에 해당 값이 크다고 해도 문제가 되진 않는다.
   실제 사용하고 있는 메모리는 RES 영역이기때문에 메모리 점유율이 높은 프로세스를 찾기 위해서는 RES 영역이 높은 프로세스를 찾아야 한다.

2. swap이 발생하고 있을 경우는 물리 메모리가 부족하다는 증거이므로, RES의 크기가 몹시 큰 프로세스가 없는 지를 파악한다.

3. 좀비 프로세스가 사용한 PID가 정리되지 않고 쌓이면 새로운 프로세스에 할당할 PID가 모자라게 되고, 이는 결국 더이상 PID를 할당하지 못하는 PID 고갈을 일으킬 수 있다.

sar 명령어로 프로세스 정보 확인

1. CPU 사용률(오늘)
   

user: 사용자 모드에서 CPU가 소비한 시간의 비율
nice: nice로 스케줄링의 우선도를 변경한 프로세스가 사용자 모드에서 CPU를 소비한 시간의 비율
system: 시스템 모드에서 CPU가 소비한 시간의 비율
iowait: CPU가 디스크 I/O 대기를 위해 idle상태로 소비한 시간의 비율
steal: Xen등 OS의 가상화를 이용하고 있을 경우, 다른 가상 CPU의 계산으로 대기된 시간의 비율
idle: CPU가 디스크 I/O 등으로 대기되지 않고, idle상태로 소비한 시간의 비율

2. 시간 추이별 Load Average 확인
   

3. 물리 메모리 사용 현황 확인(오늘)

kbmemfree : 물리 메모리의 남은 용량(kbytes)
kbmemused : 사용중인 물리 메모리 양(kbytes)
%memused : 물리 메모리 사용률
kbbuffers : 커널에서 buffer 메모리로 총 사용된 물리 메모리의 양 (kbytes)
kbcached : 커널에서 cache data 로 사용된 총 물리 메모리의 양(kbytes)
kbcommit : 현재 작업을 위해 필요한 메모리의 총량(kbytes),메모리 부족이 발생하지 않기 위한 RAM/swap 사용량의 추정치
%commit : 현재 작업을 위해 필요한 메모리 총량의 %
kernel은 보통 메모리를 overcommits하므로 일반적으로 100%를 넘을 것이다.

suggest: 해당 이슈에 대한 솔루션을 어떻게 제안할 것인지

1. CPU 부하가 높은 경우

   • 원인이 되고 있는 프로세스를 찾은 후 상세하게 조사해서
     strace 명령어로 추적하거나 oprofile로 프로파일링해서 병목지점을 좁혀나간다.

2. I/O 부하가 높은 경우

• ex1) swap이 발생하고 있는 경우

  • 특정 프로그램 오류로 메모리를 지나치게 사용하는 경우, 프로그램을 개선한다.
    탑재된 메모리가 부족한 경우, 메모리를 증설한다. 메모리를 증설할 수 없는 경우에는 분산을 검토

• ex2) swap이 발생하지 않고, 디스크로의 입출력이 빈번하게 발생하고 있는 상황인 경우

  • 캐시에 필요한 메모리가 부족한 경우로 생각해 볼 수 있다.
    따라서 해당 서버가 저장하고 있는 데이터 용량과 증설 가능한 메모리량을 비교해서 다음과 같이 나눠서 검토한다.
    (1) 메모리 증설로 캐시 영역을 확대시킬 수 있는 경우, 메모리를 증설한다.
    (2) 메모리 증설로 대응할 수 없는 경우, 데이터 분산이나 캐시 서버 도입 등을 검토
    프로그램을 개선해서 I/O 빈도를 줄이는 방법도 검토