System Performance Tuning(I/O) Author 이영진대리, 강경구대리 Creation Date 2008-02-21 Last Updated 2008-02-21 Version 1.0 Copyright(C) 2004 Goodus Inc. All Rights Reserved Version 변경일자 변경자 ( 작성자 ) 주요내용 1 2008-02-21 이영진대리, 강경구대리 문서최초작성 2 2008-02-25 이영진대리, 강경구대리 문서업데이트 3
Contents 1. Performance management & Tuning... 4 1.1. 개요...4 1.1.1. 성능향상을위한일반론... 4 1.1.2. 시스템성능에영향을주는요소들... 5 1.2. 시스템속도의저하원인규명...5 1.3. 시스템통합으로투자 / 관리비용감소...6 1.4. 시스템자원용량계획 (capacity planning)...7 2. Intro Tuning... 7 2.1. trade-offs in performance tuning...7 2.2. Basic tuning procedure...8 3. Disk Tuning... 9 3.1. 디스크의성능정의...9 3.2. 디스크의성능정의...9 3.2.1. EIDE... 10 3.2.2. Small Computer Systems Interface(SCSI)... 10 3.2.3. Fibre Channel... 10 3.3. RAID... 11 3.3.1. Level 0 (Striping)... 11 3.3.2. Level 1 (Mirroring)... 12 3.3.3. Level 5 (Strinping with Interleved Parity)... 12 3.3.4. RAID 0 + 1 (striping plus mirroring)... 13 3.3.5. RAID 구성의최적화... 13 3.3.6. Interlace Size... 13 3.4. 디스크의성능측정하기... 13 4. Tuning Tip (System I/O Tuning)...15 4.1. IOPS?... 15 4.1.1. IOPS 의미? (The number of I/O operations per second)... 15 4.1.2. IOPS 와관계되는사항들... 15 4.2. Reduce IOPS method... 17 4.3. File System read ahead... 17 4.4. File System Write Behind... 19 4.5. Kernel Parameter Tuning... 21 4.6. Write Behind & read ahead integrated... 22
5. Cache Management...23 5.1. DNLC (Directory Name Lookup Cache)... 23 5.2. Inode Cache... 25 5.3. DNLC 와 Inode Cache 관리... 25 6. 결언...26 7. Pro-Active Tuning 성공사례...27-3 -
1. Performance management & Tuning 1.1. 개요 대부분의유닉스초심자들은시스템의여러가지세팅을적절히조절해주면시스템의성능이매우크게향상될것이라는생각을가지곤한다. 하지만이는커다란착각 (?) 이라고말해주고싶다. 왜냐하면이미웬만한상업용유닉스시스템들은어느정도의최적화가된상태로시장에나오는것이기에정확한지식없는시스템튜닝은오히려부작용을일으킬수있는것이다. 물론 Linux 나 FreeBSD 와같은비상업용유닉스를쓰는경우는논외로하겠다. 그러므로유닉스시스템성능향상을위한튜닝의기본적인원칙은다음과같다. 시스템이나네트워크에너무많은부하가걸리지않도록한다. 부하가많이걸리게되면자원을기다리는프로세스들이많아지게되고그러면점점누적되어시스템의성능이급격히저하되기때문이다. 불필요한기능이나쓸모없는일을위해시스템여분의성능을낭비하지않는다. 예를들면시스템의쿼터 ( 용량제한 ) 나 CPU 사용계산 (Accounting) 등이별로필요없는경우이에대한시스템의불필요한사용은시스템의성능저하의한몫만을할뿐이다. 추가적으로고려할사항은프로그램을만들때는시스템성능을고려한프로그램의작성이요구되며필요한시스템작업이요구되는경우부하가적은야간을이용해 cron 등스케줄링하여 JOB 돌려놓으면좋다. 시스템성능을향상시키는것은대부분의 IT 기업이끊임없이추구하는목표이다. 처리해야하는데이터의양이증가하고더욱다양해짐에따라특정작업을실행하는데허용되는시간은더욱짧아지고있다. 이를위해향상된알고리즘이개발되거나또는처리속도가더욱빠른시스템이개발되어야한다. 1.1.1. 성능향상을위한일반론다음은시스템의성능을향상시키기위해서필요한것들이다. 이것은유닉스시스템뿐만아니라다른운영체계의시스템에도해당되는것이다. 시스템이충분한메모리크기를가지도록하자. 일반적으로운영체계에서요구하는기본메 - 4 -
모리양이있다. 이를충분히수용할수있어야만그시스템은기대되는성능을낼수있는것이다. 프로그램의잘못된사용을바로잡는다. 앞서도언급하였지만시스템의성능을고려하지않고프로그램을짜서수행시키는경우나한꺼번에많은프로그램들을불필요하게수행시키는등의일은시스템의성능을떨어뜨리는결과를초래한다. 또한불필요한 Demon 의수행도마찬가지의결과를가져오는것이다. 시스템의하드디스크나파일시스템을정리한다. 이는파일시스템의여러가지옵션을조정하는것과쓸모없는디렉터리나파일의정리도포함된다. 항상네트워크상태를모니터링한다. 특히 Error 율이낮은지를 netstat 명령을통해체크한다. Kernel 재조정을통해필요없는드라이버와옵션등을제거한다. 예를들면자신의시스템에장착되어있는하드웨어를제외한다른회사의드라이버들은제거해도아무지장이없다. 다만만일의경우를고려해기존의드라이버들이모두있는 Kernel 백업은받은후에제거한다. 1.1.2. 시스템성능에영향을주는요소들시스템성능에영향을주는요소들은다양하게존재한다. 이요소들은여러가지로파악될수있지만그중에서도시스템의프로그램들이사용하는리소스의측면에서파악하는것이일반적이다. 시스템의성능에영향을주는요소들을리소스측면에서파악하면다음과같다. CPU 사용시간 메모리 하드디스크 I/O 양 네트워크 I/O 양모든프로세스는시스템리소스의일부를사용한다. 이러한리소스들을여유있게프로세스들이사용한다면시스템의성능은양호한것이다. 하지만그렇지않고리소스가없어프로세스들이기다리는경우가늘어날수록그시스템의성능은감소되는것이다. 프로세스들이기다리는시간을시스템성능의척도로사용하는경우도이러한이유때문이다. 1.2. 시스템속도의저하원인규명 시스템의상태를실시간모니터링하여성능저하로인한원인을발견하고대책을수립함. 장애의원인은무엇입니까? - 5 -
성능저하의원인이어디에서비롯되었습니까? 어플리케이션의처리속도를어떤방법으로향상시킬수있습니까? 시스템자원을언제, 얼마만큼증설하면됩니까? 성능 성능저하원인? 시스템? DB? Network? 또는 Application? 시간 1.3. 시스템통합으로투자 / 관리비용감소 시스템 performance tuning 으로다중분산화된 Application 을단일시스템에통합하여최적화할수있음. 이로인한시스템의재투자를줄이고관리에소요되는비용을줄일수있으므로보다경쟁력있는자사의전산환경을구축할수있음. - 6 -
1.4. 시스템자원용량계획 (capacity planning) 특정기간동안모니터링된시스템의데이터를분석하고, 그분석결과를토대로미래의자원부족을예측할수있다. 미래에필요한자원을미리준비하여가까운미래에자원부족으로인한시스템성능저하를줄이므로안정적인전산환경을유지할수있다. 용량? 시간 2. Intro Tuning 2.1. trade-offs in performance tuning 서론에서도언급하였듯이 Tuning 을하기위한절차를계획하고, 계획된순서에맞게진행을하면서적절한부분을 monitoring & tuning 하여야한다. - 7 -
튜닝은서로영향을준다. 따라서, 관련부분을같이튜닝하여야한다. CPU 문제를해결후보통 I/O 문제가발생할수있다. (I/O 문제가해결되면, CPU 문제가발생 ) Bottleneck 은전이 ( 傳移 ) 가능하다. 작업특성을고려해서반드시 Trade-off 를만들어놓고튜닝포인트를잡아서작업을진행한다. 균형적인튜닝을위해서권장되는것이반드시 Trade-Off 작업계획서를기반으로튜닝을진행하라는것이다. 한가지시스템자원 (Resource) 을튜닝하여개선할경우다른자원에어떤영향을미칠것인가를반드시분석하여놓고 Tuning 을실행하여야한다. 보편적으로 Trade-Off 는성능대비용의상관관계를분석할때많이사용하지만, Performance Management & Tuning 과정에서도반드시적용되어야한다. 2.2. Basic tuning procedure 시스템을 Tuning 할경우, 다음의 Process 에따라작업을진행하는것이일반적이다. 시스템도입시의 Tuning 도, (0) 의부분을제외하고같은 Process 가된다. (0) Performance 의문제가있는지를판단한다. (1) Performance 의판단기준 (Metrics) 을설정한다. (2) Performance 의목표치를정의한다. 동시에최우선해야할과제를정의한다. (3) 문제의요인을도출한다. (4) 문제의요인에대응하는해결책을검토, 실행한다. (5) 해결책을실행한결과를분석한다. (6) 목표가달성되지않았다면위의작업을되풀이한다. - 8 -
문제의인식, 실태의파악, 목표치의정의, 원인의특정, 해결책의검토 / 실행, 결과의분석이라는 6 항목으로구성된다. 이 Cycle 을되풀이하여계속적으로 Tuning up 에몰두하는자세가필요하다. 3. Disk Tuning 디스크서브시스템의성능분석및기타 Tool 을설명하며, 특히성능향상의주요부분및디스크관련기술을집중적으로다루고자한다. 3.1. 디스크의성능정의 디스크서브시스템의성능을결정하는몇가지중요한요소가있다. (1) 디스크용량 : 디스크서브시스템이나디스크에저장될수있는데이터양 (2) seek time : 디스크헤더가한트랙에서타트랙으로이동하는데걸리는시간으로성능에영향이큼 (3) rotational speed : 디스크 spin 의속도 (4) 데이터전송속도 : 디스크에서 host 로의데이터전송속도 (5) zone bit recording : 디스크에가변밀도로데이터를기록할수있는기술로높은량을제공하며, 디스크드라이버의전송속도및용량을증가시킨다 (6) bus bandwidth : 시스템버스에의한데이터전송가능한양 (7) controller : 호스트와디스크드라이버간 read/write 를조정하는디바이스 (8) buffer size : 디스크콘트롤러에있는 cache 의양 (9) mean time between failure(mtbf) : failure 간평균시간 (10) mean time to data loss(mtdl) : 데이터손실전까지의디스크평균시간 3.2. 디스크의성능정의 호스트와디스크인터페이스간의표준 (EIDE, SCSI, Fibre channel) - 9 -
3.2.1. EIDE Enhanced Integrated Driver Electronics(EIDE) 는 low-end system 의표준이며 16.7MB/sec 의전 송속도, SCSI 보다는비교적저렴한비용이든다. EIDE 는 Sun 의 Ultra 5,10 에서제공된다 3.2.2. Small Computer Systems Interface(SCSI) SCSI 는지난 10 년간컴퓨터의 Interface 로꾸준히사용되었으며, SCSI-I 은 5MB/sec 의전송 속도를가졌으며, SCSI-II 라불리는향상된버전은 16MB/sec 의 Fast SCSI Interface 이며, 16 bit Fast/Wide SCSI Differential SCSI, Ultra SCSI 등이있다. 16bit 는 40MB/sec 의전송속도를지원. SCSI Fast SCSI Fast and Wide SCSI Ultra SCSI Asynchronous/ Synchronous Asynchrononous or synchronous Single-ended Synchronouns Differential Synchrononous Differential Synchrononous Differential Transfer Rate Number of Pins Width 5 MB/second 10 MB/second 20 MB/second 40 MB/second 50 pins 50 pins 68 pins 68 pins 8 bits 8 bits 16 bits 16 bits Maximum Calbe Length Mumber of Targets 3.2.3. Fibre Channel 6 m 3m synchronous 25 m differential 3m synchronous 25 m differential 3m synchronous 12 m differential 7 7 15 15 대규모시스템과워크스테이션, 주변장치간고성능의 point-to-point 방식의통신을제공하며, 여러가지의이점을제공한다. (1) 효과적인고성능 (2) 확장성 (3) 장거리동작 (4) 연결의용이성 (5) switched 네트웍 FC-AL 의특성 (1) Gigabit bandwidth (2) 초당 100MB/sec 의전송속도 (3) Suitability 네트웍 (4) Building 네트웍을위한허브및 switch 제공 (5) SCSI 프로토콜사용 - 10 -
(6) SCSI 보다장거리지원 (7) 10KM 까지지원가능 (8) 고유디바이스명지원 (9) 64bit World Wide Device 명지원 3.3. RAID Redundant Arrays of Inexpensive Disks(RAID) 는 1987 년버클리연구소에서처음으로시작되었으며, 소규모의전원으로값비싼디스크들의결합을통해고성능의저렴한디바이스를만들고자함이었다. 때문에 RAID 는다중 spindle 의채택으로드라이버중하나가 Fail 시손상되는데이터를어떻게보존할수있느냐가관건이었다. 디스크서브시스템의성능을가름하는두가지의요소가있다. (1) 전송속도 (Transfer Rate) : 이는대규모의데이터를 read 와 write 하는초당전송속도를말한다. (2) 초당 I/O 동작 (IOPS) : IOPS 는주어진시간안에 I/O 와다중 I/O 를처리하는수치로, 데이터베이스와 Transaction Processing System 은높은 I/O Rate 를요구한다. (3) 복구 : 하나의디스크가 Fail 시 Array 는 Reduced mode 로동작하는데이는 Array 의전체성능을저하시키며, RAID Level 에따라사뭇다르다. 이때시스템관리자는 Fail 된디스크의교체작업을진행해야하며, 정상동작을위해데이터의복구가필요하며, 어떤시스템은 hot spare 라불리는미리정의된디스크드라이버를통해자동복구도가능하다. Hot sparing 은정상성능을내기위한빠른복구를지원하며, 관리자에게좀더편한관리를지원한다. (4) 전형적인 RAID Level : RAID 구성은획기적으로성능을증대시킬수있으며, 여러가지 RAID Level 마다특성을가지고있다. 3.3.1. Level 0 (Striping) Striping 은같은크기의 chunk 나 stripe block 을여러디스크에나누어위치시키며, 각 chunk 는 Array 의연속적인드라이브에순차적 write 가된다. RAID 0 는여러디스크에걸쳐 I/O 의균형을유지하므로우수한 IOPS 를제공한다. - 11 -
3.3.2. Level 1 (Mirroring) 각 write 마다별도의하나이상의 mirror 된디스크로복사한다. Mirrored 시스템은 read 시 높은 IOPS 성능을제공하며, write 성능은개별디스크의 write 보다는약간떨어진다. 3.3.3. Level 5 (Strinping with Interleved Parity) RAID 5 는하나의그룹안에각디스크드라이브에 striped 된데이터를저장시키며, 데이터의에러검출정보 (parity) 를또한저장시킨다. 이는훌륭한 sequencial 성능을보장하며하나의디스크 fail 시데이터손실없이남아있는디스크로부터복구가가능하다. - 12 -
3.3.4. RAID 0 + 1 (striping plus mirroring) 두개의 RAID 를조합하여구성되며, 보편적으로 RAID 0+1 으로불러지며, 성능적측면의 RAID 0 와안정적측면의 RAID 1 을혼용하여사용한다. 3.3.5. RAID 구성의최적화 RAID 는구별되는장 / 단점을보유하고있으며, 여러종류의업무성격에따라선택적으로사용되어야한다. 예를들어, random 성능이필요한데이터베이스시스템, 안정성, 성능등다방면의검토가필요하다. 3.3.6. Interlace Size chunk size 라불리우며, 이는 stripe 된개별디스크에쓰여지는데이터양으로, 최적의 Interlace size 는 read/write 의성능을좌우할수있는요소이며, I/O 형태에따라적절한 size 가정의되어야한다. (1) 높은 random I/O 가요구될시 interlace size 를크게할것 (2) sequencial I/O 시작은 I/O 를사용할것 3.4. 디스크의성능측정하기 디스크의성능을측정하기위해 sar 명령어로성능정보를수집할수있으니여기서는 iostat 명령어로설명한다. 다음은 iostat 명령의결과를나타낸다. # iostat -x - 13 -
extended device statistics device r/s w/s kr/s kw/s wait actv svc_t %w %b fd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 sd0 0.9 0.1 7.2 0.4 0.0 0.0 11.9 0 0 sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 sd6 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 ssd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 r/s 는초당 read 수이고, w/s 는초당 write 수이다. kr/w 는초당읽은 KByte 수를나타내고, kw/s 는초당쓴 KByte 수이다. Svc_t 는평균 I/O 서비스시간 (Milli second) 을말하는데큐에서대기하는시간 (Queue Time) 까지가포함된시간이다. %b 는디스크가비지한상태인시간의백분율로디스크에실행되고있는백분율을나타낸다. 일반적으로 svc_t 가 30ms 이하가일반적이고, 그이상이고 50ms 미만이며 %b 가 5% 이하일경우도보통의상태이다. 하지만 50ms 이상이되고 %b 가 20% 이상일경우는디스크가병목현상을일으킨다고볼수있다. %b 는큐가비어있지않는시간의백분율을나타내는데, 서비스를위해기다리는시간의백분율이다. 보통 %w 가 5% 이상일경우디스크에부하가매우많이걸리고있다고할수있다. 디스크의성능분석을위한대표적인모니터링항목 Kr/s(Read Size) Kw/s(Write Size) 항목명단위설명 Svc_t( 평균 Service Time) Wait( 평균 Wait Time) KB/second KB/second Msec Mesc 초당디바이스에서발생한물리적인읽기 (Read) 를수행한값, 이는어떤디스크에얼마만큼의물리적인읽기 (Read) 가발생하는지를나타내므로디스크사용률의측정기준이되며이값을기분으로특정디스크의읽기 (Read) 에대한부하도를알수있다. 초당디바이스에서발생한물리적인쓰기 (Write) 를수행한값. 이는어떤디스크에얼마만큼의물리적인쓰기 (Write) 가발생하는지를나타내므로디스크사용률의측정기준이되며이값을기준으로특정디스크의쓰기 (Write) 에대한부하도를알수있다. 디스크에액세스한이후디바이스가실질적인서비스작업을완료할때까지의시간디스크에액세스를하지못하고큐에서기다리는시간. 디스크를액세스하여읽기 (Read) 혹은쓰기 (Write) 를수행하려할때해당디스크가이전명령에의한엑세스에대한읽기혹은쓰기가아직진행중이라면액세스를하지못하고액세스작업이완료될때까지큐에서기다려야한다. - 14 -
4. Tuning Tip (System I/O Tuning) 4.1. IOPS? 4.1.1. IOPS 의미? (The number of I/O operations per second) 단위시간 ( 기본 1 초 ) 동안에디스크로부터 Input / Output 한수치. IOPS 를줄이면단위시간동안많은양의데이터를한번에전송할수있으므로시스템의 Response Time ( 응답시간 ) 을줄일수있다. 4.1.2. IOPS 와관계되는사항들 bandwidth of the bus - bus 의대역폭 ( bandwidth ) - scsi card 종류 ( scsi1, scsi2, scsi3, ultrascsi ) amount of available memory - 사용가능한 memory 양 Capacity of th cache - memory cache 의데이터보유양 - buffer cache, DNLC, inode cache size speed of the disks - seek time, latency time (RPM) - 적절한 DISK RAID 정책 성능관리를시작하기전에분명히규정하고넘어가야할것들이있는데, 바로 Performance Tuning 을위한용어정의이다. 용어에대한이해가선행되지않으면개념적으로난해한요소들에부딪힐수있기때문이다. 그중에서몇가지핵심적인용어의의미를명확히정의하여보자. 이용어들은용량관리 (Capacity Planing & Sizing) 분야의이해를위해서라도꼭이해 - 15 -
하고있어야한다. 성능관리분야의용어정리 Bandwidth : * 초과될수없는최상의 capacity * Overhead 를무시한측정치 * The best(perfect) case number * 실행시도달할수없는어떤값 ( 실행시 inefficiency( 무능, 무효과, 비능률 ), Overhead 가있기때문 ) Throughput : * 특정시간동안실제할수있는작업의량 (what you really get) * Bandwidth 중실제로사용되는 capacity * 실제 Throughput 의측정값은다양한요소들에의해영향받는다.(H/W, S/W, human, Random access) * 정확한 Throughput 값의측정은불가능하며, 단지근사치 (Approximated value) 만을구할수있다. * Maximum Throughput 을측정한다면 100% 사용율 (utilization) 에서얼마나많은작업량이가능한가를평가하는것이된다. Response Time : * 총경과시간 (+ wait time 포함, + Run Queue 대기시간 ) * user 가응답을받기까지걸린총시간 * Elapsed Time for an operation to complete * Usually the same thing as latency Service Time : * 실제 request 를처리하는데만사용된시간 (Queue 대기시간, Wait Time 제외 ) = actual processing time * The best(perfect) case number * Response Time 에서 Wait Time(Queue Delay) 을빼면 Service Time 이된다. Utilization : * 측정대상작업을수행하기위해사용된자원의사용량 ( 독자적이건, 종합적이건 ) * 자원량 : Throughput 을수행하기위한 * 백분율 (%) 로표시되면일반적으로 busy%( 률 ) 로나타낸다. - 16 -
이용어들은서로상관관계를가지고있는데, Utilization 이 100% 에도달하는순간이되면 Response Time 은빠르게되지만 ( 자원의이용방법에따라다르다 ), Troughput 은포화상태에도달하여떨어지게되어있다. 이시점의 Throughpu 을 "Drop-Off" 라고한다. 결국, Performance Tuning 은 100% Busy 상태에도달한자원 (Drop-Off 된자원 ) 의소재를찾아서그가용성을높여주는것이목표이다. 4.2. Reduce IOPS method IOPS 를줄일수있는방법 - 한번의 I/O 발생시많은양의 DATA 를읽고쓰기함. read ahead & write behind 기능사용 - UFS cache 를 tuning 하여 cache-hit 율을증가시킴. 적절한 RAID 정책을설정함. - strip size & cluster size 를설정함. 4.3. File System read ahead Read ahead 라는것은현재시점에서파일의사용이미리있을것이다는것을염두에두고파일에서일정내용을사용되기전에미리읽어오는것이다. 이것은시스템이디스크에대한연산을줄이는효과가있으며, 이렇게함으로서전체적인 I/O 의성능을개선할수있다. 물론이것은전적으로커널에서행해야하며, 사용자프로세스는모른다. 물론이것을하기위해선커널의메모리를사용하게되기에비효율적으로관리하면오히려역효과가날수있다. 나중에사용자프로세스는다시파일에대한연산을하려고할때이곳에서데이터를가져올수있게된다. 따라서, I/O 가일어나길기다릴필요없이미리읽어온데이터를가지고연산을계속할수있게되는것이다. 이튜닝은 ufs 에만해당하면 zfs 인경우에는해당하지않습니다. 또한, 이옵션은 SATA 와 SAS 디스크의경우에는해당되지않는다. 동시에동시전송블럭의수를늘렸기때문에물리적인디스크와사용하게될버퍼의크기는 1M(=1048576) 으로설정할필요가있다. 1) 파일시스템의기능중에서데이터를읽어오는방식중미리읽기기능이있다. 이것을설정하면한 block 을읽어올때여러 block 을미리읽어오는기능이있다. Ex) Read ahead 를 6 으로설정한예제 - 17 -
8K 8K 8K 8K 8K 8K < 메모리 > 8K 8K 8K 8K 8K 8K 8K 8K 8K 8K 2) 설정방법은 UFS file system setting 값중에서 maxcontig 값을설정. 3) Maxcontig 값의단위는 1 block (8192byte) 4) fstyp 명령을이용하여 maxcontig 정보를확인. Ex) root# fstyp -v /dev/rdsk/c0t0d0s0 grep maxcontig maxcontig 6 rotdelay 0ms rps 120 < 디스크 > 5) tunefs 명령이나 newfs 명령을사용하여설정 Ex) root# tunefs -a 128 /dev/rdsk/c0t0d0s0 maximum contiguous block count changes from 6 to 128 root# newfs C 128 /dev/rdsk/c0t1d0s3 % 128 block 이므로 128*8192 = 1,048,576byte 의데이터를한번에미리읽어오게된다. maxcontig 값이 6 일때와 128 로변경후 I/O 성능을비교 Maxcontig 값설정전 root# fstyp -v /dev/rdsk/c0t0d0s0 grep maxcontig maxcontig 6 rotdelay 0ms rps 120 root# cp 500m /ARCH1/500m & [1] 20376 root@svrdb1 # iostat -x 5 extended device statistics device r/s w/s kr/s kw/s wait actv svc_t %w %b sd0 492.4 0.0 10543.8 0.0 0.0 0.5 1.1 1 48 sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 sd6 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 ssd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0-18 -
ssd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 ssd2 13.0 31.0 120.5 20650.3 0.0 6.0 137.8 2 100 Maxcontig 값을 128 로설정후 root# tunefs -a 128 /dev/rdsk/c0t0d0s0 maximum contiguous block count changes from 6 to 128 root# cp 500m /ARCH1/500m & [1] 8416 root@svrdb1 # iostat -x 5 extended device statistics device r/s w/s kr/s kw/s wait actv svc_t %w %b sd0 95.5 0.0 15047.4 0.0 0.0 0.5 5.0 0 47 sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 sd6 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 ssd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 ssd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 ssd2 5.0 34.0 30.2 21879.9 0.0 6.2 159.4 1 99 4.4. File System Write Behind 1) 파일시스템의기능에는데이터를메모리버퍼에임시저장후한번에저장하는기능이있다. 이기능을 Write Behind 라고한다. 연속적으로데이터를기록하는작업환경에서는 filesystem 의 Write Behind 기능을설정하여 IOPS 양을줄일수있다. Ex) Write Behind 6 으로설정한예제 8K 8K 8K 8K 8K 8K < 메모리 > 8K 8K 8K 8K 8K 8K 8K 8K 8K 8K < 디스크 > 2) 설정방법은 UFS filesystem setting 값중에서 maxcontig 값을설정. 3) Maxcontig 값의단위는 1 block (8192byte) - 19 -
4) fstyp 명령을이용하여 maxcontig 정보를확인. Ex) root# fstyp -v /dev/rdsk/c0t0d0s0 grep maxcontig maxcontig 6 rotdelay 0ms rps 120 5) tunefs 명령이나 newfs 명령을사용하여설정. Ex) root# tunefs -a 128 /dev/rdsk/c0t0d0s0 maximum contiguous block count changes from 6 to 128 root# newfs C 16 /dev/rdsk/c0t1d0s3 ** 128 block 이므로 128*8192 = 1,048,576byte 의데이터를한번에저장하도록설정한다. maxcontig 값이 6 일때와 128 로변경후 I/O 성능을비교 Maxcontig 값설정전 root# fstyp -v /dev/rdsk/c0t0d0s0 grep maxcontig maxcontig 6 rotdelay 0ms rps 120 root# mkfile 500m 500m & [1] 29699 root# iostat -x 2 extended device statistics device r/s w/s kr/s kw/s wait actv svc_t %w %b sd0 0.0 141.0 0.0 6743.3 7.5 168.2 1246.4 33 100 sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 sd6 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 ssd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 ssd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 ssd2 8.0 4.0 32.5 9.5 0.0 0.1 5.6 0 7 real user sys 1m26.18s 0m0.11s 0m5.21s Maxcontig 값을 128 로설정후 root# fstyp -v /dev/rdsk/c0t0d0s0 grep maxcontig maxcontig 6 rotdelay 0ms rps 120 root# tunefs -a 128 /dev/rdsk/c0t0d0s0-20 -
maximum contiguous block count changes from 6 to 128 root# mkfile 500m 500m & [1] 10920 root@svrdb1 # iostat -x 2 extended device statistics device r/s w/s kr/s kw/s wait actv svc_t %w %b sd0 0.0 38.5 0.0 25411.4 0.0 13.6 353.6 0 99 sd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 sd6 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 ssd0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 ssd1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 ssd2 10.0 5.5 56.5 25.7 0.0 0.1 5.3 0 8 real user sys 0m27.59s 0m0.14s 0m5.77s Maxcontig 값을 128 로변경후 3 배이상의 I/O 성능이향상되었다 ** 단위의명령중 newfs C 명령은시스템운용중에는불가능하며새로운파일시스템을구성시에적용할수있다. Ex) Oracle Datafile 추가예제 maxcontig 값이 6 SQL> alter tablespace TEST1 add datafile '/test/test1_2.dbf' size 200m; Tablespace altered. Elapsed: 00:00:28.55 maxconfig 값이 128 SQL> alter tablespace TEST2 add datafile '/test/test2_2.dbf' size 200m; Tablespace altered. Elapsed: 00:00:09.06 4.5. Kernel Parameter Tuning Read ahead 와 write behind 기능과관련된 kernel parameter - 21 -
Read ahead & Write Behind 를설정하였다하여도 scsi 의최대전송 size 가작다면 scsi 전송용량 size 보다더많은데이터는전송하지못한다. 예를들어 scsi 의최대전송용량이 128k 인데 maxcontig 값이 512k 라면데이터는 128k 이상전송되지않는다. RAID 0 (striping) : 클러스터크기는스트라이프크기에의한여러개의스트라이프멤버수와같다. RAID1 (mirroring) : 클러스터의크기는디스크의절반과같다. RAID0+1 (striping + mirroring) : 클러스터의크기는스트라이프크기에의한여러개의미러당스트라이프멤버의수와같다. Solstice DiskSuite 와 Veritas Volume Manager(VxVM) 과같은볼륨을사용자가이용할때, 매우큰클러스터의크기를요구하면, 큰전송을하기위해사용자는 /etc/system 커널설정파일에서 SCSI 나 Volume manager 관련파라메터를설정할필요가있다. 아주큰 SCSI I/O 전송을하기위해는 (byte 단위 ) set maxphys = 1048576 아주큰 Solstice DiskSuite 전송을하기위해서는 (byte 단위 ) set md_maxphys = 1048576 아주큰 VxVM I/O 전송을위해서는 ( 블록단위 : 512byte 단위 ) set vxio:vol_maxio = 2048 로설정할수있다. maxphys 는상당히오래된커널변수인관계로최신디스크나어레이등을사용할때는반드시사용하는것이좋습니다. #echo "set maxphys=1048576" >> /etc/system 설정하고재부팅이필요합니다. 이튜닝은상위화일시스템과상관없이사용하는것이좋습니다. 4.6. Write Behind & read ahead integrated Read ahead 및 write behind 설정시반드시 filesystem 의 Workload ( 작업형태 ) 를확인한후에설정을하여야한다. 연속된큰파일을읽어들이는작업형태일경우 ( 예 : Database) 많은수의 block 를미리읽기로설정하면성능을높일수있다. 비연속된작은파일의 I/O 가발생하는작업형태일경우 ( 예 : web, mail) read ahead 나 write behind 의기능을정지하여야한다. - 22 -
예를들어한번에 I/O 시 1kbyte 사이즈보다작은파일을읽어들이는작업형태에서 read ahead 를 128 로설정했다면필요하지않은 1,048,576byte 의데이터를미리읽 어오기때문에오히려 I/O 시간이늘어나고메모리를낭비하는결과를갖는다. ** 위의 ufs 튜닝옵션들은모두서비스제공중에설정가능한것이나, 최적의성능을위해서라면화일시스템을새로이구성하시는것이바람직합니다 5. Cache Management 5.1. DNLC (Directory Name Lookup Cache) 최근에참조했던 directory name 과 vnode 를기억하고있는 cache 이다. directory name 검색시 filesystem 의 inode 정보와 directory data block 의정보를읽어오기때문에 disk 의 I/O 가발생한다. 최근에검색했던 directory name 을메모리에 cache 하여중복된 directory 내용검색시메모리의 cache 에서 directory 정보를찾도록하여 disk 의 I/O 를줄일수있다. vmstat -s 으로모니터링시 DNLC cache hit 율이 90% 이상이되도록함. ( 만일 90% 이하의값이면 DNLC cache size 를증가하여야한다.) Ufs, nfs 에서사용된다. 커널의파라미터명은 ncsize 이다. vnode 란? 다양한파일시스템에대한구조체제공 여러종류의파일시스템에대하여같은시스템호출인터페이스사용 서로다른파일시스템이하나의계층적논리적인디렉토리목록으로사용가능하도록제공 Vnode (Virtual node) 는하나의파일을나타냄 다수의파일시스템을동시에제공 디스크파티션마다파일시스템타입이다를수있다. 네트워크상에서파일공유를지원한다. 새로운파일시스템타입을쉽게생성추가가능하다. 파일에접근하면접근했던기록이아래의그림처럼 memory 내의특정영역에 cache - 23 -
되어 VNODE number 와 file 의 full path 이름이기록된다. < DNLC Cache > Full path 명 Vnode 번호 /usr/bin/ksh 00000300024f8090 /usr/bin/csh 00000311024f9091 /etc/vfstab /etc/shadow 00000323024f5900 00120311033f9541 mdb utility 를이용하여현재시스템의 DNLC 정보를확인한다. # mdb -k Loading modules: [ unix krtld genunix ip usba logindmux ptm md cpc random nfs ] > ::dnlc VP DVP NAME 00000300018960a0 000003000189be78 d46 00000300016a60a0 0000030000d497b0 md@0:1,125,raw 00000300018080a0 000003000180d128 d23 00000300017780a0 0000030001778288 S01MOUNTFSYS 00000300018a60a0 0000030000d497b0 pts@0:4... 00000300017e2110 00000300017f6a60 d116 000003000105e118 0000030000c92e18 mount 000003000186e118 0000030000d620c8 cfg > 000003000105e118::vnode2path /sbin/mount > 0000030000c92e18::vnode2path /sbin > ::quit DNLC 는 kernel parameter 의 ufs_ninode 이며기본값은아래와같다. - ncsize = 4 x (maxusers + max_nprocs) + 320 - 설정방법은 /etc/system 파일에아래와같이하면된다. #vi /etc/system set ncsize=4000 set ufs_ninode=4000 #reboot - 24 -
5.2. Inode Cache Open 한 Inode 목록을포함 DNLC 를이용하여디렉토리목록의위치참조 Inode cache 와 DNLC 는매우유사하다. DNLC 의모든목록은 inode cache 의목록이된다. inode 목록을빠르게찾는것은디스크를다시읽을필요가없기때문이다. DNLC, inode cache 는 LRU(Least Recently Used) 를기본으로하여관리된다. 오래된목록은새로운목록으로교체를한다. 5.3. DNLC 와 Inode Cache 관리 DNLC 와 inode cache 들은같은크기를가진다. (DNLC 목록들은 inode 목록을가진다.) 기본적으로 4 * (maxusers + max_nprocs) + 320 의크기를가진다. Inode cache 크기는 ufs_ninode 에의해설정 - NFS 서버의경우높게설정 (50,000 이상 ) - DNLC Hit 비율은 90% 이상유지 DNLC 와 inode cache 들은 DNLC 목록이 inode cache 목록을가지기때문에같은크기를가진다. Inode cache 로부터삭제된목록은 DNLC 에서도같이삭제된다. Inode cache 는오직 UFS(inode) 데이터에대해서만 cache 를하고, DNLC 는 NFS(rnodes) 와 UFS(inode) 데이터에대해서만 cache 를하기때문에 NFS 와 UFS 동작비율은 ncsize 가수정이될때좌우된다. Boot 후부터현시점까지 DNLC cache hit 율확인 (hit 율이 90% 이하이면 DNLC cache 의 부족을판단함.) # vmstat -s 0 swap ins 0 swap outs 0 pages swapped in 0 pages swapped out 46973 total address trans. faults taken... 1318405 system calls - 25 -
126424 total name lookups (cache hits 96%) 90% 이하이면 ncsize 값증가 2196 user cpu 4482 system cpu 7863209 idle cpu 2753 wait cpu 6. 결언 UFS 파일시스템상의 I/O 튜닝을소개하였습니다. 실질적으로나타나는증상별로해결방안을찾아야하는어려움이있으나일반적으로사용되는파일시스템의내부구조와커널의파라메터등을소개함으로써단순히운영체계를설치후사용하던관리자들에게새로운사항들을접할수있는기회라생각되어정리하였습니다. 자신의작업환경을고려해성능을스스로평가해보는것이가장좋은튜닝방법이라할수있고여기에소개된튜닝에대한방법들은페이퍼에서흔히볼수있는조언들입니다. 시스템관리자들에게뚜렷한해결방안을제시해주기보다는소개된사항들을데이터집약적환경설정에서성능을향상시키고자하는분들에게매우유익하다고볼수있습니다. Solaris8 이전버전을사용하고계시는관리자들에게필요한튜닝방법과 solaris8 이상을사용하고계시는관리자분들과는구분되는부분이있을수있으니이점주의하시길바랍니다. 참조문서 http://docs.sun.com http://sunsolve.sun.com Sun Performance Guide / Sun Press / 2004-26 -
7. Pro-Active Tuning 성공사례 고객사 OOO 상담원 구축기간 2007.07.19 ~ 2007.07.26 고객사이슈및구축배경 1. Application 에서요구하는데이터처리 (SQL) 프로그램의 Access 가비효율적인패턴을보임. 2. 고가용성시스템으로구축되지않음. 3. RDBMS 가개발단계부터통계정보가없음 4. 업그레이드된서버의자원 (CPU, Memory, Disk I/O) 에맞게 DBMS 가최적화되지않음. 5. Index 전략부재 ( 결합인덱스전략없이 Single Index 로구성된사례많음 ) 6. 향후데이터가늘어날경우를대비한부분범위처리형태의 SQL 전략없음. 고객사이슈해결방안효율적인 access 패턴을위한 sql tuning 및 index tuning 진행 rule base 사용기반으로하는 tuning 계획수립진행부분범위처리형태로프로그램 (SQL) 튜닝로그성데이터의주기적인 Cleansing 을위한 Range partition 의검토와 parallel processing 에대한검증및도입이요구됨 구축후개선점각종 wait event 비율이현저히감소하였으며 CPU 자원사용량감소와불필요한 DISK I/O 제거를통하여 database 전반에걸친 resource 사용량감소, system performance 향상에영향을주었습니다. - SQL Tuning 사례 - 27 -
- 프로그램 /SQL 들의튜닝전후개선율비교 튜닝전시간 합계 튜닝후시간 합계 개선율 튜닝전블럭액세스량 합계 튜닝후블럭액세스량 합계 개선율 590.997 초 33.17 초 17.8 배 37,539,159 개 841,817 개 44.5 배 700 600 500 400 300 200 100 0 튜닝전 튜닝후 10000000 9000000 8000000 7000000 6000000 응답속도 5000000 4000000 3000000 2000000 1000000 0 튜닝전 튜닝후 블록액세스량 CPU 사용량 Tuning 전 (2007.07.19) Tuning 후 (2007.07.26) 튜닝전에는최고 95% 의 CPU 사용을나타내나, 튜닝후에는 20% 미만의사용량을나타냄. Logical I/O Tuning 전 (2007.07.19) Tuning 후 (2007.07.26) - 28 -
튜닝전에는최고초당 800,000 blocks 를 scan 하였지만튜닝후에는최대 110,000 blocks 미만을나타냄. 튜닝후평균적으로약 10 배 (200,000 : 20,000) 성능향상보임. 현재데이터증가추이로볼때향후 3년정도는무난히사용할수있을것으로보임. 또한추가적지속적인 tuning 시 system(hard ware) Life Time 을 5년까지유지시킬수있음. 그러나데이터가현재보다 2배이상으로증가하거나또는대량의데이터를가공하여통계를생성하는작업이많아진다면 I/O 성능개선은꼭필요할것으로보인다. - 29 -