IOSTAT 관련 정보

 Published Date: 2008년 7월 26일

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