개요

안녕하세요. 저희는 오픈소스컨설팅 리눅스팀 입니다. 저희는 리눅스 및 관련 솔루션에 대해 기술지원을 하고 있습니다.

이번 글에서는 서버 모니터링을 위한 여러 툴 중에서도 기본적으로 많이 사용하시는 sar에 대해 다뤄보려고 합니다.

리눅스 서버를 운영하다보면 리소스 사용량을 확인해야 할 경우가 있는데요.

• 리소스 사용량 그 자체에 대한 리포팅
• 시스템 문제 분석

이러한 경우 대부분의 리눅스 배포판에 설치되는 sar 를 활용하면 서버에서 사용되는 자원의 사용량을 정확하게 파악 할 수 있습니다.

sar 외에도 많은 유용한 도구들이 있지만, sar 는 이미 설치되어 있거나 기본 리포지토리에서 가져올 수 있어서 분석을 빠르게 시작할 수 있다는 장점이 있습니다.

sar 는 system activity report 명령 도구입니다. 현재 사용량 뿐 아니라, 시스템에 예약작업으로 등록되어 있어서 리소스 사용량을 일정 주기마다 기록/저장하여 이전의 상태와 변화 추이를 확인할 수 있다는 장점이 있습니다.

일반적으로는 OS 설치하면서 같이 설치되는 경우가 많지만, minimal 수준으로 설치하실 경우 설치가 되어 있지 않을 수 있습니다.

그런 경우에는 당황하지 마시고 sysstat 이라는 패키만 설치해 주시면 바로 사용이 가능하니 이점 꼭 기억하시기 바랍니다.

sar를 사용할 때 여러 option을 주어서 다양한 정보를 확인 할 수 있는데요.

실제 이슈 케이스에 따라 어떤 field를 확인하고 분석할 수 있는지 알아보도록 하겠습니다.

---

본문

---

분석 사례 #1

Memory 100% , Reboot
이 사례는 시스템이 메모리를 100% 사용 한 후 reboot 된 상황이고,
sar 데이타를 통해 부하의 원인 분석을 진행 하였습니다.
sar 데이타는 11:25:04 AM을 마지막으로 더 이상 찍히지 않았고, 이후 시스템은 리부팅 되었습니다.
참고로, 이 사례에서 sar 는 1분 단위로 수집 되었습니다.
이 시스템의 OS는 RHEL7 입니다.

Memory 사용 정보 확인 (-r)

우선 sar 의 메모리 정보를 확인해 보겠습니다.

메모리 정보를 확인하는 여러 옵션 중에서 일단 -r 옵션을 통해서, 확인해 보겠습니다.

• 위에서 주목할 필드는 kbactive 와 %memused 입니다. 필드를 설명하면,
  • kbactive : 프로세스에 의해서, 비교적 최근에 메모리로 로드된 메모리 공간의 크기를 의미하며, kilobyte 단위의 표시입니다. 최근에 로드된 메모리는 프로세스에서 사용하는 부분일 수 있으므로, 다른 프로세스의 메모리 요청시에도 되도록이면 이 영역에서는 잘 회수되지 않습니다.
  • %memused : 현재 시스템의 전체 메모리 중에 사용중인 메모리의 비율을 표시합니다.
• 11:21:54 AM 시점을 보면, 메모리 사용률(kbmemused)가 99%를 달성하였습니다. 그리고, kbactive 값이 크게 약 9GB 수준에서 28GB 수준으로 증가하였습니다. 이는, 어떤 프로세스에 의해서 메모리 요청이 급증한 것으로 볼 수 있습니다.
• 하지만 이 데이터만으로는 해당 시점에 메모리가 부족했다고 판단하기는 좀 부족한 것 같습니다.

Page 사용 정보 확인 (-B)

추가적인 메모리 분석을 위해, -B 옵션을 통해서 page 사용 정보를 확인해 보겠습니다.

• 여기서 확인할 필드들은 모두 의미가 있습니다.
  • pgpgin/s : 초당 시스템이 디스크에서 페이징한 총 킬로바이트 수입니다.
  • pgpgout/s : 초당 시스템이 디스크로 페이징 아웃한 총 킬로바이트 수입니다.
  • pgfree/s : 초당 시스템에서 사용 가능한 목록에 배치한 페이지 수입니다.
  • pgscank/s : kswapd 데몬이 초당 스캔한 페이지 수입니다.
  • pgscand/s : 초당 직접 스캔한 페이지 수입니다
  • pgsteal/s : 메모리 요구를 충족하기 위해 시스템이 초당 캐시(페이지 캐시 및 스왑 캐시)에서 재확보한 페이지 수입니다.
  • %vmeff : pgsteal / pgscan으로 계산되는 이것은 페이지 회수 효율성의 지표입니다.
• 11:21:54 AM 부터 pgpgin/s 와 pgpgout/s 가 크게 증가한 것을 보아 디스크를 읽고 쓰는 작업이 다량 발생한 것을 알 수 있습니다. 위의 sar -r 에서 같은 시점에 kbactive 값처럼 메모리가 급증하고 page in/out 으로 메모리와 디스크간의 I/O 가 많이 일어난 것으로 보입니다.
• 같은 시점에 %vmeff 는 24.03%을 기록하였습니다. %vmeff 는 pgsteal (페이지 재사용) / pgscan (페이지 스캔) 의 비율이며, 페이지 재사용 효율을 백분율로 보여줍니다.
• 즉, %vmeff 를 통해서 프로세스의 메모리 요청으로 필요한 만큼 메모리를 회수했는지를 알 수 있습니다. 모든 페이지를 회수하는 상태는 100%이며, 페이지 스캔이 없는 경우에는 0% 으로 표시됩니다. 이 값은 0% 이거나 100% 에 가까워야 정상입니다. 만약 100%보다 낮은 수치가 있을 경우에는 메모리 할당 요청을 하였으나, 원하는 시간 내에 처리 되지 않았을 가능성이 있습니다.
• 11:25:04 AM 에 24.03% 라는 것은 필요한 메모리 할당이 늦어졌다는 의미이며 메모리가 부족한 상태였음을 알 수 있습니다. 그리고 메모리와 디스크간의 I/O가 많았음을 추정해 볼 수 있습니다.

Swap 사용 정보 확인 (-S)

메모리가 부족한 상황에서의, 디스크 I/O 라면 swap In/Out 이 발생했을 수도 있습니다.
-S 옵션을 통해서, swap 공간의 사용량을 확인해 보겠습니다.

• 여기서 볼만한 필드는 %swpused 입니다.
  • %swpused : 사용중인 swap 메모리 크기
• 11:21:54 AM 메모리 사용량이 99.71% 까지 증가한 후에 11:21:54 AM 부터, 11:25:04 AM 까지 swap 사용률(%swpused)도 0% → 100%로 증가하였습니다.
• 최종적으로 메모리 사용률(kbmemused) 과 swap 사용률(%swpused)이 100% 가까이 증가하였고, %vmeff 값을 통해 필요한 메모리 할당이 원하는 시간 내에 처리되지 않았음을 알 수 있습니다. 따라서 시스템의 메모리가 부족한 상황이였음을 알 수 있습니다.

기타 리소스 사용 정보 (CPU usage)

이제 CPU 부하와 run queue를 확인해보겠습니다.

-u 옵션으로 CPU 부하를 확인할 수 있습니다.

• 여기서 확인해 볼 필드는 %iowait 입니다.
• %iowait : 프로세스가 디스크 I/O 요청으로 대기 상태에 있었던 시간의 백분율
• %iowait의 수치가 11:21:54 AM 기점으로 크게 증가하였습니다. 이는 I/O 요청으로 대기 중인 상태인 프로세스가 증가하였고, 디스크 액세스가 발생하고 있다고 있다는 것을 알 수 있습니다.
• sar -B에서도 디스크 I/O가 많이 발생했다는 것을 확인하였지만 sar -u 로도 프로세스의 I/O 요청이 많았다는 것을 확인할 수 있습니다.

기타 리소스 사용 정보 (process queue)

 -q 옵션으로 큐(run queue) 길이와 Load Averages를 확인할 수 있습니다.

• 여기서 확인해볼 필드는 runq-sz와 blocked 입니다.
  • runq-sz : 런타임에 실행되기 위해 대기 중인 프로세스 수
  • blocked : I/O 요청이 완료되기를 기다리는 프로세스 수
• 11:25:04 AM 에 runq-sz 가 33이며 대기열에 프로세스가 많이 쌓여 있는 것을 알 수 있습니다.
• blocked는 I/O가 완료되기를 기다리는 프로세스 수를 의미하기 때문에 이 수치가 11:20:01 AM ~ 11:21:54 AM 에 4에서 61까지 증가한 것으로 보아 I/O 요청이 많았다고 추측할 수 있습니다.
• 다량의 디스크 I/O 요청으로 swap을 포함한 메모리 사용이 100%까지 증가하였고, 이로 인해 CPU에서 프로세스를 처리하지 못해 큐에 프로세스가 많이 쌓였다고 추측해 볼 수 있습니다.

분석 결과

sar 의 -r , -B 옵션을 통해서 memory usage 와 process 의 memory 요청이 급증한 것을 확인하였습니다.그리고, sar -S 로 memory 가 부족으로 인한 swap used 증가를 확인했습니다.그 이후에는 sar 정보나 kernel dump 등이 발생하지는 못하였지만, 계속적인 memory 부족이 process 수행이나 block I/O 동작등의 지연을 유발하고 그로 인해 전체적인 시스템 동작 문제로 kernel 이 시스템을 reboot 했을 것으로 추정할 수 있을 것 같습니다.

---

분석 사례 #2

Memory Usage 증가와 같은 사례는 시스템 메모리가 증가된 원인 확인이 필요했고, sar 를 통해 메모리 변화 등을 통해 어떠한 특이사항이 있는지 확인해 보고자 분석을 진행하였습니다. 참고로, 이 사례에서 sar 는 1분 단위로 수집되었습니다. 이 시스템의 OS는 RHEL6 입니다.

Memory 사용 정보 확인 (-r)

메모리 정보를 확인하는 -r 옵션을 통해서, 확인해 보겠습니다.

• 위에서 주목할 필드는 %memused 입니다. 필드를 설명하면,
  • %memused : 현재 시스템의 전체 메모리 중에 사용중인 메모리의 비율을 표시합니다.
• %memused 는 98%~99%의 사용률을 유지하고 있습니다.
• kbcached와 kbbuffers 의 값은 합쳐서, 2~3GB 정도를 차지하고 있습니다.
• 전체 메모리 대비 kbcached와 kbbuffers를 제외하고도, 30GB 정도로 90% 이상의 메모리를 사용하므로 메모리 사용량이 높다고 볼 있습니다.

Swap 사용 정보 확인 (-S)

메모리 사용률이 높으므로, 혹시나 swap 영역을 사용하는지 확인해 보겠습니다.
-S 옵션을 통해서, swap 공간의 사용량을 확인해 보겠습니다.

• 여기서 확인할 필드는 %swpused 입니다.
  • %swpused : 사용중인 swap 메모리 크기
• 메모리 사용률은 높지만 %swpused의 변화가 크지 않습니다.
• swap In/Out 으로 인하여, 시스템에 영향이 있다고 보기는 어려울 것 같습니다.

Page 사용 정보 확인 (-B)

위에서의 -r 옵션을 통한 내용은 현재 메모리가 차지하고 있는 정도만을 표시하므로, 실제로 메모리에서의 I/O 가 얼마나 많이 발생하는지는 확인이 어렵습니다.
메모리에서의 paging In/Out 을 확인하기 위해, -B 옵션을 사용해서 확인해 보겠습니다.

• 여기서 다음 필드들이 의미가 있을 것 같습니다.
  • pgpgin/s : 초당 시스템이 디스크에서 페이징한 총 킬로바이트 수입니다.
  • pgpgout/s : 초당 시스템이 디스크로 페이징 아웃한 총 킬로바이트 수입니다.
  • %vmeff : pgsteal / pgscan으로 계산되는 이것은 페이지 회수 효율성의 지표입니다.
• 2시에서 2시 27분까지 pgpgin/s 이 급격하게 증가한 후에 감소하는 것을 확인할 수 있습니다.
• 다른 날짜의 sar파일을 확인해보니, 2시마다 같은 패턴으로 pgpgin/s 이 증가한 후에 감소하는 것을 확인할 수 있습니다. 따라서 2시마다 cron 에 의해 어떠한 테스크(Task)가 동작한다고 추측해 볼 수 있습니다.
• 실제 cron 설정 파일을 확인해보니 2시마다 백업 스크립트가 실행되고 있었습니다.
• %vmeff 값이 100% 또는 0%에 가까운 수치를 기록합니다. 모든 페이지를 회수하는 상태는 100% 이고, 페이지 스캔이 없는 경우에는 0% 으로 표시되므로 메모리 할당 요청을 하였을 때 원하는 시간 내에 처리되었다고 볼 수 있습니다.
• 따라서 메모리 사용률이 98%~99%의 높은 수치를 유지함에도 OOM 이 발생하지 않는 이유는 memory page를 요청할 때마다 회수하여 사용하였기 때문입니다.
• 메모리 부족현상은 발생하지 않고 있는 것으로 보입니다.

Block I/O 사용 정보 확인 (-b)

직전 paging 데이타에서의 pgpgin/s , pgpgout/s 이 발생하는 것으로 보아, 추가적으로 memory 와 disk 간의 I/O 정보를 확인해 보겠습니다.
-b 옵셥으로 I/O 전송률 통계를 확인해 볼 수 있습니다.

• 여기서 다음 필드들이 의미가 있습니다.
  • tps : 물리적 장치에 발행된 초당 총 전송 수입니다. 여기서 전송은 물리적 디스크에 요청한 I/O이다
  • rtps : 물리적 장치에 발행된 초당 총 읽기 요청 수입니다.
  • wtps : 물리적 장치에 발행된 초당 총 쓰기 요청 수입니다.
  • bread/s : 초당 블록 단위로 장치에서 읽은 총 데이터 양입니다.
  • bwrtn/s : 초당 블록 단위로 장치에 기록된 총 데이터 양입니다.
• rtps와 bread/s 값이 2시에 증가한 것을 확인하였고, 다른 sar파일 또한 같은 시간대인 2시에 rtps와bread/s만 증가한 것을 확인하였습니다. 이러한 결과로 cron 으로 실행된 작업이 디스크 i/o 작업이라는것을 추측해볼 수 있습니다.

분석 결과

위의 데이터들을 종합하여 결론을 내보면, 메모리 사용 정보(-r)에서는 특이한 변화량은 없었고, Swap Out 이 거의 발생하지 않은 것으로 볼 때 메모리 부족현상이 시스템에 영향을 줄만큼 있지는 않은 것으로 판단됩니다. 다만, 페이징 정보( -B 옵션) 와 Block I/O정보( -b )를 봤을 때, 2시경에 Block I/O 가 많이 증가하면서 paging in/out이 상대적으로 많이 발생했다는 것을 볼 수 있습니다. 이를 볼 때, 이 시점에 block read I/O 를 많이 발생시키는 process 가 수행되었을 가능성이 있어 보입니다. 실제로는 해당 시점에 백업이 수행되어, 많은 block read I/O 가 발생 하였고 그로 인해서, 메모리 사용률도 어느 정도 높아진 것으로 확인이 되었습니다.

---

분석 사례 #3

CPU Load High이 사례는 일시적인 load High 로 인해, HA 솔루션에서 리소스가 Failover 된 것으로, sar 를 통해 리소스 사용량 변화 등을 확인하기 위해서 분석을 진행하였습니다. 참고로, 이 사례에서 sar 는 1분 단위로 수집 되었습니다.

CPU 사용 정보 확인 (-u)

시스템 log 에 CPU Load High 메세지가 찍히는 것이 확인되어서, CPU Load 를 먼저 확인해 보았습니다. -u 옵션으로 CPU 사용 정보를 확인할 수 있습니다.

• 위 sar -u 의 결과에서 수치가 좀 높은 부분은 %iowait 입니다.
  • %iowait : I/O request 로 CPU 가 소비한 시간을 의미하는데, uniterruptable I/O 가 발생하는 경우 CPU 가 다른 task 에 의해 선점되지 못하게 됩니다.
  • 12:03:01 에 %iowait 이 CPU 시간을 많이 차지하고 있고, 이는 시스템에서 uniterruptable I/O 로 다른 task 를 처리할 수 없음을 의미합니다.

Block I/O 사용 정보 확인 (-b)

CPU 의 %iowait 이 높다면, 실제로 block I/O 가 많이 발생하였는지 확인해 보겠습니다. -b 옵션으로 block I/O 정보를 확인할 수 있습니다.

• 여기서는 시스템 load 가 높아진 원인으로 볼만한 수치는 보이지 않는 것 같습니다.
• 각 field에 의미는 생략하도록 하겠습니다.

Memory 사용 정보 확인 (-r)

Memory 부족이 swap 사용등으로 이어져 문제가 될 가능성이 있습니다. -r 옵션을 통해 Memory 사용량이 높았는지 확인해 보겠습니다.

• memory 부족이 있었는지는 %memused 도 확인하지만, kbcached 를 확인하기도 합니다.
  • kbcached : 디스크 등에서 메모리로 읽혀져 cached 영역을 차지하게된 크기입니다.
  • kbactive : 비교적 최근에 memory 에 올라와서, memory reclaim 시 kbinact 보다 늦게 회수됩니다.
  • kbinact : kbactive 에 비해서는 좀 더 오래 전에 memory 에 올라온 영역. 다른 프로세스의 memory reclaim 시 회수될 가능성이 높습니다.
• 12:04:01 와 12:05:01 시각의 정보를 보면, 상당한 메모리 양이 회수된 것을 알 수 있습니다. 다른 log 들을 살펴봤을 때, 이 때에 동작중인 application 중지등으로 인하여 메모리가 정리된 것으로 보입니다.
• 그 외에 Memory 부족이라고 판단할 만한 수치로는 보이지 않습니다.

프로세스 큐 정보 (-q)

위에서 본 CPU, Memory, Block I/O 정보등으로는 실제로 시스템 로드가 높았다고 판단하기 어려웠습니다.
-q 옵션으로 task 수에 대한 정보와 load average 를 확인해 보겠습니다.

• 여기서 확인해 볼 field는 아래와 같습니다.
  • runq-sz : Run queue 길이로, 실행되기를 기다리고 있는 task 수입니다.
  • plist-sz : task list 에 있는 task 수로 전체 task 수 입니다.
  • blocked : 현재 blocked 된 task 수로, I/O complete 를 기다리고 있는 task 들을 의미합니다.
• task 수는 시스템의 cpu 수에 따라서, load 가 높은지 여부를 판단한다. 현재 대상 시스템은 4 개의 CPU 가 할당되어 있는 VM 입니다.
• 12:03:01 시점에 1분 로드가 8.75 로 할당된 4개 CPU 대비 높은 CPU load 를 기록하고 있습니다. 또, 해당 시점에 blocked 된 task 수가 상당수 있는 것으로 보아, uninterruptable I/O 상태의 process 가 있었음이 확인됩니다. 이 정보는 cpu usage 정보에서의 %iowait 수치와 어느정도 일관성이 있음을 볼 수 있습니다.
• 12:03:01 과 12:04:01 사이에 task 가 많이 줄어들었습니다. 이는 다른 log 정보로 봤을 때, application 이 failover 되면서 줄어든 것으로 보입니다.

분석 결과

일시적인 CPU %iowait 과 task 에서의 blocked 수가 확인됩니다. sar 의 수집 interval 이 1분이고 표시되는 값들이 1분 동안의 평균 수치이다 보니, 실제로 이슈가 있는 짧은 순간 동안은 로드가 더 높았을 수도 있습니다. sar 데이터만으로는 확실한 문제 원인을 확인할 수 없지만, VM에 할당된 CPU 수를 좀 더 늘려서 문제가 완화되는지를 모니터링해 볼 수 있을 거 같습니다.

---

분석 사례 #4

Block I/O 로 인한 issue이 사례는 서비스 통신이 2시간 단위로 끊어지는 현상이 발생 (디스크 I/O) 하여 sar 를 통해 확인해 보고자 분석을 진행하였습니다. 참고로, 이 사례에서 sar 는 10분 단위로 수집되었습니다.

CPU 사용 정보 (-u)

-u 옵션으로 CPU 부하를 확인할 수 있습니다.

• 여기서 확인해 볼 필드는 %user,%iowait,%idle입니다.
  • %user : 사용자 수준(응용 프로그램)에서 실행하는 동안 발생한 CPU 사용률입니다. 이 필드에는 가상 프로세서를 실행하는 데 소요된 시간이 포함됩니다.
  • %iowait : 프로세스가 디스크 I/O 요청으로 대기 상태에 있었던 시간의 백분율입니다.
  • %idle : CPU가 유휴 상태이고 시스템에 미결 디스크 I/O 요청이 없는 시간의 백분율입니다.
• 08:10:01 AM 기점으로 %user 와 %iowait 가 상승하고, %idle 감소하는 것을 확인할 수 있습니다.
• cpu 의 iowait 가 높았던 것은 process 가 cpu 에서 내려 올 수 없는 상태로 짐작되고, I/O 가 완료되기를 기다려야 하는 상황이라고 추측할 수 있습니다.

프로세스 큐 정보 (-q)

 -q 옵션으로 큐(run queue) 길이와 Load Averages를 확인할 수 있습니다.

• 여기서 확인해볼 필드는 runq-sz와 blocked 입니다.
  • runq-sz : 런타임에 실행되기 위해 대기 중인 프로세스 수입니다.
  • blocked : I/O 요청이 완료되기를 기다리는 프로세스 수입니다.
• logical cpu 수를 기준으로, 그 수보다 ldavg 가 높으면, 부하가 높다고 볼 수 있으며, block I/O 가 발생하지 않는 task 들은 금방 처리되어 이 값이 높더라도 문제가 되지 않을 수 있으나, block I/O 가 높은 task 가 많은 경우는 CPU 응답이 느려질 수 있음. 그리고 runq-sz 등이 시간에 따라서 늘어나는 경우, CPU 가 밀린다고 볼 수도 있습니다.

Memory 사용 정보 (-r)

-r 옵션을 통해서, 메모리 정보를 확인해 보겠습니다.

• 위에서 주목할 필드는 %memused 입니다. 필드를 설명하면,
  • %memused : 현재 시스템의 전체 메모리 중에 사용중인 메모리의 비율을 표시합니다.
• %memused 는 99%의 사용률을 유지하고 있습니다.
• %memused 는 시스템이 일정시간 동작하면 높아질 수 밖에 없는 부분으로 신경쓰지 않아도 되며, kbcached 값은 file cache 등으로 올라와 있고, 회수 되어 프로그램에 할당이 될 수 있는 값입니다. 그리고 그 중 즉시 반환될 수 있는 부분을 kbinact로 생각하시면 됩니다.
  kbinact 가 여유가 있으면, 메모리가 부족하지는 않다고 추측할 수 있습니다.

Swap 사용 정보 (-S)

메모리 사용률이 높으므로, 혹시나 swap 영역을 사용하는지 확인해 보겠습니다.
-S 옵션을 통해서, swap 공간의 사용량을 확인해 보겠습니다.

• 여기서 볼만한 필드는 %swpused 입니다.
  • %swpused : 사용중인 swap 메모리 크기
• 사용된 swap 은 시스템에서 일부러 회수하지 않으므로, 기존에 swap 이 발생한 경우 이 값이 쌓여 있을 수 있습니다. 현재 swap 의 값이 중요하지 않으며, 시간이 지남에 따라서 값의 변동이 있는지 확인해야 됩니다. swap 양이 늘어난다고 하면, memory 부족으로 swapout (memory → swap영역) 이 발생하는 걸로 볼 수 있고, swap 양이 낮아지는 경우는 별로 없는데, 처음에 설명한 이유로 보통 메모리 여유가 생기더라도 줄어들지 않습니다.
• 메모리 사용률은 높지만 %swpused의 변동폭이 거의 없으므로 SWAP은 사용하지 않는다는 것을 확인할 수 있습니다.

Paging 사용 정보 (-B)

위에서의 -r 옵션을 통한 내용은 현재 메모리가 차지하고 있는 정도만을 표시하므로, 실제로 메모리에서의 I/O 가 얼마나 많이 발생하는지는 확인이 어렵습니다.
메모리에서의 paging In/Out 을 확인하기 위해, -B 옵션을 사용해서 확인해 보겠습니다.

• 여기서 다음 필드들이 의미가 있습니다.
  • pgpgin/s : 초당 시스템이 디스크에서 페이징한 총 킬로바이트 수입니다.
  • pgpgout/s : 초당 시스템이 디스크로 페이징 아웃한 총 킬로바이트 수입니다.
  • %vmeff : pgsteal / pgscan으로 계산되는 이것은 페이지 회수 효율성의 지표입니다.
• 08:10:01 AM 에 pgpgin/s 이 급격하게 증가하는 것을 확인할 수 있습니다.

Block device 사용 정보 (-d)

block I/O 는 해당 block device 의 spec (IOPS , read/write per sec) 등의 확인이 필요하기 때문에

-d 옵션을 통해 블록 장치에 대한 정보를 확인해 보겠습니다.

• 여기서 다음 필드들이 의미가 있습니다.
  • tps : 장치에 발행된 초당 전송 수를 나타냅니다. 여러 논리적 요청을 장치에 대한 단일 I/O 요청으로 결합할 수 있습니다.
  • rd_sec/s : 장치에서 읽은 섹터 수입니다.
  • wr_sec/s : 장치에 기록된 섹터 수입니다.
  • avgrq-sz : 장치에 발행된 요청의 평균 크기(섹터)입니다.
  • avgqu-sz : 장치에 발행된 요청의 평균 대기열 길이입니다.
  • await : 처리할 장치에 발행된 I/O 요청의 평균 시간(밀리초)입니다. 여기에는 대기열에 있는 요청에 소요된 시간과 이를 서비스하는 데 소요된 시간이 포함됩니다.
  • %util : 디바이스에 I/O 요청이 실행된 CPU 시간의 백분율입니다(디바이스의 대역폭 사용률). 이 값이 100%에 가까울 때 장치 포화가 발생합니다.
• 08:10:01 AM 시점에서 tps , rd_sec/s, wr_sec/s, avgrq-sz, avgqu-sz, await, %util 값들이 전부 상승한 것을 확인할 수 있습니다.
• avgqu-sz 는 block 에 대한 IO 큐에 쌓인 요청의 평균 대기열 길이로, 시간에 따라서 이 값이 늘어나면 block IO 가 밀린다고 볼 수 있습니다.
• %util 은 block I/O 에 의해, CPU 에서 소모한 시간을 의미하며, 값이 높으면 위에 -u옵션에서 본 것처럼 iowait가 높을 수 있다고 볼 수 있습니다.

분석 결과

sar -d 에서 보았듯이 특정 디바이스에 %util 이 거의 100% 에 가까워, I/O Saturation 발생으로 서비스에 영향을 주었을 가능성이 높습니다.서비스 문제의 명확한 원인이 무엇인지는, 이런 리소스 사용량을 유발시키는 process 에서 어떠한 동작을 했었는지를 추가로 확인이 필요합니다.

요약 및 정리

---

추가 고려 사항

문제의 원인 분석을 위해, 리소스 사용량을 직접적 또는 간접적으로 활용하는 것을 앞의 여러 케이스를 통해서 살펴 보았습니다.

sar 나 비슷한 용도의 도구들을 잘 활용하기 위해서 신경써야 할 부분들이 있습니다. 주로 다음 내용들을 고려해야 합니다.

• 시간동기화 – 분석할 대상 데이터의 시간정보가 정확해야 합니다. 시간동기화가 안 이루어져 시간이 틀어진다면 다를 정보들과 종합적으로 분석시 어려움이 발생할 수 있습니다.
• 워크로드 특징 이해 – sar 만으로는 분석에 제한이 있을 수 있습니다. 어떤 리소스를 어떻게 사용하는지를 운영자 대상으로 인터뷰하거나, 동작하는 애플리케이션이 어떤 제품인지 확인하여 워크로드를 짐작할 수 있습니다.
• 다른 로그들 – 시스템 로그나 감사로그, 애플리케이션의 로그들에 기록되는 에러들은 어떠한 리소스가 문제임을 알려주는 힌트가 되기도 합니다.
• Interval, sampling – sar의 경우 리소스 데이터 수집 간격이 10분입니다. 이 경우 이슈 발생 시점을 포함하는 10분간의 누적 데이터가 기록되므로, 리소스 사용이 스파이크성으로 짧은 시간 일시적으로 치솟았다가 떨어지는 경우라면 수치가 높지 않아 식별이 어려울 수도 있습니다. 그러므로 적당한 시간 간격으로 조정해야 합니다.

sar 로 확인할 수 있는 정보

위 본문에서 살펴봤듯이 sar 로 아래 정보들을 확인할 수 있습니다.

• CPU 사용량
• 메모리, 페이징, 스왑의 사용량
• Block device 사용량
• Network 사용량 통계
• 프로세스 통계

sar 로 볼 수 없는 정보

리눅스 서브시스템들의 전체적인 정보를 확인할 수 있었지만, 아래와 같은 특정 부분의 정보는 확인할 수 없었습니다.

• 프로세스별 리소스 사용 정보
• 커널 system call 및 유저프로세스의 function 들의 사용정보
• 메모리 맵 정보

추가적인 상세 분석을 위해서

sar 도구만으로는 문제의 원인 분석이 어려울 수 있으며, 이러한 경우 sar 데이터를 통해 추가로 분석해야 할 리소스 대상 범위를 좁히고 해당 리소스 분석에 특화된 도구를 사용해야 할 것입니다.

process 별 정보는 pidstat 명령으로, systemcall 등의 추적은 strace 같은 trace 도구로, network 는 netstat 이나 tcpdump/tshark 등이 있습니다.

매우 다양한 도구가 있으므로, 환경과 목적에 맞는 도구를 골라 사용할 필요가 있습니다.

마치며

이번 글에서는 sar 를 살펴보았습니다.
시스템 운영 및 분석이 필요한 분들에게 도움이 되는 글이 되었으면 합니다.

다음에는 좀 더 재미있으면서(?) 쉽고(?) 유익한 내용의 주제로 작성해 보겠습니다.
감사합니다.