성능관련 Tuning에서 사용되는 명령어

일부 성능 관련 명령어는 5.2부터 바꼈습니다.vmtune vmo & iooshedtune schedo

vmo, ioo, sheduo, no, nfso의 사용방법이 모두 동일 해졌습니다.

1 -L : 항목에 대한 현재값, 기본값, 재부팅후 적용될 값, 설정가능한 값의 범위, 항목의 단위와 설정값 변경시 적용되는 형태에 대한 정보를 줍니다.TYPE D : 바로 적용, S : 변경 불가, R : 재부팅 이부터 적용

S = Static: cannot be changed D = Dynamic: can be freely changed B = Bosboot: can only be changed using bosboot and reboot R = Reboot: can only be changed during reboot C = Connect: changes are only effective for future socket connections M = Mount: changes are only effective for future mountings

2 -L “Item”으로 사용하면 해당 Item에 대한 값만 보여주고 –L만 사용하면 전 항목을 보여줍니다.3 -a : 모든 항목의 현재의 설정값을 보여줌, -r과 함께 사용하면 재부팅 후 어떤값이 적용될지를

보여줍니다.4 -o “Item” : “Item” 항목의 현재값을 보여줍니다.

4.1 -o “Item”=”New Value”를 사용하여 Item의 값을 New Value로 바꿔줄수 있다. 이때 값의 적용에 대해서는 적용되는 형태에 따릅니다.

4.2 -o “Item” –r 은 “Item” 항목이 재부팅 후 어떤값이 적용될지를 보여줍니다.4.3 -o “Item”=”New Value” –r 을 사용하면 해당 항목의 변경이 다음 재부팅부터 적용됩니다.

“Item”을 명시할 때 vmo 혹은 ioo등에서 보여주는 항목과 그대로 동일하게 명시하면 됩니다.가령 vmo –o maxperm=40 이 아니라 vmo –o maxperm%=40 이라고 하셔야 합니다.

5 -p : -o 를 사용할 때 시스템 재부팅 후에도 똑같이 적용할 때 사용(-p를 사용하지 않으면 재부팅 후 바꾸지 전의 값으로 돌아감) /etc/tunable/nextboot 에 해당 값들이 저장됩니다.

6 -D : 전체 항목을 기본값으로 되돌려줍니다.7 -d “Item” : 해당 항목만 기본값으로 되돌려줍니다.

IBM 에서 공식적으로 제공하는 perfpmr은 아래의 site에서 받을수 있습니다.(perfpmr 은 수시로 통보없이 update됩니다. 그러기에 필요할때마다 새로 받으셔서 사용하시기 바랍니다.)ftp://ftp.software.ibm.com/aix/tools/perftools/perfpmr

AgendaI. CPU

II. VMM

III. LVM

IV. Network

V. Summary

I. CPU

1. Priority 란?

2. %iowait 란?

3. SMT 에서의 CPU 성능분석

4. Tuning(smt_snooze_delay)

1. Priority 란?

0 부터 255 까지 총 256 가지가 있으며 낮을수록 CPU 사용에 대한 우선순위가 높습니다.이중 0 부터 39 까지의 priority 를 가지는 Thread 는 무조건 바로 실행시켜줘야하는 권한이며 interrupt 등이 이런 priority 를 가지게 됩니다.

일반적인 Thread 들은 위의 priority 를 Base 로 해서 이보다 큰 priority 를 가지게 되며, nice value 에 의해 조정될 수 있고, 실시간으로 scheduler 에 의해 아래의 공식과 같이 유동적으로 변하게 됩니다.

Base Priority : 40Default Nice : 20Thread priority = x_nice + (CPU usage ticks*R/32)*(x_nice+4)/64x_nice = 20 + Base Priority + (2*(Nice-20)), if Nice + Base Priority > 60

= Nice + Base Priority, if Nice + Base Priority <= 60

Thread priority : CPU 를 사용함에 따라 priority 를 낮추어 CPU 를 과도하게 점유하는 것을 막아주는 원리와매초마다 CPU 사용시간을 보정해주어(절반 혹은 설정값에 따라 줄여줍니다) 낮아진 priority 를 재조정해주는 원리.이 두가지 원리에 의해 여러 Thread 들이 적절하게 CPU 를 사용할 수 있게 됩니다.

R/32 CPU-penalty-to-recent-CPU-usage ratioR sched_R = 16 (schedo –a 에서 확인 가능 및 수정 가능)

CPU usage ticks 는 CPU aging/Decay 라는 D 에 의해 시간이 매초 다시 계산됩니다.(만약 D 가 없다면 CPU 를 많이 사용해서 priority 가 낮아진 Thread 는 더 이상 CPU 를 사용하지 못할수 있기 때문입니다.D sechd_D = 16 (schedo –a 에서 확인 가능 및 수정 가능)New CPU usage ticks = current CPU usage ticks * D/32

1. 기본값으로 사용될경우 x_nice 는 60 이 되고, Thread priority 는 처음에는 60 이 됩니다.(CPU usage ticks이 0 이므로)

2. 이 Thread 가 계속 실행중에 있다면, 10ms 에 1 씩 CPU usage ticks 이 증가합니다.3. R 이 16 이므로 20ms 에 priority 에 penalty 1 씩 증가하게 됩니다.4. 1 초가 지나면 총 증가된 penalty 가 50 이 되어 Thread 의 priority 는 110 입니다.5. 이때 swapper 에 의해 CPU usage ticks 가 다시 계산됩니다.

New CPU usage ticks = current CPU usage ticks(=100)*D(=16)/32 = 100*16/32 = 50New priority = 60 + (50*16/32)*1 = 85

즉, CPU 를 사용하면서 낮아지는 priority 를 매초 보정해주어 priority 가 너무 낮아져서 실행이 아예 안되는 상황을 막고, 효과적인 스케쥴링이 될수 있도록 해줍니다.

SCHED_OTHER 가 기본스케쥴링 정책이며 위에서 설명한 방식입니다.

이외에도, SCHED_FIFO(priority 가 높은 Thread 가 들어오기 전까지, 같은 priority 끼리는 FIFO 방식으로 처리, real-time system), SCHED_RR(priority 가 높은 Thread 가 들어오기 전까지, 같은 priority 끼리는 Round Robin 방식으로 처리, priority 는 불변)가 있습니다.

2. %iowait 란?

%iowaitI/O Wait는 CPU의 Idle time 중 하나의 측정값으로 흔히 이 I/O Wait cycles동안은 다른 프로세스에 의해 사용될 수 없다는 일반적인 오해가 있지만, 사실이 아닙니다.

CPU의 증설은 Wait I/O 를 줄이지 못합니다.높은 %io wait는 전통적으로 I/O 성능의 문제를 가르키지만 고성능의 CPU 발전으로 인해 %io wait는 오해의 지표가 될수 있습니다. 왜냐하면 %io wait는 CPU 성능에서의 수치이지 I/O 성능에서의 수치가 아니기 때문입니다. 정확하게 말해서 I/O가 완료되기를 기다리는 idle한 CPU의 시간 백분율을 나타냅니다.이것은 간접적인 I/O 성능과 관련된 사항이기에 (I/O 성능과 관련하여)잘못된 결론이 내려질 수도 있습니다.예로서, 양호한 시스템의 i/o wait가 100%로 나올 수도 있으며, disk 병목현상이 있는 시스템의 %io wait가 0%로 나타날 수도 있습니다.

아래의 자료를 통해 CPU 성능이 향상될 때 왜 I/O WAIT가 증가하게 되는지, 그 이유도 정확히 설명이 됩니다.

I/O 의 성능향상없이 CPU 의 성능이 향상되었을 때, 동일 작업이 수행될 때 I/O WAIT TIME 은 줄어들지 않습니다. 그에 반해 향상된 CPU 로 인하여 이 작업에 의해 소요되는 CPU TIME 은 줄어듭니다. 결국 I/O WAIT 의 백분율이 증가되는 현상이 나타나는 이유입니다.

출처 : http://www.aixtips.com/AIXtip/iowait.htm

The following example illustrates how faster CPU's can increase %iowait. Assume we upgrade a system with CPU's that are 4 times faster. All else remains unchanged. Before the upgrade, a transaction takes 60 ms which includes 40 ms of CPU time plus 20 ms to perform an IO, and that our application performs one transaction after another in a serial stream.

Before 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%

After 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%

ex) 아래의 그림에서 표시된 두서버의 CPU 자원 사용 현황의 차이점은 무엇일까요?(첫번째 시스템은 CPU 사용율이 90%로, 두번째 시스템의 CPU 사용율은 100%입니다.)

첫번째 시스템의 경우 디스크의 사용율이 높은 상태에서 %iowait 가 47%이며, %usr+%sys 가 41.7%입니다. 이 시스템의 경우 실제로는 58.3%의 CPU 는 다른 process 가 사용할 수 있는 상태입니다.

3. SMT 에서의 CPU 성능분석 SMT(Simultaneous MultiThreading)

root@uniDev:[/] smtctl -m onsmtctl: SMT is now enabled and will persist across reboots. Note that the boot image must be remade with the bosboot command before the next reboot.root@uniDev:[/] smtctl

This system is SMT capable.

SMT is currently enabled.

SMT boot mode is set to enabled.SMT threads are bound to the same physical processor.

proc0 has 2 SMT threads.Bind processor 0 is bound with proc0Bind processor 1 is bound with proc0

root@uniDev:[/] lsdev -Ccprocessorproc0 Available 00-00 Processorroot@uniDev:[/] topas

topas 가 실행된 상태에서 c 를 두번 누르면 다음과 같이 나옵니다. (Logical CPU 가 두개임을 확인합니다.)

Topas Monitor for host: uniDev EVENTS/QUEUES FILE/TTYSun May 25 10:52:25 2008 Interval: 2 Cswitch 321 Readch 2248.7K Syscall 3441 Writech 1676CPU User% Kern% Wait% Idle% Reads 592 Rawin 0cpu1 14.1 5.4 0.4 80.1 Writes 4 Ttyout 423cpu0 0.0 0.0 0.0 100.0 Forks 2 Igets 0 Execs 4 Namei 916Network KBPS I-Pack O-Pack KB-In KB-Out Runqueue 1.0 Dirblk 0en0 0.6 3.0 0.5 0.1 0.4 Waitqueue 0.0lo0 0.0 0.0 0.0 0.0 0.0 PAGING MEMORYDisk Busy% KBPS TPS KB-Read KB-Writ Faults 1156 Real,MB 2048hdisk0 1.0 4.0 1.0 0.0 4.0 Steals 0 % Comp 84.0hdisk1 0.0 0.0 0.0 0.0 0.0 PgspIn 0 % Noncomp 15.6hdisk2 0.0 0.0 0.0 0.0 0.0 PgspOut 0 % Client 15.6 PageIn 0Name PID CPU% PgSp Owner PageOut 0 PAGING SPACERMForTAg 782502 0.3 1.2 root Sios 0 Size,MB 4096topas 696398 0.3 1.7 root % Used 39.1db2fmcd 819218 0.1 1.0 root NFS (calls/sec) % Free 60.8vmstat64 1048712 0.1 0.3 root ServerV2 0java 544918 0.0 189.0 wasadm ClientV2 0 Press:getty 463046 0.0 0.4 root ServerV3 0 "h" for helpdb2fmp 303140 0.0 12.8 db2inst1 ClientV3 0 "q" to quit

SMT 환경하에서의 CPU 사용율은 전통적인 CPU 사용율 산출 방식과 다릅니다.전통적인 방식

CPU 가 사용될 때 마다 usr, sys, iowait, idle 인지 확인하여 해당 count 를 늘려줘서 이에 대한 백분율을 나타냅니다. 완전히 logical CPU 가 하나의 물리적인 CPU 라고 가정하여 CPU 사용율을 나타내며, 이에 따라 idle 이 좀더 높게 나옵니다.

SMT 및 Micropartition 환경 purr 이라는 h/w 레지스터를 카운팅하는 방식입니다.

SMT 환경에서는 같은 물리적인 CPU 를 바라보는 logical CPU 중 하나만 작동하더라도 해당 레지스터의 카운터가 올라갑니다. 따라서 다른 logical CPU 가 idle 상태여도 idle 카운트는 올라가지 않습니다. 그러므로 실제로 vmstat, topas 등에서 나타나는 CPU 의 idle 의 상태보다 CPU 는 더 많은 여유가 있을 수 있지만, 이를 수치로 나타내기는 어렵습니다.결국 위를 바탕으로 SMT 가 on 되어 있는 상황에서의 CPU idle 은 단순히 보여주는 수치 이상의 여유를 가지고 있다라는 개념으로 시스템을 모니터링 하여야 합니다.

개인적인 의견으로, 단순히 개념적인 모니터링보다는, purr 에 기반을 둔 모니터링(SMT 환경에서 vmstat, topas 등의 정보)과, 전통적인 방법에서의 모니터링(전통적인 방법으로 CPU 사용양을 산출해낸 정보)이 동시에 이루어 질 때, 좀더 신뢰성 있는 모니터링이 가능하리라 생각됩니다.

4. Tuning(smt_snooze_delay)일반적인 환경에서 CPU와 관련된 시스템적인 면에서의 TUNING 포인트는 거의 없습니다.기본값 그대로 사용하는 것이 가장 좋으며 특별히 변경으로 인한 성능 향상에 대한 보고 조차 거의 없는 것이 현실입니다. 다만 SMT 환경에서는 smt_snooze_delay 이라는 항목이 있어서 소개드립니다.

Snoozing SMT 환경에서 한 Thread 가 Idle 상태로 전환되었을 때(이런 것을 snoozing 이라고 부릅니다.) 이

Thread 가 사용하고 있던 CPU 의 SMT 를 해제시키면, 해당 CPU 를 공유하고 있던 Thread 의 성능은 향상됩니다. 그리고 Thread 가 깨어나면 SMT 가 다시 활성화 됩니다. Thread 가 Idle 로 변했을 때, 이 CPU 의 SMT 를 해제시키기까지의 시간, 즉 delay 가 schedo 에서 지정가능한 smt_snooze_delay 이며 단위는 microsecond 입니다. 기본값은 0 입니다.문제는 아주 짧게 Idle 로 빠졌다가 바로 깨어나는 Thread 에서 발생합니다. SMT 를 on 에서 off 로, 그리고 다시 off 에서 on 으로 바로 전환해야 하기 때문에 오히려 이로 인한 CPU 자원 소모가 커지게 됩니다.아주 짧은 Idle 이 매우 반복적으로 발생하는 software 의 환경이라면 이 기능을 쓰지않거나 smt_snooze_delay 를 0 보다 조금더 늘려줌으로써 성능 향상을 도모할 수 있습니다.-1 로 설정하면 이 기능을 쓰지 않는 것이며, 값을 늘려줄때는 thread 의 Idle 시간이 어느정도인지 판단하여 적절히 설정해줄 필요가 있습니다.

II. VMM (Virtual Memory

Management)

1. Segment 와 메모리 부족

2. svmon 을 이용한 메모리 분석 테스트

3. Tuning

4. free 와 disclaim

5. Paging space

1. Segment 와 메모리 부족

Segment 형태1. Working : Process 에 의해 사용되는 메모리2. Persistent : jfs 를 위한 메모리3. Client : jfs 를 제외한 file 을 처리할 때 사용되는 메모리

Segment 분류 Computational : Working Segments(Program Text(실행프로그램이 실행가능한 형태로

해석되어 메모리로 올라간 상태) 포함) Non-computational : Persistent + Client Segments

1. File cache 에 해당하는 부분입니다.

Working Segment 는 Paging In/out 시에 메모리와 Paging space 사이로 i/o 가 발생합니다. Persistent 와 Client Segment 는 Paging In/Out 시에 메모리와 해당 file system 사이로 i/o 가

발생합니다.

vmstat 에서의 pi/po 는 pgsp i/o 를 나타내지만, nmon 에서의 pi/po 는 filesystem in/out 과 pgsp in/out 을 합한 값입니다.

메모리 부족 AIX 에서의 메모리 부족은 free memory 로만 판단할 수 없습니다.

1. vmstat 에서의 %avm 이 전체 메모리의 80% 이상인 상태에서, 지속적으로 paging space in/out 이 대량이든 소량이든 발생할 경우 메모리 부족으로 판단할 수 있습니다.

2. Comp%의 사용율이 80%이상인 상태에서, 지속적으로 paging space in/out 이 대량이든 소량이든 발생할 경우 메모리 부족으로 판단할 수 있습니다.

3. %avm 이나 Comp%가 60% 보다 작으면서 paging space in/out 이 발생하여 메모리 부족과 같은 현상이 발생할때는 tuning 을 통해서 어느정도까지 해결이 가능합니다.

4. Tuning 의 방법은 이 단원의 3 번 Tuning 권장을 따릅니다.

2. svmon 을 이용한 메모리 분석 테스트메모리 분석 테스트

test 프로그램 실행 후, test 프로그램의 1단계와 2단계 동안 svmon –P “PID” 명령어를 이용하여 프로세스의 메모리를 분석

test.c - 메모리 분석 테스트를 위한 간단한 프로그램. (cc –o test test.c)1 단계 : 처음 실행되자마자 30초간 멈춰있는 상태2 단계 : RMForTAgent라는 파일(파일 크기 48181Bytes)을 열어서 48181Bytes 만큼 메모리를 할당하여, 이 메모리 버퍼에 RMForTAgent파일을 읽어들이고 다시 일정시간동안 멈춰있는 상태

test.croot@uniSvr3:[/usr/share/ontune] cat test.c#include <stdio.h>

void main(void){ FILE *f; char *p;

sleep(30); 1 단계 printf("open\n"); f = fopen("./RMForTAgent", "r"); p = (char*)malloc(48181); fread(p, 1, 48181, f); sleep(600); 2 단계 fclose(f); free(p);}

테스트 결과1 단계root@uniSvr3:[/usr/share/ontune] svmon -P 1085652

------------------------------------------------------------------------------- Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 16MB 1085652 test 17700 5912 0 17698 N N N

Vsid Esid Type Description PSize Inuse Pin Pgsp Virtual 0 0 work kernel segment s 10260 5908 0 10260

기본적으로 프로그램 실행을 위해 필요한 커널 부분(System SG) eb09d d work shared library text s 7418 0 0 7418

프로그램 실행을 위해 필요한 library 부분(shared SG) d7a3e 2 work process private s 16 4 0 16

프로그램 실행을 위해 사용된 메모리로, 변수나 상수 및 mem alloc에 할당된 메모리 (Exclusive SG) cc23b f work shared library data s 4 0 0 4

프로그램실행을 위해 사용된 메모리로, 호출된 함수의 코드등에 대한 부분(Exclusive SG) 97a56 1 clnt code,/dev/hd2:225309 s 2 0 - -

test 실행 파일 자체가 메모리에 읽어짐(Exclusive SG) test 프로그램 파일 크기 : 6210 -> 2pages

2 단계root@uniSvr3:[/usr/share/ontune] svmon -P 1085652

------------------------------------------------------------------------------- Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd 16MB 1085652 test 17732 5912 0 17718 N N N

Vsid Esid Type Description PSize Inuse Pin Pgsp Virtual 0 0 work kernel segment s 10257 5908 0 10257 eb09d d work shared library text s 7418 0 0 7418 d7a3e 2 work process private s 29 4 0 29

malloc에 의해 48181B(13Pages)가 늘어난 것이 반영된 모습(Exclusive SG) cc23b f work shared library data s 14 0 0 14

프로그램실행을 위해 추가로 호출된 printf, fopen, malloc, fread 함수의 코드를 불러오기 위해 사용된 메모리(Exclusive SG)

9add0 - clnt /dev/hd2:225311 s 12 0 - - fopen 및 fread에 의해 읽혀진 RMForTAgent 파일이 메모리에 올라간 상태(Exclusive

SG) RMForTAgent 파일 크기 : 48181 -> 12Pages

97a56 1 clnt code,/dev/hd2:225309 s 2 0 - - test 실행 파일 자체가 메모리에 읽어짐(Exclusive SG) test 프로그램 파일 크기 : 6210 -> 2pages

① 빨간색 항목은 프로그램내부에서 동적 메모리 할당이나 함수호출 등에 의해 사용되는 메모리가 어떻게 늘어나는지 확인 할 수 있는 부분입니다.

② 파란색 항목은 Non-computational 부분으로 file-cache로 사용된 부분입니다.③ file-cache로 사용된 부분에서 file system type이 jfs라면 이 항목은 persistent 영역이 되고, jfs2

라면 client 역역이 됩니다.④ Non-comp로 사용된 부분은 해당 process가 종료되어도 memory에서 clear되지 않습니다. 이는

순수하게 cache로서의 의미를 가지는 것으로 다른 어떤 프로세스가 해당 file을 재사용할 가능성이 있다는 것이며 재사용될 때의 성능 향상을 위함입니다. memory에서 의도적으로 clear 시키는 방법은 없으며, lrud에 의해 자연스럽게 clear되거나 file이 삭제될 때 clear 됩니다.

⑤ 경우에 따라서 사용하는 process가 없는 상태의 file cache영역이 과도하게 물리적인 메모리를 점유하는 현상이 나타날수 있습니다. 3번과 4번 항목에 의해 AIX의 메모리 사용율이 항상 100% 가까이 나타나게 됩니다.

* svmon에서의 Segment의 종류 System : OS의 커널부분에 의해 사용

Exclusive : 해당 유저의 프로세스들간에 공유되는 메모리 Shared : 시스템 전체 프로세스들간에 공유되는 메모리

Ex) 아래 그림에서 노란 박스안은 여러 서버들의 메모리 상태입니다.파란색이나 주황, 빨간색은 comp영역의 사용량이며, 회색은 file cache 사용량입니다.이처럼 의외로 많은 file cache 영역의 사용으로 실제 메모리 여유가 없어 보일 수 있습니다.그렇기 때문에 정확한 모니터링 및 분석을 통해 메모리 부족 여부를 판단하여야 합니다.

3. Tuning numperm, numclient, minperm, maxperm, maxclient, strict_maxclient, strict_maxperm,

minfree, maxfree

Persistent 와 Client Pages numperm : non-computational 영역에서 사용중인 물리적인 메모리의 백분율 numclient : Client 영역으로 사용중인 물리적인 메모리의 백분율( = “numperm” – “jfs

사용율”)svmon (-G)을 통해서 확인 가능

예) 단위는 page(4096Bytes)root@uniSvr3:[/usr/share/ontune] svmon size inuse free pin virtualmemory 2097152 1524622 572530 422583 854795pg space 2097152 4305

work pers clntpin 422583 0 0in use 854795 0 669827

numperm = inuse of (pers + clnt) * 100 / size of memory = (0+669827) * 100 / 2097152

numclient = inuse of clnt * 100 / size of memory = 669827 * 100 / 2097152 = 31% inuse : 물리적인 메모리에서 사용중인 page 수 pin : inuse 중에서 paging space out 이 되지 못하도록 설정된 page 수(중요한 커널 메모리는

자동으로 pinned 되지만, 사용자에 의해 의도적으로 pinned 될수 있습니다. 예 – Oracle 의 PGA, SGA)

Non-computational 영역에 대한 Thresholds (minperm, maxperm, maxclient) minperm : numperm 이 이 값보다 작을때는 lru 알고리즘이 comp 와 non-comp 에 무작위로 발생 minperm~maxperm : numperm 이 이 값 사이에 있을때는 가급적 lru 알고리즘이 non-comp 에

발생 maxperm : numperm 이 이 값보다 클때에는 lru 알고리즘이 non-comp 를 우선 대상으로 설정,

하지만 전체적인 메모리 요구량에 따라 lru 가 comp 에 발생할 수 있으며, 이로 인해 numperm 이 maxperm 이상으로 상승할 수 있음

권장값 – minperm : 10~40, maxperm : 20~60 (lru_file_repage 가 0 일때는 기본값 사용해도 무방) or maxperm : 100 – %avm - 10% (avm : vmstat 에서의 active virtual memory 로, 실제 메모리 뿐 아니라 가상 메모리까지 포함한 Comp 영역의 값을 뜻함. 즉 전체 물리적 메모리에서 현재의 avm 과 Comp 를 위한 추가 여유분 10%를 제외한 크기를 file cache 로 준다라는 의미임)

기본값 – minperm : 20, maxperm : 80 maxclient : maxperm 과 같은 의미에서 numclient 를 적용 maxclient 는 무조건 minperm 보다 커야하고 maxperm 보다 작아야 합니다. 이 때문에 minperm, maxperm, maxclient 변경시 항상

minperm 을 먼저 변경하고, 그다음에 maxclient 를 변경하고 마지막으로 maxperm 을 변경해야 합니다.

Non-computational 영역에 대한 제한 (strict_maxclient, strict_maxperm) strict_maxclient : 기본값 1 1 일때 numclient 의 hard-limit 이 설정된 것으로 절대로 numclient

가 maxclient 보다 커질수 없습니다. strict_maxperm : 기본값은 0 1 일때 numperm 의 hard-limit 이 설정된 것으로 절대로 numperm

이 maxperm 보다 커질수 없습니다. 가급적 0 으로 둘것을 권장합니다. 특히 jfs2 사용자는 불필요한 i/o 발생이 많아 질 수 있기 때문에 0 으로 설정하시기 바랍니다.

여유 메모리에 대한 Thresholds minfree : 물리적인 메모리의 여유공간이 page 단위로 이값보다 작게 되면 lru 알고리즘이 작동

maxfree : lru 알고리즘이 작동하면서 여유 page 수가 이 값보다 커지면 lru 알고리즘 작동 정지 권장값 – minfree : cpu 수 * 120, maxfree : minfree + cpu 수*maxpgahead(or

j2_maxPageReadAhead)기본적으로 cpu 당 하나의 프로세스가 실행되는 구조를 감안하여, 현재 실행 중인 프로세스의 수가 cpu의 수라고 가정하고 각각 프로세스에 최소한의 여유 메모리를 확보한다는 개념

기본값 : AIX 5.3 이상 minfree : 960, maxfree : 10885.2 이하 minfree : 120 or 128, maxfree : 128

4. free 와 disclaim

free malloc등 동적으로 메모리를 할당 받은 후 이 메모리를 해제할 때 사용하는 system call 입니다. 동적으로 할당 받은 메모리를 free시켜주지 않으면서 추가적으로 메모리를 계속 할당 받을 때

memory leak이 발생합니다. free가 호출되었을 때 커널는 해당 메모리를 해제는 하지만 OS에 반환하지는 않습니다. 이 프로그램이 또다시 메모리 할당을 요구할 때 OS에 새롭게 메모리를 할당받아주는것보다 free된 메모리를 재할당하는 것이 훨씬 빠르기 때문입니다. 이것은 memory leak과는 완전히 다른것으로 이로인한 memory leak은 없습니다.

free만 호출되었을 때 프로세스가 사용하고 있는 메모리는 줄어들지 않습니다. 다만 이 상태에서 새롭게 메모리 할당을 요청할 경우 추가로 필요한 메모리 크기만큼만 늘어나게 됩니다.

disclaim free된 메모리를 OS에 완전히 반환해주는 system call입니다. disclaim이 호출된 후 프로세스의 메모리 사용양은 해제된 만큼 바로 줄어듭니다. OS에 반환하는데 CPU 자원이 추가도 더 소비됩니다. MALLOCDISCLAIM=true 로 설정된 경우 disclaim이 호출되지 않고 free만 호출하여도 OS에 메모리를 바로 반환합니다.

MALLOCDISCLAIM 은 설정된 세션에만 유효하며 한번 설정하면 해제가 안되기 때문에 새로 로그인을 해야합니다.

테스트 프로그램 mem_test.c (cc –o mem_test mem_test.c)#include <stdio.h>#include <sys/shm.h>

void main(void){ char *p; int i;

p = (char*)calloc(1, 10*1048576); sleep(2); free(p); free(p)가 호출되어도 이 프로세스의 메모리 사용율은 줄어들지 않습니다. printf("free\n"); sleep(2); disclaim(p, 10*1048576, ZERO_MEM); disclaim이 호출된 이후 메모리 사용율이 줄어듭니다. printf("disclaim\n"); sleep(2); for(i=0;i<100;i++) { p = (char*)malloc(1048576); memset(p, 0, 1048576); printf("%d\n", i); sleep(1);

free(p); free(p)의 호출을 막으면 메모리가 계속 증가함을 확인할 수 있습니다. }} 위 테스트 프로그램에서 빨간색 라인으로 된 두줄을 지우고 새로 컴파일하여 실행하면, 위 프로그램은 10MB메모리를 계속 가지고 있는중에 파란색 라인에서 10 을 찍으면서 1MB 씩 프로그램의 메모리 사용양이 증가함을 확인할수 있습니다.이것은 memory leak 의 예를 나타내는 것이지만, 또한 free 된 메모리를 OS 에 바로 반환하지 않고 추가의 메모리 요청에 의해 빠르게 재사용되는 것에 대한 예이기도 합니다.

5. Paging space 할당방식

Early Paging Space Allocation (EPSA) Late Paging Space Allocation (LPSA) Deferred Paging Space Allocation (DPSA, AIX4.3.2 이후부터 등장)

이 값들은 PSALLOC 이라는 시스템 환경변수와 vmtune(또는 vmo)에 의해 변경될 수 있습니다.

Early Paging Space Allocation

프로세스가 메모리 사용할때 pagign space에도 이 메모리와 같은 크기의 paging 공간을 미리 예약해두는 방식입니다. 그래서 실제로 paging space out이 발생할 때 이 예약된 공간을 빠르게 바로 사용할 수 있습니다.그러나 만약 미리 예약할 때 paging space에 이 예약할 공간이 부족하면, 프로세스에 메모리를 할당해주는 것 자체가 실패하게 되어 프로세스의 정상 작동이 어렵게 될수 있습니다.이런 이유로 빈 페이징 스페이스 블록이 페이징 스페이스 kill 레벨보다 적어 SIGKILL에 의해 해당 프로세스가 kill 되는 경우를 미리 막을 수 있게 됩니다.이 방식에서는 커널이 paging space 예약등을 해야하기 때문에 보통 CPU 자원(%Sys)의 사용율이 조금더 높아집니다.

Late Paging Space Allocation

AIX4.3.2 이전에는 시스템 기본으로 사용되던 방식입니다. Early Paging Space Allocation과는 달리 프로세스가 먼저 메모리를 할당 받은 후 나중에(“Late”) 메모리의 페이지들이 프로세스에 의해 실제 사용될(touch) 때에 사용되는 양 만큼만 paging space가 할당됩니다. 프로그램에 따라서는 큰 양의 paging space를 할당 받은 후 그 중 일부만 사용하여 paging space의 낭비를 가져올 수도 있으므로 이 방식으로 Early Paging Space Allocation 보다는 paging space 공간을 절약 할 수 있습니다.

Deferred Paging Space Allocation

AIX 4.3.2 부터 새로 소개된 방식으로 Late Paging Space Allocation 방식이 변경된 것입니다. AIX4.3.3 이후부터는 시스템 기본 페이징 스페이스 할당방식입니다. Late Paging Space Allocation과 달리 Deferred Paging Space Allocation은 실제 메모리에 있던 페이지가 pagingspace out이 일어나야 하는 경우에 비로소 paging space가 할당되는 방식입니다.Late Paging Space Allocation 방식에도 early 방식과 같이 결국은 큰 양의 paging space가 할당된 뒤 pagingspace out이 발생하지 않아서 실제로 전혀 사용되지 않는 경우가 있을 수 있습니다. 이런 경우에는 paging space의 공간 낭비 및 paging space 할당을 위한 CPU 자원 소모 또한 발생될 수 있습니다.Deferred Paging Space Allocation 방식은 이런 비효율성도 제거가 된 방식입니다.한번 메모리 페이지가 paging space에 page out 되면 이 paging space은 그 페이지가 다시 메모리로 page back 한다 하더라도 해당 프로세스를 위해 해제되지 않습니다. 이런 상황이 되면, paging space 사용율(lsps –s)보다 실제 paging space에 올라가 있는 페이지의 양(lsps –a)이 더 커지는 결과를 낳게 됩니다. 해당 프로세스가 종료되는 시점에서나 paging space의 공간까지 해제가 되는 것입니다.따라서 lsps –a 등의 명령어로 나타나는 페이징 스페이스 사용율은 시스템 부팅 이후에 페이징 스페이스가 가장 많이 사용되었을 때의 값을 나타내는 것입니다.여기서 중요한 부분중에 하나가 paging space에서 처리할 수 있는 공간보다 더 많은 공간이 가상 메모리로 할당이 될 수 있는 것입니다. 만약 이렇게 paging space에서 처리할 수 있는 공간보다 더 많은 공간이 가상 메모리로 할당된 상황에서 대량의 paging space out이 발생할 때 paging space 의 공간이 부족한 상황이 될 수 있습니다.

vmtune –d (1 또는 0)으로 deferred paging space allocation 방식을 on/off 할 수 있다.(vmo –o defps)

페이징 스페이스 할당방식의 변경 early방식으로 변경하기페이징 스페이스 할당방식을 Early 할당으로 바꾸기 위해서는 PSALLOC 환경변수를 아래와 같은 방법으로 변경해 주면 되며 변경 후에는 이미 실행되고 있던 프로세스를 제외한 새로운 프로세스들은 Early

할당방식을 적용 받게 됩니다.1. # export PSALLOC=early : 현재의 쉘에서 새로운 프로세스들은 early 할당방식을 적용 받습니다.2. .cshrc 나 .kshrc에 export PSALLOC=early 를 등록 : 이렇게 등록된 사용자로 새롭게 로그인된

세션의 프로세스들은 early 할당방식을 적용 받습니다.3. /etc/environment 파일에 PSALLOC=early 를 등록 : 현재 시스템의 모든 새로운 프로세스(Pid 1의

init 프로세스는 제외)들은 early 할당방식을 적용 받습니다.

Late 방식으로 변경하기vmo –o defps=0

Defer 방식으로 변경하기기본값이 Defer 방식이며, vmo –o defps=1 입니다. 또한 PSALLOC이 NULL 값이어야 합니다.(PSALLOC=””)

III. LVM (Logical Volume Manager)

1. LVM policy

2. Mirro Write Consistency

3. 기타 특성

4. ramdisk

5. Monitoring

6. 성능 측정

1. LVM policy Inter-Disk Policy

LV의 partition들이 Disk 간에 어떻게 분포할지를 결정 Maximum : 가능한 많은 디스크에 걸쳐서 partition들이 분포. 여러 디스크에 걸쳐지므로

성능향상을 기대할 수 있지만, 이들 디스크에 문제 발생시 LV가 못쓰게 되므로 가용성은 떨어집니다.

Minimum : 가능한 적은 디스크에 걸쳐서 partition들이 분포. 적은 디스크에 걸쳐 있으므로 디스크의 문제 발생에 좀더 강하지만 여러 디스크에 걸쳐진 성능 이점은 없습니다.

Intra-Disk Policy LV의 partition들이 해당 Disk 안에 어떻게 분포할지를 결정

디스크 축을 중심으로 inner edge -> inner middle -> center -> outer middle -> outer edge 순으로 outer edge의 디스크 회전에 대한 속도가 가장 높아서 성능 또한 가장 좋습니다. 하지만 단순히 디스크 회전 속도 뿐만 아니라 디스크 arm이 움직이는 시간이 있어서, 디스크 arm이 center로 움직이는 것이 확률상 빠릅니다. 디스크 회전 속도와 arm의 움직임움 고려했을 때 실제로 center에서 outer edge 사이 성능을 비슷하게 고려하시면 됩니다.

2. Mirror Write Consistency Active MWC

해당 LV Copy 모두 write가 완료되는 것이 확인될 때 write operation이 완료됩니다. 장애 이후 빠르게 바로 사용할 수 있습니다. 전체적인 write 성능저하가 있습니다. LV 추가시 기본 설정값입니다.

Passive MWC Big Volume Group에서만 사용가능합니다. MWC-off 처럼 write 성능저하가 없습니다. 장애 이후 lv가 사용될 때 read-then-sync 의 형태로 동작하기 때문에 read의 성능저하가

발생합니다.( stale이 발생된 부분이 read 하면서 복구되기 때문에 read가 느려집니다.)

3. 기타 특성 Allocate each logical partition copy on a SEPARATE physical volume

Mirroring 시 각각의 copy가 서로 다른 물리 디스크에 위치하도록 하는 옵션 Yes : 서로 다른 물리 디스크에 위치시킵니다. No : 위의 사항을 지키지 않습니다. Superstrict : mirror된 다른 copy의 partition이 위치한 디스크에는 절대로 partition을 생성하지 않는

옵션입니다. 기본값은 yes입니다.

RELOCATE the logical volume during reorganization Reorgvg 등의 명령어시 재배치를 시킬지 안시킬지를 지정하는 옵션입니다. 기본값은 yes 입니다.

Wite verify Write 명령 수행후 read 명령을 내려 write 가 정상 종료되었는지 다시한번 확인하는 옵션입니다. 가용성은 높아지지만, 성능 저하가 발생합니다. 기본값은 no 입니다.

Serialize io Overlapping 되는 io 를 한번에 처리하지 않고 개별적으로 처리하도록 하는 옵션입니다. Io 를 사용하게 되는 대부분의 application 들은 io 요청들이 개별적이기 때문에 이 옵션을 no 로 하셔야

합니다.

4. ramdisk 메모리를 디스크처럼 filesystem 으로 mount 하여 사용합니다.

Physical memory 2GB 를 /ram_mount 로 mount 하는 예입니다.

# mkramdisk -u 2000M (혹은 mkramdisk –u 2G) -u 옵션은 pinned 시키지 못하도록 합니다.# ls -l /dev | grep ram 만들어진 ramdiskX 를 확인합니다.# mkfs -V jfs /dev/ramdiskX ramdiskX 로 filesystem 을 만듭니다.# mkdir /ram_mount mount 할 디렉토리를 만듭니다. # mount -V jfs -o nointegrity /dev/ramdiskX /ram_mount mount 합니다.

jfs2 로 사용하시려면 jfs2 가 nointegrity 를 지원하지 않기 때문에 방법이 조금 달라집니다.# /sbin/helpers/jfs2/mkfs -V jfs2 -o log=INLINE /dev/ramdiskX# mkdir /ram_mount# mount -V jfs2 -o log=/dev/ramdiskX /dev/ramdiskX /ram_mount

5. Monitoring iostat

iostat –a [diskes…] [Interval [Count]] -a 옵션 : 아답터의 처리량 표시 [diskes…] : 지정된 디스크만 표시

sar sar –d Interval [Count] 일반적으로 CPU를 볼 때 사용하지만, -d 옵션을 사용하면 block device(디스크) 처리량을 표시

filemon filemon –O {lf,vm,lv,pv|all} –o “저장할 파일명” -O 옵션 뒤에 원하는 항목을 지정하는데, “,”를 이용하여 복수 지정 가능합니다. 이때 띄어쓰기를 하면

안됩니다. lf : file, vm : virtual memory, lv : Logical Volume, pv, Physical Volume, all : lf, vm, lv & pv

filemon은 trace가 background로 호출됩니다. 원하는 관찰 시간이 지난후 “trcstop” 명령을 내리시면 –o로 지정한 파일로 결과를 저장시켜 줍니다.

lvmstat lvmstat은 먼저 해당 장치에 lvmstat을 enable시킨후 사용하여야 합니다. lvmstat –l LVName –e

혹은 lvmstat –v VGName –e lvmstat {-l LVName| -v VGName} Interval [Count]

ex) hdisk0(rootvg)에서 과도한 busy혹은 io가 관찰되었을 때, 어떻게 파악할까요?1. lvmstat –v rootvg –e lvmstat을 enable 시킵니다.2. lvmstat –v rootvg 2 100000 2초 주기로 rootvg의 io를 관찰합니다. 이때 io가 없으면

보여주는 값이없으며, io가 발생할 때 해당 lv별 수치가 나옵니다.3. 관찰된 lv중에 높은 수치가 나오는 lv를 확인합니다.4. lv가 mount되어 있고, 어떤 file에 io가 집중되는지 확인할때는 filemon을 이용해야 합니다.

A. filemon –O lf –o fmon.out이라는 명령어를 내립니다.B. 적절한 시점에 trcstop 명령어를 이용하여 filemon을 종료시키면, fmon.out이라는 결과 파일이 생성 됩니다.

C. fmon.out 파일을 열어서 4번 에서 관찰된 lv가 마운트 되어있는 filesystem으로 검색하여 어떤 파일들의 io 가 높은지 확인합니다.

filemon의 경우는 trace가 동작하므로 간편하게 사용하기가 어렵습니다.lvmstat이 간편하고 빠르게 사용할 수 있으므로 먼저 lvmstat을 이용하고 좀더 깊이 파악해야 할 때 filemon을 이용하시는 것이 편리합니다.

6. 성능 측정 dd 명령어를 내리면서 iostat, lvmstat, sar, topas 등을 이용합니다.

hdisk0의 읽기속도 (hdisk0가 아닌 rhdisk0를 사용하여야 합니다) dd if=/dev/rhdisk0 of=/dev/null bs=1024k count=100000

hdisk0의 쓰기속도 (직접적인 측정은 어렵고 filesystem을 이용해야 합니다. 결국 raw device의 쓰기 속도가 아닌 filesystem의 쓰기 속도가 됩니다. 다만 테스트용으로 lv를 만들어서 of=/dev/rTestLV 식으로 보실 수 있습니다)

dd if=/dev/zero of=/testfs/testfile bs=1024k count=200; sync; sync;(sync : filesystem buffer에만 쓰기가 되어 있을수 있기에 syncd가 돌아가도록 합니다.)

hdisk0에 /testfs filesystem을 만들고 여기에 testfile이라는 파일을 200메가(bs 1024K * Count 200 = 200MB)크기로 생성하면서 속도 측정을 하는 것입니다.

lv00의 읽기속도 (lv00이 아닌 rlv00를 사용하여야 합니다) dd if=/dev/rlv00 of=/dev/null bs=1024k count=100000

/testfs filesystem 의 읽기속도 (/testfs 에 file1이라는 200MB 파일이 있다고 가정하면) dd if=/testfs/file1 of=/dev/null bs=1024k count=200

IV. Network

1. 성능측정

2. Tuning

3. Socket Close 절차

4. NFS

1. 성능 측정 ftp를 이용한 성능 측정

ftp가 접속된 상태에서 다음과 같은 명령을 실행하면서, topas를 이용하여 측정합니다.ftp> put “| dd if=/dev/zero bs=32k count=1000” /dev/null

파일을 ftp 로 전송하며 측정하는 것은 디스크의 read 밑 write 속도의 영향을 받기 때문에 정확한 측정이 되지 않습니다.

2. Tuning no 를 통한 시스템 tuning

Speed MTU tcp_sendspace

tcp_recvspace

udp_sendspace

udp_recvspace

rfc1323

10Mb 1500 16384 16384 16384 163840 0100Mb 1500 16384 16384 16384 163840 0

GB 1500 131072 65536 65536 655360 1

1. thewallNetwork 을 위해 사용하게 될 Physical Memory 의 양. Kilobyte 사용자가 변경할 수 없는 값.64 bit kernel 에서는 전체 Physical memory 의 1/2 이나 64GB 중 작은 값

32 bit kernel 에서는 전체 Physical memory 의 1/2 이나 1GB 중 작은 값

2. sb_maxTCP 와 UDP socket 통신에 사용하게 될 maxmium buffer size. thewall 보다 클 수 없음.Default : 1048576 ByteRange : 1 ~ Minimum(thewall, MAXINT=1073741823)권장값 : tcp_sendspace, tcp_recvspace, udp_sendspace, udp_recvspace 중 최대값의 두배 이상

3. tcp_sendspacetcp socket 통신에서 data send 를 위해 사용하게 되는 socket buffer size. sb_max 한도 내에서 사용 가능하며, Gigabit 망과 같은 고속의 Network 에서는 65536 이상의 값을 줄 때 최고의 성능을 기대할 수 있음

Default : 16384 ByteRange : 4096 ~ 1048576권장값 : 상단 table 참조

4. tcp_recvspacetcp socket 통신에서 data receive 를 위해 사용하게 되는 socket buffer size. sb_max 한도 내에서 사용 가능하며, Gigabit 망과 같은 고속의 Network 에서는 65536 이상의 값을 줄 때 최고의 성능을 기대할 수 있음

Default : 16384 ByteRange : 4096 ~ 1048576권장값 : 상단 table 참조

5. ucp_sendspaceucp socket 통신에서 data send 를 위해 사용하게 되는 socket buffer size. sb_max 한도 내에서 사용 가능하며, 그 값은 4096 의 배수로 맞춰주는 것이 좋음.Default : 9216 ByteRange : 4096 ~ 1048576권장값 : 상단 table 참조(특히 Oracle 10g 에서 DB_BLOCK_SIZE * DB_MULTIBLOCK_READ_COUNT)+4KB)

6. ucp_recvspaceucp socket 통신에서 data receive 를 위해 사용하게 되는 socket buffer size. sb_max 한도 내에서 사용 가능하며, 그 값은 4096 의 배수로 맞춰주는 것이 좋음.Default : 42080 ByteRange : 4096 ~ 1048576권장값 : 상단 table 참조(특히 Oracle 10g 에서 udp_sendspace 의 10배)

7. tcp_mssdfltNetwork 간 통신에서 사용 하게 되는 segment 의 maxmium size. 이 값은 path MTU discovery 가 disable 이거나 fail 이 발생하였을 때 만 사용됨

Default : 512byte, Range : 1 ~ 1460byte8. rfc1323

RFC1323 에 의한 window scaling 과 timestamp 를 활성화 시키는 옵션. Gigabit Network 과 같은 고속의 Network상에서는 이것을 활성화 시켜주는 것으로 성능 향상기대 가능.Default : off권장값 : 기가환경에서는 1

9. tcp_nagle_limitNagle 알고리즘에 대한 값. 1 일 때 알고리즘을 사용하지 않음

Nagle 알고리즘 : 전송요청이 있을 때 바로 보내기보다 모아서 한꺼번에 전송하면 성능이 높게 나온다는 것을 이용한 알고리즘으로 1 일경우 버퍼에 쌓아두지 않고 바로 전송하게 됩니다. 이로인해 응답속도는 빠리지만, 전송성능은 떨어질수 있습니다.

Default : 65535

3. Socket Close 절차 (by kwk@kr.ibm.com)

TCP 의 connection closing 은 half-close 라고 불립니다. close() 메소드를 호출하면,실질적인 연결이 양측 모두에서 정말 close 되는 것이 아니라, "앞으로 더이상 해당 connection 을 통해서는 DATA 를 보내지 않겠다"는 표식을 달아두는 것에 지나지 않습니다. 즉, 여전히 DATA 를 받을 수 있습니다.

아래의 그림을 예로 들면,host A 에서 먼저 close() 메소드를 호출한다고 가정합니다.

host A host B| |

ESTABLISHED ESTABLISHED| |close() || FIN_ACK ||---------------------------------->|FIN_WAIT_1 CLOSE_WAIT| || ACK ||<---------------------------------|FIN_WAIT_2 |. .. .. .| (DATA) | 이 단계에서는 DATA 를 보낼 수도 있고, 그렇지 않을|<----------------------------------| 수도 있습니다.| |. .. .. . 일정한 시간동안 host A 가 host B 로부터 FIN_ACK 를 받지TIME_WAIT . 못할 경우, host A 의 FIN_WAIT_2 상태가 TIME_WAIT 으로. . 변합니다. . . 따라서, 아래처럼 host B 에서도 반드시 close()가 불려져야. . 합니다.. close()| || FIN_ACK ||<-----------------------------------|| LAST_ACK || ACK ||----------------------------------->|(CLOSEED) (CLOSED)

먼저 host A 에서의 응용어플리케이션이 close()를 메소드를 호출하게 되면(client.close() )TCP 레벨에서는 FIN_ACK(FINish ACKnowledgement) segment 를 host B 로 보내면서, host A 의 TCP 상태는 FIN_WAIT_1 상태가 됩니다. host B 는 ESTABLISHED 상태에서, host A 로부터 날아온 FIN_ACK segment 를 받으면 자신의 상태를 CLOSE_WAIT 으로 만들면서, 응답을 위한 ACK 를 보냅니다.host B 로 부터 날아온 응답 ACK 를 host A 가 받으면, FIN_WAIT_1 상태가 FIN_WAIT_2 상태로 변하게 됩니다.

이제 여기서부터가 중요한데, 이 상태에서도, host A 의 Input Stream 에서는 Host B 로부터 추가로 날아오는 데이타를 받아 들일 수 있습니다.(보낼 수는 없지만.)만약 이 상태(host A 는 FIN_WAIT_2, host B 는 CLOSE_WAIT 상태)에서 host B 에서의 응용어플리케이션이 명시적으로 close() 메소드를 호출하지 않고 아무런 Action 도 취하지 않게 되면, 일정한 시간동안 이 상태가 그대로 유지가 됩니다. 일정한 시간이 경과하면, host A 의 상태는 TIME_WAIT 상태로 넘어가게 되고, 또다시 일정한 시간이 경과하면 비로소 사라지게 (CLOSED) 됩니다.host B 에서도 유사한 현상이 일어납니다. CLOSE_WAIT 상태가 일정한 시간이 경과하여야만 비로소 사라지게 됩니다.

만약, host A 에서의 응용어플리케이션이 close() 메소드를 호출하여 날아온 FIN_ACK 를 host B 가 받고 TCP 레벨에서는 곧바로 응답 ACK 를 host A 로 보내 주었으며, 그래서 현재 host B 의 상태가 CLOSE_WAIT 상태에 있는데, 여기서 host B 의 응용어플리케이션 내에서 이 상황을 알아차리고 곧바로 close() 메소드를 날리면, TCP 레벨에서는 host B 에서 host A 로 FIN_ACK 를 역으로 보내게 됩니다. 이때 host B 의 TCP 상태는 LAST_ACK 상태, 즉, host A 로 부터 마지막 응답 ACK 를 기다리게 되는 것이지요.Host A 는 이제, host B 로부터 날아오는 FIN_ACK 에 대해 응답 ACK 를 보내고 자신의 상태는 완전히 사라진(CLOSED) 상태가 됩니다.host B 의 경우 역시 host A 로 부터 날아온 ACK 를 받고 나서야 LAST_ACK 상태가 비로소 완전히 사라지게(CLOSED) 되는 것이지요.

이처럼, TCP connection 을 연결하기 위해서는 3회의 SYN,SYN,ACK segment 가 오고가게 되며, 반면 connection 을 "closing"하기 위해서는 FIN_ACK, ACK segment 를 서로 양측이 주고 받게 됩니다.특히, 한쪽에서만 close() 한다고 하여 실질적으로 TCP연결이 closing 되는 것이 아니라 상대편 역시 명시적인 close() 메소드가 호출되어 FIN_ACK 를 양측 모두가 주고 받아야만이 비로소 완전한 단절(CLOSED)이 이루어 지게 됩니다. 그래서 TCP 의 close 는 half-close 라고 불립니다.

4. NFSnfs 는 무조건 udp 라고 말하는 경향이 있는데 aix 4.3 이후는 디폴트 값은 tcp 이고 이것이 실패하면, udp 로 넘어갑니다.또 udp 는 패킷유실이 발생할 수 있는데 nfs 단에서 패킷을 판단해 서버에 재전송을 요청하게 되는데 대량으로 재전송을 요청하게 되어 이런경우는 tcp(tcp 는 유실된 패킷만 재전송요청(nfs 단이 아니라 tcp 단에서)하므로)보다 성능이 저하됩니다. 하지만 이런 경우가 아니라면 대게 udp 가 무조건 성능이 좋다고 봅니다.

/etc/filesystems 에서 options=noacl 로 맞춰주면 성능 향상이 있어요....(default 가 noacl 입니다.)nfs_socketsizeUDP socket 의 사이즈. 기본값이 60000 이며 sb_max 가 최대값packet drop(due to full socket buffers for UDP socket)이 발생하면 이 값을 증가시킵니다.biod 나 nfsd 도 같이 적당히 늘려주면 좋습니다.

===============================================================NFS Performance 향상을 위한 방법

(-p 옵션이 없을 경우 no 와 nfso 를 이용하여 바뀌는 설정값은 재부팅하면 사라집니다. 계속적인 적용을 원할때는 /etc/rc.nfs 를 이용합니다.)

(nfsd 의 경우 # chnfs -n "nfsd count")(boid 의 경우 mount 할때, -o biods=”biod count”를 이용합니다.)1. 서버측에서는 udp 패킷이 drop 되면서 성능저하가 일어나는것이 대다수입니다.이 패킷 drop 의 발생은 대게 큰사이즈나 높은 트래픽 이 두가지중 하나가 됩니다.큰사이즈에 의한 경우는 nfsd 의 수를 늘려줌으로써 효과를 볼수 있으며 높은 트래픽의 경우 socket 의 사이즈를 더 크게 잡아주는 해결책 밖에 없습니다.nfsd 의 수를 바꾸게 되면 자동으로 데몬을 멈춘후 적용시키고 다시 데몬을 재기동시킵니다.socket 의 사이즈를 크게하는 것은 메모리를 더 쓰게되는 것을 기억해야 합니다.socket 의 사이즈는 nfso -a 에서 nfs_socketsize, nfs_tcp_socketsize 항목을 보면 됩니다.이때 이 사이즈는 no -a 에서의 sb_max(기본값은 1048576Byte)보다 작은 값으로 되어야만 합니다.

2. 클라이언트에서는 biod 의 수를 늘려주고 서버측에서는 nfsd 의 수를 늘려줍니다. 그러면 동시에 처리되는 read/write 요청의 수가 늘어나게 됩니다.(nfs V2 : 6, nfs V3 : 4 가 기본값)물론 서버쪽에서 클라이언트의 요청에 대한 처리가 얼마나 원활히 이루어지고 있는지를 점검한 후 조정이 필요합니다.- 판단방법서버쪽에서 vmstat 과 iostat 을 이용하여 서버의 상태를 점검합니다.netstat -p udp 에서 udp(udp 일경우)에서의 socket buffer overflows 항목을 살펴봅니다.이 항목이 증가하지 않고 vmstat 과 iostat 의 상태가 양호하면 system 이 여유가 있으므로 biod 와 nfsd 를 증가시킵니다.증가시킨후 만약 nfsstat -s 에서 nullrecv 항목이 증가한다면 nfsd 가 너무 큰 경우입니다. 대게 이 경우는 상대편에서 많은 요청이 일어나지 않는 경우입니다.* biod 수가 서버의 용량에 비해 크게 늘어나면 서버가 overrunning 상태에 빠집니다. 이때에는 biod 를 줄여야 하는데 stopsrc -s biod 를 먼저 실행후 줄여야 합니다. 이때에도 kernel process biod 는 여전히 작동중입니다.

3. nfs buffer size 증가nfs V3 에서 read/write 버퍼크기는 기본값이 32KB 이며 최대 61440B(AIX 에서)까지 가능합니다.이 최대값을 사용하면 어느정도의 성능향상을 기대할 수 있는데 서버와 클라이언트 양쪽이 AIX 이면 양쪽에서 똑같이 변경해 주어야 합니다.클라이언트에서는 mount 옵션으로, 서버에서는 nfso 를 이용하여 번경하여 줍니다.

daemon nfsd : 서버쪽에서 클라이언트에서 보내온 요청을 처리하는 데몬. 하나의 요청당 하나의 nfsd 데몬이 처리 biod : 클라이언트쪽에서 서버로 read/write 를 요청하는 데몬. 하나의 요청당 하나의 biod 데몬이 사용됨

V. Summary1. schedo(CPU)

smt_snooze_delay SMT 환경에서 아주 짧은 idle 이 자주 발생하는 Thread 가 많을 경우 이 값을 -1 로 하거나 적당하게

(5~20) 늘려주는 것이 좋습니다. (기본값 0)

2. vmo(Memory)minfree : cpu 수 * 120 (기본값은 120 혹은 128)maxfree : minfree + cpu 수*maxpgahead 혹은 j2_maxPageReadAhead (기본값은 128)만약 lru_file_repage 가 vmo 에 있다면,

lru_file_repage = 0 (기본값은 1)minperm, maxperm, maxclient, strict_maxperm, strict_maxclient 등 모두 기본값 그대로

사용lru_file_repage 가 vmo 에 없다면,

minperm : 10~20 (기본값은 20)maxperm, maxclient : 20~60 사이 혹은 (100 – %avm - 10%) (기본값은 80)strict_maxperm : 상황에 따라서 1 이지만 가급적 0 (기본값은 0)strict_maxclient : 기본값인 1

3. ioo(File)minpgahead

File 을 sequential 하게 읽어 들일 때 처음 읽어 들이는 size. 횟수가 늘어날 때마다 이전 값의 2배수로 더 크게 읽어 들이지만 maxpgahead 보다 값이 커질 수는 없습니다.권장값 : 2 (기본값 2)

maxpgahead Sequential read-ahead 가 증가할 수 있는 maximum page 수.권장값 : 연속적이 io 가 많이 발생한다면 32 혹은 기본값인 8

sync_release_ilocksync 가 일어나 disk 에 i/o 가 발생하는 동안 inode 에 걸리는 lock 을 풀어주는 option. sync 가 일어나는 동안 file access 가 느려지는 현상을 줄일 수 있지만 데이터의 정합성에 문제가 발생할 수 있습니다.권장값 : 0 (기본값 0)

4. no(Network)

Speed MTU tcp_sendspace tcp_recvspace

udp_sendspace

udp_recvspace

rfc1323

10Mb 1500 16384 16384 16384 163840 0100Mb 1500 16384 16384 16384 163840 0

GB 1500 131072 65536 65536 655360 1

sb_max권장값 : tcp_sendspace, tcp_recvspace, udp_sendspace, udp_recvspace 중 최대값의 두배 이상 (기본값 1048576)

tcp_sendspace : 기본값 16384tcp_recvspace : 기본값 16384ucp_sendspace : 기본값 9216

권장값 : 상단 table 참조(특히 Oracle 10g 에서 DB_BLOCK_SIZE * DB_MULTIBLOCK_READ_COUNT)+4KB)

ucp_recvspace : 기본값 42080권장값 : 상단 table 참조(특히 Oracle 10g 에서 udp_sendspace 의 10배)

rfc1323 : 기본값 0권장값 : 기가환경에서는 1

5. device(disk, ethernet adater)Enhanced Concurrent Mode 로 사용되는 디스크 : no_reserve : yesethernet adapter : large_send_enable : no, checksum_offload : no

6. HACMP 환경

sycnd 주기 : 10 (기본값은 60)maxpout : 33 (기본값은 0)minpout : 24 (기본값은 0)각 network 에서의 failure detection rate : slow

7. OS 설정

autorestart : true (기본값 false)cpuguard : enable (기본값 disable)

8. Paging space 설정

1) 하나의 디스크에는 하나의 Paging space만 생성.2) 여러 개의 디스크에 각각 Paging space를 운용 할 때는 동일 사이즈, 혹은 거의 비슷한 사이즈로 Paging space를 생성.3) 외장 디스크에 Paging space 생성을 피함.(이는 성능보다는 안정성을 위함으로 외장 디스크는 이동성 및 필요시 제거할수 있어야 하기 때문에 이런 권고사항이 생긴것으로 상황에 따라 적절히 운용하면 됩니다.)4) 여러 개의 디스크에 하나의 Paging space를 확장시키지 않음.(striping 같이 하면 안된다는 것입니다.)5) mirror를 이용하여 2 copy 이상 생성