IOSTAT 관련 정보

iostat

Note: 다음 내용은 AIX V4.1 이상에서는 검증되지 않은 내용입니다.

다음에 설명되는 내용은 베리 사드(Barry Saad)씨가  /AIXtra(1)  1994 년 1/2월호에 기고한  “Performance Tuning: A Continuing Series — The iostat Tool”의  내용에 기초한 것이다.

소개

여기서는 ”iostat” 를 이용하여 I/O 부시스템과  CPU 의 병목을 어떻게 찾아내는가에 대한 내용을  설명할 것이다. ”iostat” 는 커널의 주소공간을  표본추출하고, 매 시각 틱(2) 마다  새롭게 되는 여러 카운터들(3) 로부터  자료를 뽑아 작업을 한다. 이의 결과들-tty, CPU와  입출력 부시스템의 활동들을 망라함-은 매초단위로  보고되거나, 혹은 지정된 경과기간만큼의 단위로 보고된다.

명령어의 형식

보통은, 기간(4) 과  보고내용이 출력되는 회수를 지정하여 ”iostat” 명령을  사용한다. 이 명령의 형식은 다음과 같다:

“iostat” 명령을 사용할 경우, ”-d” 플래그를 같이  표시하면, 이는 모든 물리적 볼륨들에 대한 디스크의  통계에 관한 자료만 출력한다. ”-t” 플래그는  시스템의 tty 와 CPU에 관련한 통계만을 보여준다. 물론 ”-t” 와 ”-d” 옵션을 같이 지정할 수 없다.

만일 하나이상의 물리적 볼륨이 표시된다면, 보고되는  내용은 표시된 물리적 볼륨(들)에 국한된다. 여러  물리적 볼륨의 이름을 공백을 두고 표시함으로써, 동시에  여러 볼륨을 지정할 수 있다.

초단위의 시간이 사용될 수 있스며, 이 경우 출력자료내의  각 레코드들간의 시간을 표시한다. 최초의 레코드는  시스템이 부트된 이후로부터의 통계내용이며, 이후의  레코드들은 지정된 경과기간에 대한 자료를 보여준다.  아무런 경과기간이 표시되지 않으면, 한개의 레코드만이  출력된다.

만일 경과기간이 표시되면, 출력자료내에 몇개의 레코드들이  표시될 것인가도 지정할 수 있다. 또한 몇개의 레코드들을  표시할 것인가를 지정하지 않고  경과기간만 표시된 경우에는, ”iostat”는  강제로 종료되기 전까지 계속하여 작동한다.

Figure 1. “iostat 2 2″명령의 출력결과 예

“iostat” 출력자료의 tty 통계

“iostat” 출력자료내에서 tty 정보에 대한  “tin” 과 ”tout” 라는 두 줄의 내용은 모든  tty 장비들에 의하여 읽고 쓰여진 문자들의 수를  나타낸다. 이는 실제와 가상(5)  tty 장비  모두를 포함한다. 실제 tty 장비란 비동기 포트에 연결되어  있는 장비이며, 가상 tty 장비의 예는 쉘,  텔넷 세션과 aixterm 들이다.

  • “tin” 은 모든 tty 장비들이 1 초동안에  읽은 총 문자수를 나타낸다.
  • “tout” 는 모든 tty 장비들이 1 초동안에  쓴 총 문자수를 나타낸다.

일반적으로 입력되는 문자수가 출력되는 문자수보다는 작다.  예를 들어 다음 명령을 실행하여 본다:

이 경우, 입력된 문자수는 적고 출력된 문자수는 매우  큰것을 확인할 수 있다. 하지만, ”vi” 와 같은  어플리케이션들은 입력과 출력의 문자수는 매우 비슷하다.  비동기 파일 전송에 대하여 모뎀을 사용, 이를 분석하는  경우에는, 총 입력되는 문자수가 출력되는 문자수보다  크게 될 것이다. 즉 이는 해당 파일들이 측정하는 시스템에  대하여 어느 방향으로 보내지는가에 따른 것이라 할 수  있다.

입출력되는 문자에 대한 처리도 또한 CPU 자원을 소모하는  것이므로, tty 활동이 증가하는 경우에 이러한 활동의 증가와  CPU 활용이 증가하는가의 상관관계를 살펴 보도록 한다. 만일  그러한 상관관계가 존재한다면, tty 부시스템의 성능을  향상시킬 수 있는 방법들을 고려하도록 한다. 이에  해당하는 방법들은 어플리케이션 프로그램의 변경, 혹은  좀더 빠르고 효율적인 비동기 통신 어답터를 사용하도록  하는 방법들이 있을 수 있다.

“iostat” 출력자료의 CPU 통계

CPU 통계에 관련한 내용들은 (% user, % sys, % idle, % iowait) CPU 사용정도를 분류하여  보여준다. 이 정보는 ”vmstat” 명령의 us, sy, id, wa 에  표시된 통계와 동일한 것이다.

% user
“% user” 는 CPU 자원이 사용자 모드에서 사용된  백분율을 나타낸다. 유닉스 프로세스는 사용자 혹은  시스템 모드로 실행된다. 사용자 모드에서는,  프로세스는 자신의 코드내에서만 운영되며 커널 자원들을  필요로 하지 않는다.
% sys
“% sys” 줄은 시스템 모드에서 사용된 CPU 자원의  백분율이다. 이는 커널 프로세스들(kprocs)과  커널 자원들을 사용하기 위한 다른 프로세스들이 사용한  CPU 자원을 포함한다. 예를 들면, 파일을 읽고 쓰고자  하는 경우, 이 파일을 열고, 지정된 위치를 찾고,  자료를 읽고 쓰기 위하여 커널 자원이 필요하게 된다.  유닉스 프로세스는 커널 자원을 사용하기 위해서   시스템 호출(system call)을 이용한다.일반적으로 사용자시간과 시스템시간의 합계값이  단일사용자 시스템의 경우는 90 %,   복수사용자 시스템의 경우는 80 % 를 넘는 경우에,  해당 CPU 는 거의 작업을 하지 못한다고 할 수 있다.  이것이 의미하는  바는 CPU가 시스템 성능의 제약점이 될 수 있다는 것이다.

사용자와 시스템 모드의 비율은 작업부하에 의해 결정되며,  성능을 펑가할때 보다는, 어플리케이션의 성능을 조정하는  경우에 훨씬 중요하다.

CPU 성능을 평가할때 중요한 요소는  실행 큐(6) 의 크기이다.(이는  “vmstat” 명령을 통하여 얻을 수 있다) 일반적으로  실행 큐의 크기가 증가할 수록, 사용자는  응답시간이 점차 지연되는 것을 느끼게 된다.

% idle
“% idle” 줄은, 자신의   디스크 입출력을 기다리지 않으면서, CPU가 놀고  있거나 혹은 기다리면서 소비한 CPU 시간의 백분율을  나타낸다. 만일 실행 큐에 아무런 프로세스도 없다면,  시스템은 ”wait” 라 불리우는 특별한 커널 프로세스를  실행시킨다. 대부분의 AIX 시스템에서는, 이러한  “wait” 프로세스 ID(PID)는 514 이다.
% iowait
“% iowait” 줄은 지연된 자신의 디스크 입출력을 갖고  CPU 가 놀고 있는 시간의 백분율을 나타낸다.”iowait” 상태는 최소한 하나의 프로세스가  자신의 디스크 입출력이 완료되기를 기다리고 있다는 점에서  “idle” 상태와는 구분된다.  프로세스가 비동기 입출럭(7) 을  사용하지 않는 한, 디스크에 대한 입출력 요청은  이를 호출한 프로세스를 해당 요청이 완료될 때까지  블럭화(혹은 수면상태화)시킨다. 일단 한 프로세스의  입출력 요청이 완료되면, 이 프로세스는 실행 큐에 놓인다.

일반적으로 높은 iowait 율은 시스템의 메모리가  부족하거나, 혹은 비효율적으로 입출력 부시스템이 구성되어  있다는 것을 나타낸다. 입출력 병목을 이해하고  입출력 부시스템의 효율을 향상시키려면, ”iostat” 가  제공하는 정보보다 많은 추가적인 자료를 필요로 한다;  하지만 다음과 같은 일반적인 방법들을 적용할 수 있다:

  • 특정한 디스크상에 놓인 활동적인 논리적 볼륨들과  파일의 수를 제한한다.(이는 모든 디스크 드라이버들에게  균등적으로 파일 입출력부하를 부여한다는 사상이다)
  • 하나의 논리적 볼륨을 여러 디스크에 분산시킨다.(이는  여러개의 서로 다른 파일들이 사용되는 경우에  매우 적절한 조치가 될 수 있다)
  • 한 볼륨그룹에 대하여 여러개의 JFS 로그들을  만들고, 이들을 특정한 파일 시스템들에게 할당한다.(이는  특별히 임시 파일들과 같은 많은 수의 파일들을 수정, 삭제,  생성시키는 어플리케이션들에 대하여  이득이 된다)조각화(8) 를 줄이기 위하여  파일시스템들을 백업받고 재수록 한다.(조각화는  드라이버가 자료를 찾는데 많은 시간을 소요하도록 하고,  이는 전체 응답시간의 상당부분이 될 수 있다)
  • 현재 입출력 부시스템의 균형을 맞추기 위하여  추가적인 드라이버를 설치한다.

기본적인 어플리케이션만을 운영하는 시스템에서는,  높은 입출력 대기정도는 업무부하에 관련된 것일 수도  있다. 이러한 경우에는, 이러한 문제를 극복하기 위한  방법이 없을 수도 있다. 많은 프로세스들이 운영되는  시스템에서는, 몇몇 프로세스들은 입출력을 위하여  대기하고 있는 중에 다른 프로세스들은 운영되고 있을 것이다.  이 경우에는, iowait 는 아주 적은 값이거나 0 가  될 수 있는데, 이는 실행되는 프로세스들이  대기시간을 숨기기 때문이다. 따라서 iowait가 매우  낮은 경우에도, 이의 병목은 어플리케이션의 성능에 대한  제약이 될수도 있다. 입출력 부시스템을 완전히 이해하려면,  다음에 설명되는 통계수치등을 검증할 필요가 있다.

“iostat” 출력자료의 디스크 통계

“iostat” 출력자료의 디스크 통계는 입출력 사용정도를  분류하여 보여준다. 이 정보는 어떤 디스크가  성능에 제한을 가하는지를 결정하는데 매우 유용하다.

Disk I/O History
시스템은 기본적으로 디스크의 활동에 관련한 내역을  관리한다. 만일 다음의 메세지가 나타난 경우에는,  이러한 내역관리가 이루어지지 않고 있다는 것을 알려준다.

이 메세지는 iostat 의 첫번째 출력 보고서에만  표시된다.

디스크 입출력 내역은 반드시 실행하도록 하여야 하며,  이는 이를 유지관리하는데 소모되는 CPU 의 사용정도는  아주 미미하기 때문이다. 다음의 절차에 따르면,  이러한 내역관리를 가능하도록 하든지 혹은 하지 않도록  할 수 있다:

Disks
“Disks:” 줄은 물리적 볼륨(들)의 이름(들)을  보여준다. 이들은 ”hdisk” 혹은 ”cd” 다음에  숫자가 표시된다. 즉 ”hdisk0″ 는 첫번째 물리적 디스크  드라이버를 나타내고, ”cd0″ 는 첫번째 CD 디스크  드라이버를 뜻한다.
% tm_act
“% tm_act” 줄은 해당 볼륨이 활동적이었던 시간의 백분율을  나타낸다. 이는 병목에 대한 근본적인 표시자라고 할 수  있다.드라이버는 새로운 위치를 찾는 것과 같은 명령의 수행과  자료의 전송중에는 활동적이라고 한다. 이 디스크 사용  백분율은 자료의 경쟁에 직접 비례하는 값을 가지며,  성능과는 반비례한다. 즉 디스크의 사용이 증가할수록,  성능은 떨어지고, 응답시간은 증가하게 된다. 일반적으로,  디스크의 사용정도가 70 % 를 넘게되면, 프로세스들은  입출력이 완료되기에 충분한 시간보다 많는 시간을  기다리는데 소모하게 되는데, 이는 대부분의 유닉스  프로세스들은 자신들의 입출력이 종료될때까지  블럭화(수면상태)되기 때문이다.
Kbps
“Kbps” 는 해당 드라이버이 자료를 읽고 쓴 양을  초당 KB 단위로 보여준다. 이는 ”Kb_read” 와  “Kb_wrtn” 의 합계를, 보고기간동안의 초로 나눈 값이다.
tps
“tps” 는 초당 전송된 수를 나타낸다. 전송이라 함은  디바이스 드라이버 수준에서의 입출력 요졡을 말한다.
Kb_read
“Kb_read” 는 측정된 기간동안 해당 물리적 볼륨으로부터  읽은 총 자료의 양을 kilobytes 로 나타낸 값이다.
Kb_wrtn
“Kb_wrtn” 은 측정된 기간동안 해당 물리적 볼륨에게    쓴 총 자료의 양을 kilobytes 로 나타낸 값이다.

자료의 분석

위의 자료 각각만을 가지고 성능을 분석한다는 것은 의미가  없을 수도 있는데, 이는 각각의 보고내용은  어플리케이션의 특성, 시스템 구성방법및 물리적 볼륨과  어답터들에 관련한 너무 상세한 자료를 보여주기 때문이다.  따라서, 위의 자료를 분석할 때는, 어떤 형식들이  나타나며, 또 이들의 상관관계가 무엇인가를 찾도록  하여야 한다. 가장 일반적인 관계는 디스크의 사용정도와  자료전송율의 관계이다.

이들 자료를 이용하여 합리적인 결론을 얻을려고 한다면,  이를 분석하는 사람은 해당 어플리케이션의 디스크 자료  접근 형식(sequential인가? 혹은 random인가? 아니면  이들의 혼합된 형태인가?)을 이해하고 있어야 하며, 또한  시스템상의 디스크와 어답터의 물리적 특성도 이해하고  있어야 한다.

예를 들면, 한 어플리케이션이 sequential한  방법으로 자료를 읽고 쓴다면, 이때에 디스크가  바쁜 정도가 매우 높은 경우에는 높은 디스크 전송율을  기대할 수 있다.(여기서 Kb_read 와 Kb_wrtn 은  해당 어플리케이션의 읽기/쓰기 행동에 대한 이해를  확인시켜준다; 하지만, 이들 자료는 자료의 접근형식에  대한 아무런 정보도 제공하지 못한다)

일반적으로 디스크 전송율이 높으면서 디스크의 바쁜 정도가  높은 경우에는 아무런 문제가 되지 않는다. 하지만,  디스크가 바쁜 정도가 매우 높으면서 낮은  자료 전송율을 가지게 된다면, 논리적 볼륨 혹은  파일시스템 혹은 개별파일들이 조각화되어 있다는 것을  나타낸다.

얼마만큼이 높은 자료 전송율인가? 이는 사용하는  디스크 드라이버와 그 드리이버의 효과적 자료 전송율에  따라 달라진다. 즉 높은 자료 전송율은 효과적 랜덤  디스크 전송율(9) 과  효과적 직렬 디스크 전송율(10) 사이의 값이라고 할 수 있다.  다음은 공통적으로 사용되는 여러 SCSI-1 과 SCSI-2  디스크 드라이버의 효과적 전송율에 대한 표이다.

Table 1. 효과적 전송율(KB/초), 첫번째 부분

사용형태 400 MB 드라이브 670 MB 드라이브 857 MB 드라이브
직렬 읽기 1589 1525 2142
랜덤 읽기 241 172 262
직렬 쓰기 1185 1108 1588
랜덤 쓰기 327 275 367

 

Table 2. 효과적 전송율(KB/초), 두번째 부분

사용형태 1.2 GB 드라이브 1.37 GB 드라이브 1.2 GB S-2 드라이브 1.37 GB S-2 드라이브
직렬 읽기 2169 2667 2180 3123 랜덤 읽기 292 299 385 288 직렬 쓰기 1464 2189 2156 2357 랜덤 쓰기 362 491 405 549

전송율은 성능검증동안에 결정된 값이며, 운영체계와  어플리케이션의 부하를 고려하지 않는 하드디스크의  성능만을 반영한 미디어 전송율보다 더욱 정확한  기대치를 보여 준다.

이 자료의 또 다른 용도는 다음과 같은 질문에  대한 해답이다: "추가적인 스쿠지 어답터가  필요한가?" 만일 이와 같은 질문을 받아본 적이 있었다면,  아주 일반적인 답이나 혹은 상상만으로 대답했을 것이나,  이제는 정확한 자료를 이용하여 답을 줄 수가 있을 것이다.

“iostat” 를 이용하여 얻은 자료를 사용하여, 전송율에  대한 자료를 추적함으로써 정확한 답을 제공할 수가 있다.  즉 각각 디스크들에 대한 최대 전송율을 찾아야 한다.  만일 모든 디스크들에 대하여 최대 전송율이  발생하고 있다면(이는 매우 나쁜 경우이다) 사용중인  어답터에 연결되어 있는 디스크들에 대한 측정된  전송율은 위표에서 있는 효과적 SCSI 어답터 전송율보다  매우 낮을 것이다.

계획의 목적으로는, 해당 어답터의 측정된 성능의  70 %(예를 들면, SCSI-1 어답터의 경우 초당 2.8 MB)정도만  사용하여야 한다. 이는 가끔 발생하는 최대율에  대한 충분한 버퍼를 제공한다. 디스크를 추가할 경우에는,  자료 전송율을 염두에 두어야 한다. 최소한 기본적으로  사용할 효과적 전송율과 수집된 자료를  가져야 한다.

여러 측정기간동안에 자료 전송율이 스쿠지 어탑터의 효과적  성능정도에 접근하는 경우에는, SCSI 어답터의 용량이  부족할 수도 있다는 것을 명심하도록 한다. 이러한 경우에는,  위의 분석이 올바르지 않게 된다.

결론

“iostat” 의 근본적인 목적은 디스크의  활용정도(%tm_act 필드)를 관측하여 입출력 병목을  찾아내는데 있다. 또한 ”iostat” 는 CPU 문제의 확인,  용량계획에 대한 보조역할및 입출력문제들의 해결에 대한  방법제공등에 사용될 수 있다. ”vmstat” 와  “iostat” 를 이용하여, CPU, 메모리, 입출력 부시스템등에  관련한 성능문제들을 밝히는데 필요한 자료을 얻을 수 있다.


(1) 이는 AIX 전문가들을 위한  아이비엠의 잡지이다

(2) clock tick 의 약자로  1 시각 틱은 1/100 초를 뜻한다

(3) counters

(4) interval

(5) pseudo

(6) run queue

(7) asynchronous I/O

(8) fragmentation

(9) effective random disk-transfer rate

(10) effective sequential disk-transfer rate

Author: yyjksw