리눅스, 자료실, 성경검색, 추억의게임, 고전게임, 오락실게임, rootman, http://www.rootman.co.kr
* 3.235.29.190 *
| Home | Profile | Linux | 자료실 | zabbix | Mysql 5.6 | 갤러리 | 성경검색 | 해피니스 | 자유게시판 | 게시물검색 | L | O | R |    

 
[Doc/Faq] [팁] 서버성능 관련하여 %iowait 제대로 알기
 작성자 : rootman
Date : 2008-04-29 15:40  |  Hit : 11,299  

출처 : http://kwonjonghyuk.cafe24.com/zboard/view.php?id=aix&no=17

그동안 %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

 
 

Total. 645
번호 분류 제목 작성자 등록일 조회수
600 기초강좌 터미널상에서 쉘 명령 라인에서의 단축키 사용 (1) rootman 05-18 11896
599 mysql [mysql] mysql load data/ out file 에 대한 기초자료(import/ex… 관리자 01-25 11877
598 Doc/Faq rrdtool을 한 번 이용해 볼까요? (1) rootman 08-25 11627
597 Shell [최종수정 : 2005/09/12] 서버 상태 값 주기적으로 메일로 발송… 루트맨 01-27 11503
596 Doc/Faq [팁] 서버성능 관련하여 %iowait 제대로 알기 rootman 04-29 11300
595 sqlite [sqlite] 반올림, 버림, 올림 함수 rootman 11-22 11170
594 mysql [mysql] mysqltunner를 통한 mysql optimize rootman 03-18 11126
593 기초강좌 [BMT] ab 를 통한 아파치 성능체크 (46) rootman 10-18 10907
592 sqlite [sqlite3] 날짜와 시간 함수 알아보기 rootman 12-14 10856
591 기초강좌 주요 핵심 튜닝 사항들 rootman 10-19 10746
590 Shell [nagios] HP MSA60 P800 스카시 컨트롤러 펌웨어 체크 plugin rootman 04-16 10715
589 Doc/Faq procmail을 통한 메일 필터링 (2) rootman 09-21 10688
588 Doc/Faq DDOS로 고생하시는분들에게.. rootman 09-20 10636
587 기초강좌 fuser를 이용하여 프로세스 컨트롤하기 (20) rootman 09-26 10596
586 기초강좌 partprobe를 통한 사용중인 파티션 재인식 시키기 rootman 08-31 10573
 1  2  3  4  5  6  7  8  9  10    
AND OR