sysstat

서버를 운영함에 있어 대부분 기본적으로 관제 솔루션이나 기타 프로그램에 의해 다양한 정보를

모니터링함은 기본일 것이다.

하지만 이러한 데이터의 신뢰도는 어느정도일가...

이런 의문점은 항시 의문이 든다.

이번엔 자원의 사용에 대해 리눅스에서 완벽호환되어 제공되는 sysstat을 이용하여 테스트해보았다.



***환경시스템***

OS : CentOS5.1

CPU : Intel(R) Xeon(TM) CPU 3.20GHz

MEM : 1G

OS Disk : 80G

DATA : SATA2 500G * 6 ( Raid 5 )



시스템에서 자원의 사용률에 대한 Sysstat 자원 감시 도구 모음이며,
Sysstat의 입출력 통계와 CPU 통계 자료를 수집 도구는 다음과 같다.

iostat : 한개 이상의 디스크 드라이브에 대한 입출력 통계와 함께 전체 CPU 활용량을 보여준다.
mpstat : 보다 상세한 CPU 활용량 정보를 보여준다.
sadc : sadc는 system activity data collector의 줄임말로서 시스템 자원 활용 정보를 모은 후 파일에 기록한다.
sar: sadc가 생성한 파일에서 리포트를 작성한다(sar 리포트는 상호대화식으로 생성하거나 보다 철저한 분석을 위하여 파일에 기록 가능)

추가적으로 vmstat도 흔히 사용된다.

별도의 자원사용에 대해 별다른 모니터링을 하지 않는고 있다면 sysstat의 sar/sadc를 이용하여

자원사용에 대해 충분한 기능을 할 것이다.



<참고자료>

http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-isa-ko-4/s1-resource-rhlspec.html





주요 옵션과 기능을 본다면 아래와 같다.



*** sar -b : I/O 와 transfer 의 통계를 백분율로 출력

tps : 물리적 디스크에서 발생되어진 초당 전송량
여기서 전송은 물리적 디스크에 요청한 I/O 이다
rtps : 물리적 디스크로부터 발생된 초당 읽기 총 요청 횟수
wtps : 물리적 디스크로부터 발생된 초당 쓰기 총 요청 횟수
bread/s : 드라이브 안의 블럭에서 초당 읽은 데이타의 총합
블럭은 부정확한 사이즈의 블럭이다
bwrth/s : 드라이브 안의 블럭에서 초당 쓰여진 데이타의 총합

*** sar -B : 페이징 통계를 출력
pgpgin/s : 일초당 몇개의 블록이 디스크에서 페이지되어 들어왔나!
pgpgout/s : 디스크로 페이지되어 나갔나!

*** sar -c : 새롭게 만들어져 활동하고있는 프로세스를 출력

*** sar -e hh:mm:dd : 리포트의 종료시간을 설정
기본 ending time 은 18:00:00 이다
시간표시형식은 24시간 format 을 사용한다
이 옵션은 -f 또는 -o 옵션과 함께 사용되어져야한다.
예제] [root@soma]# sar -e 09:00:00 -f
=> /var/log/sa/sa## 파일에서 09:00:00 까지의 기록들만 출력

*** sar -n DEV | EDEV | SOCK | FULL : 네트워크통계를 출력
DEV : Network Device의 결과로 부터의 통계
IFACE : Network Interface 이름
rxpck/s : 초당 받은 패킷수
txpck/s : 초당 전송한 패킷수
rxbyt/s : 초당 받은 bytes
txbyt/s : 초당 전송한 bytes
rxcmp/s : 압축된 패킷을 초당 받은 수
txcmp/s : 압축된 패킷을 초당 전송한 수
rxmcst/s : 초당 받은 다중 패킷 수

EDEV : Network Device 의 에러 통계
IFACE : Network Interface 이름
rxerr/s : 초당 불량 패킷을 받은 수
txerr/s : 패킷전송중 초당 발생한 에러 수
coll/s : 패킷전송중 초당 발생한 충돌 수
rxdrop/s : 리눅스 buffer 의 부족으로 패킷을 받는도중 초당 drop 된 패킷 수
txdrop/s : 리눅스 buffer 의 부족으로 전송중 초당 drop 된 패킷 수
txcarr/s : 패킷전송도중 초당 발생한 carrier-error 수
rxfram/s : 패킷을 받는도중 초당 발생한 frame alignment 에러 수
rxfifo/s : 패킷을 받는 도중 초당 발생한 FIFO overrun 에러 수
txfifo/s : 전송된 패킷중 초당 발생한 FIFO overrun 에러 수

SOCK : Socket 의 통계
totsck : 총 사용된 socket 수
tcpsck : 현재 사용중인 TCP sockets 수
udpsck : 현재 사용중이 UDP sockets 수
rawsck : 현재 사용중인 RAW sockets 수
ip-frag : 현재 사용중인 IP fragments 수

FULL : 모든 종류의 Keywords(DEV,EDEV,SOCK) 내용을 출력

*** sar -o filename : 파일을 읽어서 binary 형태로 저장
예제] [root@test]# sar -o soma -i 1 5

*** sar -r : 메모리 & 스왑 공간의 이용 통계를 출력
kbmemfree : 사용가능한 총 메모리의 양(kbytes)
kbmemused : 사용중인 총 메모리의 양(kbytes), 커널에서 사용중인 메모리는 제외
%memused : 사용된 메모리의 %
kbmemshrd : 시스템에서 공유메모리로 사용된 총 메모리의 양 (kbytes)
kbbuffers : 커널에서 buffer 메모리로 총 사용된 메모리의 양 (kbytes)
kbcached : 커널에서 cache data 로 사용된 총 메모리의 양(kbytes)
kbswpfree : 사용가능한 스왑공간의 양 (kbytes)
kbswpused : 사용된 스왑공간의 양 (kbytes)
%swpused : 사용된 스왑공간의 %

*** sar -R : 메모리 통계
frmpg/s : 시스템에서 초당 자유로워진 memory pages 의 양
페이지의 크기는 시스템 아키텍쳐에따라 달라지며 보통 4K / 8K
정수값으로 표시된 값은 이 유형의 페이지가 이 비율로 증가하고 있다는 의미이며,
음수값으로 나타난 값은 이 유형의 페이지가 이러한 비율로 감소하고 있다는 것을 의미
값이 0이라며 이 유형의 페이지가 증가하지도 감소하지도 않고 있다는 것을 보여준다
shmpg/s : 시스템에서 초당 더해진 memory pages 의 양(공유 메모리 페이지)
bufpg/s : 시스템에서 초당 buffer 에 추가적으로 더해진 memory pages 의 양

*** sar -s hh:mm:ss : 명령어를 실행시킬 시작시간을 설정
이 옵션은 파일로부터 데이터를 읽을때만 사용 가능 (옵션 -f)
예제] [root@soma]# sar -s 17:01:00 soma
설명] soma 라는 파일에 저장된 데이타중에 시간이 17:01:00 이상인것들만 출력
여기서 soma 라는 파일은 -f 옵션을 사용해서 만든 파일

*** sar -u : CPU 사용 통계
%user : 사용자 레벨(application level) 에서 실행중일때의 CPU 사용률 (%)
%nice : 사용자 레벨(appliactionlevel) 에서 nice 가중치를 준 CPU 사용률(%)
%system : 시스템레벨(kernel) 에서 실행중일때의 CPU 사용률(%)
%idle : CPU가 쉬고있는 시간의 %

*** sar -v : 커널테이블 & 파일 에서 inode 의 상태를 출력한다.
dentunusd : Directory cache 에서 사용되고있지 않은 cache entries
file-sz : file handles 의 사용양
%file-sz : 리눅스 커널에서 할당가능한 최대 파일핸들의 수에 대한 파일핸들의 사용된 퍼센트(%)
inode-sz : inode handles 의 사용양
super-sz : 커널에의해 할당된 super block handles 의 수
%super-sz : 리눅스가 할당 가능한 최대 슈퍼블럭핸들에대한 실제로 할당되어진 슈퍼블럭핸들의 퍼센트(%)
dquot-sz : Disk quota entryes 의 수
%dquot-sz : 최대할당가능한 disk quota entries 에 대한 실지로 할당된 entries의 퍼센트(%)

*** sar -w : 시스템의 switching 활동 현황 출력
cswch/s : 초당 context switching 의 수

*** sar -W : swapping 의 통계 출력
pswpin/s : 초당 swap in 된 수
pswout/s : 초당 swap out 된 수

*** 기타
inadtypg : 비활성화 페이지 중 얼마나 많은 페이지가 수정된 dirty 상태로서 디스크에 기록되어야하는지를 보여준다
inaclnpg : 비활성화 페이지 중 몇 페이지가 아직 수정되지 않은 clean 상태인지 보여준다
clean 상태의 페이지는 디스크에 기록할 필요가 없다.
inatarpg : 시스템이 원하는 비활성화 상태 페이지의 희망 용량을 나타낸다



위와같은 다양한 옵션과 기능이 존재하며, 원하는 정보를 확인할 수 있다
해당 기능은 linux에서 100% 지원 및 호환이 가능하며, 부하율도 0%에 가깝다.
또한 CPU, MEM, swap, network 등 다양한 정보를 갖추고 있어서 활용도가 높다고 볼 수 있다.

끝으로 실제 활용을 해본다면 아래와 같이 직접 명령어로 확인 할 수 있으며,



예제) sar -r -f sa99 1800 -s 08:00:00 -e 19:00:00
오전 8시부터 저녁 19시가지 30분간격으로 메모리 모니터링(sa99=sar대상파일)



또는 아래와 같이 스크립트를 통하여 원하는 시간과 값만을 가져올 수도 있다.

예제)

sar -r -f sa28 | awk 'NF > 0' | grep -vi linux | grep -v memfree | grep -vi average | awk '{printf "%s %s => used : %d / buffer : %d / cached : %d / used-buffer-cache : %d MB\n", $1,$2,$4, $7, $8, $4-$7-$8}'



그럼 이만..



"우연함을 영원의 이름으로..."

I'll be back -_-b





PS : 오래전이라 어느 블로그인지는 까묵었다!!!

어느 블로그에서 발췌한 iowait에 대한 부분이 도움될거 같아 올립니다.

서버성능 관련하여 %iowait 제대로 알기 Linux/Unix

그동안 %iowait 가 높은 경우는 일반적으로 I/O 성능상 문제가 있는 것으로 여겨져 왔다.
그러나 CPU 성능의 대폭적인 향상으로 %iowait 가 높은 경우 그 의미 해석에 오해를 불러 일으키게 되었는 데 특히 Random I/O 가 많은 업무환경에서 그렇다.
왜냐하면 %iowait 는 사실 I/O 성능이 아닌 CPU성능 측정에서 언급되는 것이기 때문이다.
정확히 말하면 %iowait 는 CPU 가 idle 이지만 I/O 가 끝나기를 기다리는 시간을 %로 나타내는 것이다.
이같이 I/O 성능과는 간접적인 연관성만을 갖게되지만 많은 경우 잘못된 결론을 끌어내는 데 사용된다.
거의 100 % iowait 이지만 정상적인 시스템으로 볼 수 있는 경우와 0 % iowait 이지만 디스크 병목현상을 보이는 시스템일 수가 있다.

프로세서 속도가 증가함에 따라 %iowait 가 대체로 높게 나타나는 경향이 있다.
프로세서 성능향상이 디스크 성능향상을 크게 앞지르고 있다.
프로세서 성능이 평균적으로 12~18 개월 마다 두 배가 되고 있지만 디스크 성능(IOPS/disk)은 상대적으로 큰 변화가 없는 편이다.
이러한 불균형으로 정상적인 시스템의 경우에도 %iowait 가 높게 나타나는 경향이 있다.

* IOPS 는 디스크의 탐색시간(seek time)에 의존하며 프로세서 성능 만큼 향상되고 있지는 않다.
* 스토리지에서의 발전은 주로 공간밀도(areal density, MB/sq. in.) 나 회전속도(rotational speed) 쪽에 있어왔다.

다음 예제는 보다 빠른 CPU 를 사용하게 되면 %iowait 가 증가할 수 있다는 것을 보여준다.
4 배 빠른 CPU 로 업그레이드하는 시스템을 가정한다. 나머지는 변화가 없는 경우이다.
업그레이드 전에 트랜잭션 수행에 60 ms 가 걸렸다.(CPU time 이 40 ms 이고 IO 는 20 ms 임) 어플리케이션이 트랜잭션을 하나씩 순차적으로 수행하는 경우를 가정한다.

CPU Upgrade 이전
CPU time = 40 ms
IO time = 20 ms
Total transaction time = CPU + IO = 40 + 20 = 60 ms
%iowait = IO time/total time = 20/60 = 33%

CPU Upgrade 이후
CPU time = 40 ms/ 4 = 10 ms
IO time = 20 ms
Total transaction time = CPU + IO = 10 + 20 = 30 ms
%iowait = 20/30 = 66%

이 예의 경우를 보면 %iowait 가 두 배로 증가 되었음에도 불구하고 트랜잭션 성능이 두 배가 되었다.
이 경우 %iowait 절대값은 I/O 문제를 호도하고 있는 것이다.

%iowait 를 신뢰할 수 없다면 도대체 어떻게 I/O 문제를 찾아 낼 수 있을까?

최선의 방법은 filemon 등을 사용하여 I/O 응답시간을 측정하는 것이다.
통상적으로 캐시가 없는 디스크 서브시스템은 읽기/쓰기 시간이 평균 15-20 ms 이다.
캐시가 있는 디스크 서브시스템은 읽기가 평균 5-20 ms 이며 쓰기는 평균 2-3 ms 이다.
응답시간이 늦는 경우라면 스토리지 서브시스템의 과부하일 가능성이 크다.

결론적으로 말하면 I/O 병목현상 진단을 위해서 %iowait 에 의존해서는 안된다.
%iowait 가 높더라도 시스템이 정상적으로 운영되고 있을 수 있다.

IO 서비스 타임이 높다는 것은 디스크 서브시스템의 디스크가 과부하(즉, 디스크가 처리할 수 있는 용량이상의 IO 를 요청(IOPS))인 경우가 대부분으로
디스크 서브시스템 자체 프로세서가 과부하이거나 서버에서 디스크까지의 연결과정(SAN 스위치 등)에 병목이나 문제가 있는 경우이다.
이러한 IO 문제를 해결하기 위해서는 다음과 같이 시도해 볼 수 있다.

- AIX 튜닝 : 비동기 입출력(asynch I/O) 기능 사용, 보다 큰 크기의 블록으로 읽기(vmtune -maxpgahead) 등
- 디스크 서브시스템에 대한 I/O 개수를 줄인다. 데이타 캐시를 위한 메모리를 더 크게 잡거나 RAM 파일시스템을 사용한다.
- 보다 많은 물리적 디스크에 데이타를 분산시킨다.
- migratepv 명령어로 LV 를 과부하를 겪고 있는 디스크에서 한가한 디스크로 옮긴다.
- 어플리케이션이나 데이타베이스를 튜닝하여 I/O를 줄인다.
- 우선순위가 낮은 업무의 수행을 피크타임을 피해 한가한 시간대로 옮긴다.

위와 같은 노력을 통해서도 I/O 성능이 개선되지 않는다면 서버는 제외하고 디스크 서브시스템 쪽 튜닝에 보다 집중해야 한다.
사실 I/O 관련해서 서버는 데이타 읽기/쓰기를 요청하고 기다리는 것 이외에는 특별히 하는 일이 없다.
응답이 늦으니 기다리다 보면 자연스레 %iowait 가 올라갈 수 밖에.......

결론적으로 디스크를 더욱 빠르게 만드는 것은 어렵다.
하지만 CPU 속도를 두 배 빠르게 하면 두 배 빨리 기다리게 된다.

보다 자세한 내용은 아래 문서를 참고하시기 바랍니다.
-> http://www.aixservice.co.kr/documents/IOwait-FAQ.pdf