운영하고 있는 MySQL 서버중에 트래픽 통계를 집계해서 보여주는 DB가 있는데, 매시간 배치작업이나 데이터 양으로 속도개선이 필요하다.
다음주에 Mysql 버전을 5.1.25로 올리면서 partitiong과 replication을 구현해서 올릴 예정이다.
대체 예정 서버에서 배치프로그램과 쿼리들을 실행시키면서 테스트를 하고 있다.
그런데, sar 명령등에서 %iowait이 배치작업 도중 25% 정도까지 올라가는 현상이 있었다.
기존 운영서버에서는 거의 0%인데, 대체서버에서 왜 올라가는 것일까? 혹시 추가로 꽂은 디스크쪽에 io가 문제가 있는게 아닐까 하는 생각이 들었다.
그러나, %iowait에 대해 좀더 확인해 보니, %iowait 의 의미는 CPU 가 idle 이지만 I/O 가 끝나기를 기다리는 시간을 %로 나타내는 것이었다. 즉, io가 분주히 움직이는데 cpu가 idle인 정도를 나타내는 것인데..
배치작업은 기존 운영서버 수행속도보다 5배정도 빨리 끝나는 것으로 봐서, io에 문제가 있기보단 cpu가 특별히 할 일이 없어 놀고 있는거 같다;
그래서, io에 문제가 있기보단 cpu나 os의 성능향상으로 인해 올라가는 것으로 결론내렸다.
참고로, 기존장비와 변경예정 장비의 주요 스펙(기존보다는 변경장비가 빠방하다;)
기존 장비
CPU : Intel(R) Xeon(TM) CPU 3.20GHz 4개
OS : Red Hat Linux Advanced Server release 2.1AS
메모리 : 2G
변경 예정 장비
CPU : Intel(R) Xeon(R) CPU 5130 @ 2.00GHz CPU 4개
OS : Red Hat Enterprise Linux AS release 4
메모리 : 4G
%iowait에 대해 참고한 내용 : http://kwonjonghyuk.cafe24.com/zboard/view.php?id=aix&no=17
해당 문서가 혹시 링크가 끈어질 것을 대비해 내용을 퍼온다...
----------------------[팁] 서버성능 관련하여 %iowait 제대로 알기---------------------------
그동안 %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 속도를 두 배 빠르게 하면 두 배 빨리 기다리게 된다.
보다 자세한 내용은 아래 문서를 참고하시기 바랍니다.