AIX OS 환경에서 5.1 을 사용하다가 5.2 ML04 이상 또는 5.3 ML01 이상으로 올린 경우에 VMM 기능에 따른 성능 저하 문제와 PAGING ISSUE가 시간이 지남에 따라 빈번히 발생하여 운영에 문제를 야기시키는 경우, 원인 분석 및 사례를 통해 해결책을 제시하는 내용입니다.
이 문제가 발생하는 device 는 OS의 File system buffer cache를 지원하는 Storage를 사용하는 경우이며, 다음의 스토리지 TYPE들에 대해서는 해당이 없거나 발생하더라도 impact가 적습니다.
Raw logical volumes, filesystems using the Concurrent I/O (CIO) option, filesystems using the Direct I/O (DIO) option.
즉, raw device를 사용하는 경우와 Concurrent I/O (CIO) option으로 mount된 file system, Direct I/O (DIO) option으로 mount된 file system 에서는 이 문제에 대해서 고려 대상이 아닙니다.
AIX 5.3으로 올린 이후에 VMM 기능이 활성화되면서 memory contention이 많아지고, memory 사용률이 높아지는 사례가 보이고 있습니다.
lru_file_repage 라는 AIX OS PARAMETER가 0이 아닌 값으로 되어 있으면 ORACLE 에서는 성능 저하 현상이나 인스턴스 DOWN 에러들을 만날 수 있는데, 주로, RAC 에서는 한쪽 NODE의 성능 저하로 인해 ora-29740 error를 만나기도 하고, latch contention 같은 Performance 문제도 single node나 RAC node나 상관 없이 발생할 수 있습니다.
Oracle 에서는 이미 buffer cache를 통해서 memory에 buffer를 keep하기 때문에 OS가 제공하는 FILE buffer cache를 사용하실 필요가 없으므로, lru_file_repage를 0으로 하시라는 것입니다.
이 값을 0이 아닌 값으로 하게 되면 Buffer File I/O 를 위해 사용되는 Physical Memory 가 더 늘어나기 때문에 OS의 성능 저하를 가져올 수 있습니다. 더 많은 OS Memory 를 Oracle Process 와 다른 프로세스가 사용되도록 Tuning 하시라는 의도입니다. OS Memory Tuning 으로 실제 ORA-29740 error 혹은 memory가 점진적으로 많이 소모되는 문제에 대해 Oracle 고객분들께서 lru_file_repage 값을 0 으로 조정함으로써 해결하신 사례가 많이 있습니다.
[ alert.log ]
다음은 이 원인에 의해 Oracle Server의 alert.log file에서 error를 만난 사례들입니다.
GES: Potential blocker (pid=978982) on resource TX-016F0026-00001CA0
LMON: terminating instance due to error 29740
[ 29740 ERROR가 자주 발생한 Instance ]
2007-11-10 04:45:50.728 <==== LMON DOWN.
Submitting asynchronized dump request [1]
error 29740 detected in background process
ORA-29740: evicted by member 1, group incarnation 3
Tue Nov 20 06:44:07 2007
Errors in file /oraDB1_trc/bdump/oraDB1_j002_1282344.trc:
ORA-00481: LMON process terminated with error
Tue Nov 20 06:44:07 2007
Errors in file /oraDB1_trc/bdump/oraDB1_p142_1913322.trc:
ORA-07445: exception encountered: core dump [] [] [] [] [] []
Tue Nov 20 06:44:08 2007
Errors in file /oraDB1_trc/bdump/oraDB1_p416_1118656.trc:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00449: background process ‘LCK0’ unexpectedly terminated with error 481
ORA-00481: LMON process terminated with error
ORA-00481: LMON process terminated with error
Tue Nov 20 06:44:08 2007
Errors in file /oraDB1_trc/bdump/oraDB1_p141_967492.trc:
ORA-07445: exception encountered: core dump [] [] [] [] [] []
Tue Nov 20 06:44:13 2007
ARC0: terminating instance due to error 481
Tue Nov 20 06:44:32 2007
Errors in file /oraDB1_trc/bdump/oraDB1_lmon_2163150.trc:
ORA-29740: evicted by member 1, group incarnation 3
Instance terminated by ARC0, pid = 737652
Tue Nov 20 07:42:55 2007
[ RAC 반대 편 NODE ]
Tue Nov 20 06:40:53 2007
IPC Send timeout detected. Sender ospid 2355372 <=====
Tue Nov 20 06:40:57 2007
IPC Send timeout detected. Sender ospid 1798210
Tue Nov 20 06:41:15 2007
Communications reconfiguration: instance 0
Evicting instance 1 from cluster <=====
Tue Nov 20 06:41:41 2007
Waiting for instances to leave:
[ OS System Log ]
System 쪽 error는 OS를 AIX 5.1 -> 5.3 으로 올린 이후에 다음과 같이 발생하였다고 합니다.
주로, ORA-29740 ERROR가 보였던 시점과 유사한 시점에 발생한 메시지입니다.
—————————————————————————
레이블: TS_NIM_ERROR_STUCK_
ID: 3D32B80D
날짜/시간: 2008년 3월 17일 월요일 02시 20분 33초
순번: 132755
기계 ID: 00372F1A4C00
노드 ID: oraDB1
클래스: S
유형: PERM
자원 이름: topsvcs
설명
NIM 스레드 블록됨
가능성 있는 원인
—————–
A thread in a Topology Services Network Interface Module (NIM) process was blocked
Topology Services NIM process cannot get timely access to CPU
사용자 원인
————
Excessive memory consumption is causing high memory contention
Excessive disk I/O is causing high memory contention
권고 조치
———
시스템의 입출력과 메모리 활동을 검사하십시오.
시스템에서 로드를 줄이십시오.
가상 메모리 매개변수를 조정하십시오.
문제점이 계속되면 IBM 서비스에 문의하십시오.
실패 원인
———-
지나친 가상 메모리 활동이 NIM이 진행되지 못하게 합니다.
지나친 디스크 입출력 트래픽이 입출력 페이징을 방해하고 있습니다.
권고 조치
시스템의 입출력과 메모리 활동을 검사하십시오.
시스템에서 로드를 줄이십시오.
가상 메모리 매개변수를 조정하십시오.
문제점이 계속되면 IBM 서비스에 문의하십시오.
Explanation
————–
[ Recommendation ]
Aix의 VMM 기능을 사용 시에 초기 OS install 시에 조정해야 할 PARAMETER가 lru_file_repage입니다.
다음의 parameter를 setting한 이후에 OS memory activity, system의 Load가 줄어들어 운영 상의
성능이 좋아진 사례를 많이 볼 수 있습니다.
lru_file_repage 의 현재 값은 다음의 OS 명령어로 확인 가능합니다.
/usr/sbin/vmo -a
If you do not have the /usr/sbin/vmo file you will need to have your AIX systems administrator load the AIX fileset “bos.perf.tune”. The vmo command will list out all of the VMM parameters and their current values. The parameters you want to examine are:
MINPERM%, MAXPERM%, and MAXCLIENT%
Here is an example of the vmo report:
[ 변경 전 ]
다음은 변경하기 전의 현재 값을 조회하는 명령어입니다.
# vmo -a
cpu_scale_memp = 8
data_stagger_interval = 161
defps = 1
force_relalias_lite = 0
framesets = 2
htabscale = -1
kernel_heap_psize = 4096
kernel_psize = 16777216
large_page_heap_size = 0
lgpg_regions = 0
lgpg_size = 0
low_ps_handling = 1
lru_file_repage = 1 <====
lru_poll_interval = 0
lrubucket = 131072
maxclient% = 40
maxfree = 2310
maxperm = 11087666
maxperm% = 40 <====
maxpin = 23796381
maxpin% = 80
mbuf_heap_psize = 4096
memory_affinity = 1
memory_frames = 29360128
memplace_data = 2
memplace_mapped_file = 2
memplace_shm_anonymous = 2
memplace_shm_named = 2
memplace_stack = 2
memplace_text = 2
memplace_unmapped_file = 2
mempools = 3
minfree = 2163
minperm = 5543832
minperm% = 20 <====
nokilluid = 0
npskill = 80128
npsrpgmax = 641024
npsrpgmin = 480768
npsscrubmax = 641024
npsscrubmin = 480768
npswarn = 320512
num_spec_dataseg = 0
numpsblks = 10256384
page_steal_method = 0
pagecoloring = n/a
pinnable_frames = 25351406
pta_balance_threshold = n/a
relalias_percentage = 0
rpgclean = 0
rpgcontrol = 2
scrub = 0
scrubclean = 0
soft_min_lgpgs_vmpool = 0
spec_dataseg_int = 512
strict_maxclient = 1
strict_maxperm = 0
v_pinshm = 0
vm_modlist_threshold = -1
vmm_fork_policy = 1
vmm_mpsize_support = 1
[ 변경 후 ]
An IBM senior analyst has recommended the following VMM parameter settings for Oracle RAC
installation:
.
minperm%=3 maxperm%=90 maxclient%=90, lru_file_repage=0
It eliminates or reduces most paging issues since numperm has to drop below 3% before
computational pages would be selected.
VMM(Virtual Memory Management) Tuning (AIX 5.2 ML04 이상)
Metalink 공식 문서 Note 316533.1 참조하시기 바랍니다.
The default value is “1”, but it is recommended to set this to “0”.
This setting hints to the VMM to only steal file pages (from the AIX file buffer cache) and
leave the computational pages (from the SGA) alone
Oracle DATABASE 를 사용하는 환경에서는 lru_file_repage=0 으로 권장
이 parameter는 AIX 5.2 ML4 이상과 모든 AIX 5.3 version 에서 setting할 수 있습니다.
이 성능 문제 관련하여 변경하실 kernel 파라미터는 위와 같습니다.
minperm, maxperm 파라미터를 조정하실 수 있습니다. File system cache 를 적게
사용하고 oracle에서 memory를 더 많이 사용하도록 조정을 하시는 것입니다.
[ OS Virtual Memory Monitor ]
Monitor the avm (active virtual pages) in vmstat.
AIX OSW v2.1.1 oraDB1
zzz ***Fri Mar 7 02:00:21 KORST 2008
System configuration: lcpu=32 mem=98304MB
kthr memory page faults cpu
—– ———– ———————— ———— ———–
r b avm fre re pi po fr sr cy in sy cs us sy id wa
76 1 17239322 767423 0 38 0 0 0 0 17354 456060 42531 72 27 0 0
71 1 17261510 744692 0 50 0 0 0 0 17591 453396 42275 73 25 0 1
71 1 17266249 739880 0 54 0 0 0 0 18468 420004 42004 76 24 0 0
zzz ***Fri Mar 7 02:00:52 KORST 2008
System configuration: lcpu=32 mem=98304MB
kthr memory page faults cpu
—– ———– ———————— ———— ———–
r b avm fre re pi po fr sr cy in sy cs us sy id wa
48 1 17383817 619910 0 131 0 0 0 0 16579 320848 35404 70 27 1 2
59 4 17396799 606302 0 137 0 0 0 0 19742 354447 42862 74 24 1 2
68 1 17421283 577601 0 86 0 0 0 0 18161 320067 37689 75 23 0 1
zzz ***Fri Mar 7 02:01:23 KORST 2008
System configuration: lcpu=32 mem=98304MB
kthr memory page faults cpu
—– ———– ———————— ———— ———–
r b avm fre re pi po fr sr cy in sy cs us sy id wa
55 1 17573850 288786 0 9 0 0 0 0 6980 203269 18185 69 30 0 1
60 0 17589504 265429 0 57 0 0 0 0 14444 382658 37730 73 26 0 1
75 2 17603007 245526 0 40 0 0 0 0 16420 404348 40649 74 25 0 1
zzz ***Fri Mar 7 02:01:54 KORST 2008
System configuration: lcpu=32 mem=98304MB
kthr memory page faults cpu
—– ———– ———————— ———— ———–
r b avm fre re pi po fr sr cy in sy cs us sy id wa
84 16 17805752 840 0 81 84 63038 206659 0 15422 313172 89229 62 30 1 8
13 86 17816440 4 0 0 477 12031 36728 0 11940 256703 78364 45 13 2 40
16 110 17817486 6 0 7 410 1606 2047 0 6485 163530 49454 31 9 2 59
zzz ***Fri Mar 7 02:02:30 KORST 2008
System configuration: lcpu=32 mem=98304MB
kthr memory page faults cpu
—– ———– ———————— ———— ———–
r b avm fre re pi po fr sr cy in sy cs us sy id wa
4 211 17900211 527 0 4 322 875 1215 0 4448 136666 42842 12 8 0 79
4 187 17892064 9103 0 0 640 146 222 0 5108 93349 15216 9 6 0 85
2 180 17894616 6899 0 6 572 0 0 0 4234 39010 9332 4 4 0 92
zzz ***Fri Mar 7 02:04:07 KORST 2008
System configuration: lcpu=32 mem=98304MB
kthr memory page faults cpu
—– ———– ———————— ———— ———–
r b avm fre re pi po fr sr cy in sy cs us sy id wa
64 8 17107920 804990 0 465 0 0 0 0 34302 369445 52641 66 33 0 1
61 4 17110768 801151 0 250 0 0 0 0 18133 146536 26230 67 30 0 2
47 10 17113287 798239 0 364 2 0 0 0 27735 243125 38855 65 26 2 7
zzz ***Fri Mar 7 02:04:39 KORST 2008
System configuration: lcpu=32 mem=98304MB
kthr memory page faults cpu
—– ———– ———————— ———— ———–
r b avm fre re pi po fr sr cy in sy cs us sy id wa
91 1 17441080 462788 0 107 0 0 0 0 12417 172603 19356 75 25 0 0
112 2 17424469 478649 0 94 0 0 0 0 14367 193231 22642 79 21 0 0
110 2 17395065 507752 0 90 0 0 0 0 12029 166724 17943 80 20 0 0
zzz ***Fri Mar 7 02:05:10 KORST 2008
System configuration: lcpu=32 mem=98304MB
kthr memory page faults cpu
—– ———– ———————— ———— ———–
r b avm fre re pi po fr sr cy in sy cs us sy id wa
111 1 17354323 542734 0 106 0 0 0 0 11844 121597 16329 79 21 0 0
103 1 17340910 546696 0 104 0 0 0 0 15354 116912 19247 84 16 0 0
104 0 17341204 538862 0 44 0 0 0 0 13177 121793 18020 80 20 0 0
zzz ***Fri Mar 7 02:05:42 KORST 2008
System configuration: lcpu=32 mem=98304MB
kthr memory page faults cpu
—– ———– ———————— ———— ———–
r b avm fre re pi po fr sr cy in sy cs us sy id wa
86 1 17391770 377743 0 27 0 0 0 0 15056 141592 19478 77 23 0 0
93 2 17382990 379574 0 23 0 0 0 0 14189 147844 20078 76 24 0 0
90 3 17381710 375602 0 29 0 0 0 0 15293 148375 21661 77 23 0 0
zzz ***Fri Mar 7 02:06:13 KORST 2008
System configuration: lcpu=32 mem=98304MB
kthr memory page faults cpu
—– ———– ———————— ———— ———–
r b avm fre re pi po fr sr cy in sy cs us sy id wa
91 1 17578330 61810 0 402 0 0 0 0 19479 268802 33449 76 24 0 0
80 2 17571188 61691 0 84 0 0 0 0 10935 162114 19559 76 24 0 0
89 3 17551358 81394 0 105 0 0 0 0 18548 241193 32393 81 19 0 0
zzz ***Fri Mar 7 02:06:44 KORST 2008
System configuration: lcpu=32 mem=98304MB
[ OS Tuning ]
available swap memory의 감소나 Memory bottlenecks을 확인할 수 있는 scan rate (sr) 값의 변경 추이를 보는 것인데, 이 값이 일정 임계치가 넘으면 Memory shortage가 존재한다는 것을 알 수 있습니다.
OS resource를 monitoring할 수 있는 문서는 다음의 OS watcher user guide가 존재하며, Memory shortage 여부에 대해서 다음을 언급하고 있습니다.
Note 301137.1 Title: OS Watcher User Guide
What to look for 부분을 참조 바랍니다.
4. Memory bottlenecks are determined by the scan rate (sr) . The scan rate is the pages scanned by
the clock algorithm per second. If the scan rate (sr) is continuously over 200 pages per second
then there is a memory shortage.
Reference Documents
——————-
다음의 ppt 문서를 보시면 AIX OS TUNING을 통해 ORACLE에서 최적의 환경을 구축하는 세부 PARAMETER들이
있습니다.
http://www-900.ibm.com/cn/downloadfiles/tsc/faq/Oracle_on_pSeries_tuning_internet.ppt
<Note:316533.1> AIX Database performance gets slower the longer the database is running