오픈소스컨설팅 Linux 팀에서 리눅스를 기반으로 한 솔루션 아키텍트로 활동하고 있습니다.
안녕하세요. 저희는 오픈소스컨설팅 리눅스팀 입니다. 저희는 리눅스 및 관련 솔루션에 대해 기술지원을 하고 있습니다.
이번 글에서는 서버 모니터링을 위한 여러 툴 중에서도 기본적으로 많이 사용하시는 sar에 대해 다뤄보려고 합니다.
리눅스 서버를 운영하다보면 리소스 사용량을 확인해야 할 경우가 있는데요.
이러한 경우 대부분의 리눅스 배포판에 설치되는 sar 를 활용하면 서버에서 사용되는 자원의 사용량을 정확하게 파악 할 수 있습니다.
sar 외에도 많은 유용한 도구들이 있지만, sar 는 이미 설치되어 있거나 기본 리포지토리에서 가져올 수 있어서 분석을 빠르게 시작할 수 있다는 장점이 있습니다.
sar 는 system activity report 명령 도구입니다. 현재 사용량 뿐 아니라, 시스템에 예약작업으로 등록되어 있어서 리소스 사용량을 일정 주기마다 기록/저장하여 이전의 상태와 변화 추이를 확인할 수 있다는 장점이 있습니다.
일반적으로는 OS 설치하면서 같이 설치되는 경우가 많지만, minimal 수준으로 설치하실 경우 설치가 되어 있지 않을 수 있습니다.
그런 경우에는 당황하지 마시고 sysstat 이라는 패키만 설치해 주시면 바로 사용이 가능하니 이점 꼭 기억하시기 바랍니다.
sar를 사용할 때 여러 option을 주어서 다양한 정보를 확인 할 수 있는데요.
실제 이슈 케이스에 따라 어떤 field를 확인하고 분석할 수 있는지 알아보도록 하겠습니다.
Memory 100% , Reboot
이 사례는 시스템이 메모리를 100% 사용 한 후 reboot 된 상황이고,
sar 데이타를 통해 부하의 원인 분석을 진행 하였습니다.
sar 데이타는 11:25:04 AM을 마지막으로 더 이상 찍히지 않았고, 이후 시스템은 리부팅 되었습니다.
참고로, 이 사례에서 sar 는 1분 단위로 수집 되었습니다.
이 시스템의 OS는 RHEL7 입니다.
우선 sar 의 메모리 정보를 확인해 보겠습니다.
메모리 정보를 확인하는 여러 옵션 중에서 일단 -r 옵션을 통해서, 확인해 보겠습니다.
kbactive 와 %memused 입니다. 필드를 설명하면,
kbactive : 프로세스에 의해서, 비교적 최근에 메모리로 로드된 메모리 공간의 크기를 의미하며, kilobyte 단위의 표시입니다. 최근에 로드된 메모리는 프로세스에서 사용하는 부분일 수 있으므로, 다른 프로세스의 메모리 요청시에도 되도록이면 이 영역에서는 잘 회수되지 않습니다.%memused : 현재 시스템의 전체 메모리 중에 사용중인 메모리의 비율을 표시합니다.추가적인 메모리 분석을 위해, -B 옵션을 통해서 page 사용 정보를 확인해 보겠습니다.
pgpgin/s : 초당 시스템이 디스크에서 페이징한 총 킬로바이트 수입니다.pgpgout/s : 초당 시스템이 디스크로 페이징 아웃한 총 킬로바이트 수입니다.pgfree/s : 초당 시스템에서 사용 가능한 목록에 배치한 페이지 수입니다.pgscank/s : kswapd 데몬이 초당 스캔한 페이지 수입니다.pgscand/s : 초당 직접 스캔한 페이지 수입니다pgsteal/s : 메모리 요구를 충족하기 위해 시스템이 초당 캐시(페이지 캐시 및 스왑 캐시)에서 재확보한 페이지 수입니다.%vmeff : pgsteal / pgscan으로 계산되는 이것은 페이지 회수 효율성의 지표입니다.pgpgin/s 와 pgpgout/s 가 크게 증가한 것을 보아 디스크를 읽고 쓰는 작업이 다량 발생한 것을 알 수 있습니다. 위의 sar -r 에서 같은 시점에 kbactive 값처럼 메모리가 급증하고 page in/out 으로 메모리와 디스크간의 I/O 가 많이 일어난 것으로 보입니다.%vmeff 는 24.03%을 기록하였습니다. %vmeff 는 pgsteal (페이지 재사용) / pgscan (페이지 스캔) 의 비율이며, 페이지 재사용 효율을 백분율로 보여줍니다.%vmeff 를 통해서 프로세스의 메모리 요청으로 필요한 만큼 메모리를 회수했는지를 알 수 있습니다. 모든 페이지를 회수하는 상태는 100%이며, 페이지 스캔이 없는 경우에는 0% 으로 표시됩니다. 이 값은 0% 이거나 100% 에 가까워야 정상입니다. 만약 100%보다 낮은 수치가 있을 경우에는 메모리 할당 요청을 하였으나, 원하는 시간 내에 처리 되지 않았을 가능성이 있습니다.메모리가 부족한 상황에서의, 디스크 I/O 라면 swap In/Out 이 발생했을 수도 있습니다.-S 옵션을 통해서, swap 공간의 사용량을 확인해 보겠습니다.
%swpused 입니다.
%swpused : 사용중인 swap 메모리 크기이제 CPU 부하와 run queue를 확인해보겠습니다.
-u 옵션으로 CPU 부하를 확인할 수 있습니다.
%iowait 입니다.%iowait : 프로세스가 디스크 I/O 요청으로 대기 상태에 있었던 시간의 백분율sar -B에서도 디스크 I/O가 많이 발생했다는 것을 확인하였지만 sar -u 로도 프로세스의 I/O 요청이 많았다는 것을 확인할 수 있습니다. -q 옵션으로 큐(run queue) 길이와 Load Averages를 확인할 수 있습니다.
runq-sz와 blocked 입니다.
runq-sz : 런타임에 실행되기 위해 대기 중인 프로세스 수blocked : I/O 요청이 완료되기를 기다리는 프로세스 수| sar 의 -r , -B 옵션을 통해서 memory usage 와 process 의 memory 요청이 급증한 것을 확인하였습니다.그리고, sar -S 로 memory 가 부족으로 인한 swap used 증가를 확인했습니다.그 이후에는 sar 정보나 kernel dump 등이 발생하지는 못하였지만, 계속적인 memory 부족이 process 수행이나 block I/O 동작등의 지연을 유발하고 그로 인해 전체적인 시스템 동작 문제로 kernel 이 시스템을 reboot 했을 것으로 추정할 수 있을 것 같습니다. |
Memory Usage 증가와 같은 사례는 시스템 메모리가 증가된 원인 확인이 필요했고, sar 를 통해 메모리 변화 등을 통해 어떠한 특이사항이 있는지 확인해 보고자 분석을 진행하였습니다. 참고로, 이 사례에서 sar 는 1분 단위로 수집되었습니다. 이 시스템의 OS는 RHEL6 입니다.
메모리 정보를 확인하는 -r 옵션을 통해서, 확인해 보겠습니다.
%memused 입니다. 필드를 설명하면,
%memused : 현재 시스템의 전체 메모리 중에 사용중인 메모리의 비율을 표시합니다.%memused 는 98%~99%의 사용률을 유지하고 있습니다.kbcached와 kbbuffers 의 값은 합쳐서, 2~3GB 정도를 차지하고 있습니다.kbcached와 kbbuffers를 제외하고도, 30GB 정도로 90% 이상의 메모리를 사용하므로 메모리 사용량이 높다고 볼 있습니다.메모리 사용률이 높으므로, 혹시나 swap 영역을 사용하는지 확인해 보겠습니다.-S 옵션을 통해서, swap 공간의 사용량을 확인해 보겠습니다.
%swpused 입니다.
%swpused : 사용중인 swap 메모리 크기%swpused의 변화가 크지 않습니다.위에서의 -r 옵션을 통한 내용은 현재 메모리가 차지하고 있는 정도만을 표시하므로, 실제로 메모리에서의 I/O 가 얼마나 많이 발생하는지는 확인이 어렵습니다.
메모리에서의 paging In/Out 을 확인하기 위해, -B 옵션을 사용해서 확인해 보겠습니다.
pgpgin/s : 초당 시스템이 디스크에서 페이징한 총 킬로바이트 수입니다.pgpgout/s : 초당 시스템이 디스크로 페이징 아웃한 총 킬로바이트 수입니다.%vmeff : pgsteal / pgscan으로 계산되는 이것은 페이지 회수 효율성의 지표입니다.pgpgin/s 이 급격하게 증가한 후에 감소하는 것을 확인할 수 있습니다.pgpgin/s 이 증가한 후에 감소하는 것을 확인할 수 있습니다. 따라서 2시마다 cron 에 의해 어떠한 테스크(Task)가 동작한다고 추측해 볼 수 있습니다.%vmeff 값이 100% 또는 0%에 가까운 수치를 기록합니다. 모든 페이지를 회수하는 상태는 100% 이고, 페이지 스캔이 없는 경우에는 0% 으로 표시되므로 메모리 할당 요청을 하였을 때 원하는 시간 내에 처리되었다고 볼 수 있습니다.직전 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 가 발생 하였고 그로 인해서, 메모리 사용률도 어느 정도 높아진 것으로 확인이 되었습니다. |
CPU Load High이 사례는 일시적인 load High 로 인해, HA 솔루션에서 리소스가 Failover 된 것으로, sar 를 통해 리소스 사용량 변화 등을 확인하기 위해서 분석을 진행하였습니다. 참고로, 이 사례에서 sar 는 1분 단위로 수집 되었습니다.
시스템 log 에 CPU Load High 메세지가 찍히는 것이 확인되어서, CPU Load 를 먼저 확인해 보았습니다. -u 옵션으로 CPU 사용 정보를 확인할 수 있습니다.
%iowait 입니다.
%iowait : I/O request 로 CPU 가 소비한 시간을 의미하는데, uniterruptable I/O 가 발생하는 경우 CPU 가 다른 task 에 의해 선점되지 못하게 됩니다.CPU 의 %iowait 이 높다면, 실제로 block I/O 가 많이 발생하였는지 확인해 보겠습니다. -b 옵션으로 block I/O 정보를 확인할 수 있습니다.
Memory 부족이 swap 사용등으로 이어져 문제가 될 가능성이 있습니다. -r 옵션을 통해 Memory 사용량이 높았는지 확인해 보겠습니다.
%memused 도 확인하지만, kbcached 를 확인하기도 합니다.
kbcached : 디스크 등에서 메모리로 읽혀져 cached 영역을 차지하게된 크기입니다.kbactive : 비교적 최근에 memory 에 올라와서, memory reclaim 시 kbinact 보다 늦게 회수됩니다.kbinact : kbactive 에 비해서는 좀 더 오래 전에 memory 에 올라온 영역. 다른 프로세스의 memory reclaim 시 회수될 가능성이 높습니다.위에서 본 CPU, Memory, Block I/O 정보등으로는 실제로 시스템 로드가 높았다고 판단하기 어려웠습니다.-q 옵션으로 task 수에 대한 정보와 load average 를 확인해 보겠습니다.
runq-sz : Run queue 길이로, 실행되기를 기다리고 있는 task 수입니다.plist-sz : task list 에 있는 task 수로 전체 task 수 입니다.blocked : 현재 blocked 된 task 수로, I/O complete 를 기다리고 있는 task 들을 의미합니다.%iowait 수치와 어느정도 일관성이 있음을 볼 수 있습니다.일시적인 CPU %iowait 과 task 에서의 blocked 수가 확인됩니다. sar 의 수집 interval 이 1분이고 표시되는 값들이 1분 동안의 평균 수치이다 보니, 실제로 이슈가 있는 짧은 순간 동안은 로드가 더 높았을 수도 있습니다. sar 데이터만으로는 확실한 문제 원인을 확인할 수 없지만, VM에 할당된 CPU 수를 좀 더 늘려서 문제가 완화되는지를 모니터링해 볼 수 있을 거 같습니다. |
Block I/O 로 인한 issue이 사례는 서비스 통신이 2시간 단위로 끊어지는 현상이 발생 (디스크 I/O) 하여 sar 를 통해 확인해 보고자 분석을 진행하였습니다. 참고로, 이 사례에서 sar 는 10분 단위로 수집되었습니다.
-u 옵션으로 CPU 부하를 확인할 수 있습니다.
%user,%iowait,%idle입니다.
%user : 사용자 수준(응용 프로그램)에서 실행하는 동안 발생한 CPU 사용률입니다. 이 필드에는 가상 프로세서를 실행하는 데 소요된 시간이 포함됩니다.%iowait : 프로세스가 디스크 I/O 요청으로 대기 상태에 있었던 시간의 백분율입니다.%idle : CPU가 유휴 상태이고 시스템에 미결 디스크 I/O 요청이 없는 시간의 백분율입니다.%user 와 %iowait 가 상승하고, %idle 감소하는 것을 확인할 수 있습니다. -q 옵션으로 큐(run queue) 길이와 Load Averages를 확인할 수 있습니다.
runq-sz와 blocked 입니다.
runq-sz : 런타임에 실행되기 위해 대기 중인 프로세스 수입니다.blocked : I/O 요청이 완료되기를 기다리는 프로세스 수입니다.-r 옵션을 통해서, 메모리 정보를 확인해 보겠습니다.
%memused 입니다. 필드를 설명하면,
%memused : 현재 시스템의 전체 메모리 중에 사용중인 메모리의 비율을 표시합니다.%memused 는 99%의 사용률을 유지하고 있습니다.%memused 는 시스템이 일정시간 동작하면 높아질 수 밖에 없는 부분으로 신경쓰지 않아도 되며, kbcached 값은 file cache 등으로 올라와 있고, 회수 되어 프로그램에 할당이 될 수 있는 값입니다. 그리고 그 중 즉시 반환될 수 있는 부분을 kbinact로 생각하시면 됩니다.kbinact 가 여유가 있으면, 메모리가 부족하지는 않다고 추측할 수 있습니다.메모리 사용률이 높으므로, 혹시나 swap 영역을 사용하는지 확인해 보겠습니다.-S 옵션을 통해서, swap 공간의 사용량을 확인해 보겠습니다.
%swpused 입니다.
%swpused : 사용중인 swap 메모리 크기%swpused의 변동폭이 거의 없으므로 SWAP은 사용하지 않는다는 것을 확인할 수 있습니다.위에서의 -r 옵션을 통한 내용은 현재 메모리가 차지하고 있는 정도만을 표시하므로, 실제로 메모리에서의 I/O 가 얼마나 많이 발생하는지는 확인이 어렵습니다.
메모리에서의 paging In/Out 을 확인하기 위해, -B 옵션을 사용해서 확인해 보겠습니다.
pgpgin/s : 초당 시스템이 디스크에서 페이징한 총 킬로바이트 수입니다.pgpgout/s : 초당 시스템이 디스크로 페이징 아웃한 총 킬로바이트 수입니다.%vmeff : pgsteal / pgscan으로 계산되는 이것은 페이지 회수 효율성의 지표입니다.pgpgin/s 이 급격하게 증가하는 것을 확인할 수 있습니다.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%에 가까울 때 장치 포화가 발생합니다.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 도구만으로는 문제의 원인 분석이 어려울 수 있으며, 이러한 경우 sar 데이터를 통해 추가로 분석해야 할 리소스 대상 범위를 좁히고 해당 리소스 분석에 특화된 도구를 사용해야 할 것입니다.
process 별 정보는 pidstat 명령으로, systemcall 등의 추적은 strace 같은 trace 도구로, network 는 netstat 이나 tcpdump/tshark 등이 있습니다.
매우 다양한 도구가 있으므로, 환경과 목적에 맞는 도구를 골라 사용할 필요가 있습니다.
이번 글에서는 sar 를 살펴보았습니다.
시스템 운영 및 분석이 필요한 분들에게 도움이 되는 글이 되었으면 합니다.
다음에는 좀 더 재미있으면서(?) 쉽고(?) 유익한 내용의 주제로 작성해 보겠습니다.
감사합니다.
오픈소스컨설팅 Linux 팀에서 리눅스를 기반으로 한 솔루션 아키텍트로 활동하고 있습니다.
