본문 바로가기

enhanced_affinity_affin_time enhanced_affinity_affin_time 값은 0-100으로 automatic background reaffinitization을 할 때에 cpu 자원 사용량을 제한해주는 parameter로 default는 1. (1%) 하지만 종종 CPU 사용량을 정확히 계산하지 못하고 reaffin process가 cpu를 과다점유하는 사례가 있으므로, enhanced_affinity_affin_time를 off (set to 0) 하도록 권고한다. 해당 parameter 값을 확인해 보고 아래와 같이 0으로 설정해 줄 것. # vmo -p -o enhanced_affinity_affin_time=0
/var/tmp/Ex*, /var/preserve/... /var/tmp와 /var/preserve에 생성되는 파일은 vi로 인해 생성된다. vi editor 는 default editing buffer directory로 /var/tmp 를 사용하며 Ex 로 시작하는 buffer 파일을 생성한다. /var 파일시스템에 full 이 발생할 정도의 큰 데이터 파일을 open했을 경우 대용량의 Ex* 파일이 생성될 수 있다. 현재 vi로 편집하는 파일이 없다면 지워도 관계 없다. /var/preserve 아래에 있는 파일들은 vi 명령을 사용하여 편집을 하는 도중 갑자기 중지가 된 내용들이다. 일반적으로 -r 옵션을 사용하여 이전에 중지된 파일의 내용을 복원하며 이 때 사용된다. 삭제해도 무방함. Check the /var/preserve directory for..
CPU사용률 모니터링 CPU사용률 모니터링 # nmon -> t 옵션 # topas -P 특정 기간(ex. 5초 등..)동안 CPU사용률을 확인하고 싶다면 tprof 커맨드 사용 # tprof -x sleep => 현재 directory에 sleep.prof 라는 이름의 output 파일이 생성되며, CPU 사용률로 sorting하여 결과 로깅됨 ex) # tprof -x sleep 30 # cat sleep.prof Configuration information ========================= ...snip... Tprof command was: tprof -x sleep 5 Trace command was: /usr/bin/trace -ad -M -L 1339173273 -T 500000 -j 00A,001..
j2_inodeCacheSize / j2_metadataCacheSize inode/meta cache가 메모리를 많이 점유하는 문제가 발생한다면, J2가 inode 및 metadata를 즉시 recycle함으로써 free memory를 확보하게끔 아래와 같이 관련 파라미터 값을 줄일 수 있다. # ioo -p -o j2_inodeCacheSize=100 -o j2_metadataCacheSize=100 => default:400 -> 100 으로 축소 f/s umount/mount 다시 해줘야 적용됨 이렇게 되면 대략 1/4정도의 kernel heap에 포함된 inode cache, metadata cahce의 사용량이 줄어든다. 단, 이 경우 jfs2사용에 대한 performance의 저하가 올 수도 있으므로 변경 후 모니터링이 필요함.
dumplv에 대하여 dumplv는 mirror를 권장하지 않고 자체적으로 mirror가 안되도록 막혀있다. 이유는 다양한 system crash 상황에서 AIX가 dump를 받아야 하는데, 이 때는(hang 또는 crash 시) AIX lvm function자체가 제대로 동작하지 않을 수 있기 때문에 mirror가 되어 있는 경우에는 dump device에 data를 기록할 때 corruption이 발생할 수 있다고 한다. 그래서 mirror대신 별도의 디스크에 secondary dump device를 만드는 것만이 권장되어 있다. primary dump device: hdisk0 secondary dump device: hdisk1 만일 fault난 디스크(hdisk0)에 primary dump가 설정되어 있을 경우, 아..
ERROR LOGGING BUFFER OVERFLOW ERROR LOGGING BUFFER OVERFLOW 는 error가 많이 발생하여 error log자체의 buffer를 넘어서서 과거의 error가 지워졌다는 기록이다. 아래와 같이 error log buffer를 현재 값에서 2배 정도 늘려주면 된다. (운영에 영향없이 온라인 중에 가능) ex) buffer: 32767 -> 65536 bytes로 두배 늘려주기 # /usr/lib/errdemon -l Error Log Attributes --------------------------------------------- Log File /var/adm/ras/errlog Log Size 106496 bytes Memory Buffer Size 32768 bytes
zombie process 좀비 프로세스는 kill 시그널을 받아도 프로세스가 종료되지 않는다. 이미 현재 프로세스에 대한 모든 정보는 메모리에서 사라졌지만, 부모 프로세스가 정상적인 종료 처리를 하지 못해 발생한다. 좀비 프로세스에 대한 해결책은 리부팅. 리부팅이 되면 모든 메모리 정보가 새롭게 초기화되므로 좀비 프로세스에 대한 내용도 사라지게 된다. 참고로, 모든 프로세스는 일시적으로 좀비 상태를 거친 후 종료된다. unix/linux의 모든 프로세스들은 작업을 완료하면 커널을 통해 종료사실을 부모프로세스에게 알린다. 이때 부모프로세스가 자식프로세스의 종료사실을 확인 해주어야 해당 프로세스가 정상적으로 종료할 수 있다. 부모 프로세스가 종료 사실을 확인할 때까지는 자식 프로세스는 일시적으로 좀비상태가 되는데, 이는 육안으로 식..
tcpdump 사용법 tcpdump는 바로 display되며 별도의 파일로도 받을 수 있다. # tcpdump -i port ex) # tcpdump -i en0 port 12345 # tcpdump -i en0 # tcpdump -i en0 > tcpdump.out 혹은 # tcpdump -i en0 -l -w tcpdump.bin # tcpdump -r /tmp/tcpdump.bin -n -v > /tmp/tcpdump.out 으로 확인 # tcpdump -i lo0 -l -w /tmp/tcpdump.bin tcp[13] \&7 !=0 => 이렇게 tcpdump 를 받아보면, socket이 CLOSE_WAIT 상태로 왜 남아있는지를 찾을 수 있다. data는 충분한 시간동안 모은 다음, CLOSE_WAIT 상태의 sock..