AIX的内核参数的调整对数据库和应用的性能至关重要。一般来说,在部署阶段，我们必须对内核参数做适当的调整，上线以后，也需要对内核的某些参数做出微调。最近,收到一个case,发现errpt里面有大量的”NIM thread blocked”事件，老外抱怨前端应用很慢,通过nmon收集信息，发现有大量的page in/out。
经过分析，我发现有一个相当重要的参数，需要我们去关注,那就是lru_file_repage.简单来说,就是如果将这个参数设置为0的时候,AIX会尽可能的keep住计算内存在RAM里面.在AIX6.1里面这个参数默认为0.在启用了STMM的DB2数据库里面，数据库内存的规则也是会尽量不让计算内存交换出去.
对于这个参数IBM的官方解释如下:
lru_file_repage – when the number of permanent memory pages (numperm) falls between minperm and maxperm (or the number of client memory pages falls between minperm and maxclient), this setting indicates whether repaging rates are considered when deciding to evict permanent memory pages or computational memory pages. Setting this to 0 tells AIX to ignore repaging rates and favor evicting permament memory pages, keeping more computational memory in RAM. The AIX 5L default is 1/true (consider the repaging rate), The AIX 6.1 default is 0/false (now a restricted setting).
在我们调整完该参数后，再微调了数据库的另外一些参数，数据库性能得到了大幅度的提升，没有再出现”NIM thread blocked”.AIX5.3/6.1里面，内核参数发生了一些变化，除了以上提到的这个参数外，还有其它的内核参数需要我们关注.
Posts Tagged ‘AIX’
lru_file_repage
March 4th, 2009在AIX下面用kdb来分析dump文件
November 4th, 2008很久以前写过一个文章在AIX下用kdb来分析一个僵死进程。这两天又碰到一次AIX系统dump。因为发生在周末，周一上班的时候，才发现有dump文件生成。
我们首先看看dump文件的生成的状态:
sysdumpdev -L
Device name: /dev/lg_dumplv
Major device number: 10
Minor device number: 10
Size: 276834867 bytes
Uncompressed Size: 1964289255 bytes
Date/Time: Sat Nov 1 12:48:04 2008
Dump status: 0
dump completed successfully.
2.抓取dump文件
snap -Dd /tmp/ibmsupt
3.Uncompress dump文件
/usr/bin/dmpuncompress DUMP.BZ
解压后，就可以开始使用kdb来debug dump文件了:
vmstat在aix5L里面的新选项
September 29th, 2005在看VMSTAT的MAN的时候，无意中发现了VMSTAT在AIX5L里面的几个新参数的用法
1.vmstat -I 1
kthr memory page faults cpu
——– ———– ———————— ———— ———–
r b p avm fre fi fo pi po fr sr in sy cs us sy id wa
1 1 0 236130 1707 0 5 0 0 0 1 296 4907 406 55 4 40 1
1 0 0 230809 7026 0 3 0 0 0 0 312 7948 469 90 9 1 0
1 0 0 234079 3756 0 3 0 0 0 0 314 7772 455 96 4 0 0
3 0 0 235620 2215 0 4 0 0 0 0 314 9933 462 91 9 0 0
1 0 0 229008 8826 0 3 0 0 0 0 309 7028 455 94 6 0 0
1 0 0 233515 4319 0 3 0 0 0 0 315 7936 455 94 6 1 0
1 0 0 235533 2301 0 3 0 0 0 0 312 8487 454 92 8 0 0
其中：
kthr 下的 p: 每秒钟真正等待物理I/O的线程数
page 下的 fi: 每秒钟调入的文件页数
fo: 每秒钟调出的文件页数
2.vmstat -t 1
kthr memory page faults cpu time
—– ———– ———————— ———— ———– ——–
r b avm fre re pi po fr sr cy in sy cs us sy id wa hr mi se
0 0 228656 9128 0 0 0 0 0 0 312 3079 466 1 1 98 0 08:57:31
0 0 228656 9128 0 0 0 0 0 0 323 3178 482 1 1 97 1 08:57:32
0 0 228749 9035 0 0 0 0 0 0 305 7520 458 5 8 85 2 08:57:33
0 0 228689 9095 0 0 0 0 0 0 315 2903 467 0 1 98 1 08:57:34
0 0 228656 9128 0 0 0 0 0 0 316 2979 469 0 0 98 2 08:57:35
0 0 228656 9128 0 0 0 0 0 0 309 3045 463 2 1 97 0 08:57:36
0 0 228656 9128 0 0 0 0 0 0 313 3108 459 2 0 97 1 08:57:37
1 0 228656 9128 0 0 0 0 0 0 311 2797 448 0 0 99 0 08:57:38
增加了记录系统时间的选项
AIX里面的Quorum和VGDA
September 12th, 2005$ lsvg rootvg
VOLUME GROUP: rootvg VG IDENTIFIER: 000a995d00004c00000001059e94badf
VG STATE: active PP SIZE: 64 megabyte(s)
VG PERMISSION: read/write TOTAL PPs: 1084 (69376 megabytes)
MAX LVs: 256 FREE PPs: 344 (22016 megabytes)
LVs: 10 USED PPs: 740 (47360 megabytes)
OPEN LVs: 9 QUORUM: 1
TOTAL PVs: 2 VG DESCRIPTORS: 3
STALE PVs: 0 STALE PPs: 0
ACTIVE PVs: 2 AUTO ON: yes
MAX PPs per PV: 1016 MAX PVs: 32
LTG size: 128 kilobyte(s) AUTO SYNC: no
HOT SPARE: no BB POLICY: relocatable
为什么 QUORUM是1呢？
因为在RS/6000系统中, 每个在VG(卷组)中的物理硬盘都至少有一个VGDA(卷组描述区, 既对该硬盘上的物理和逻辑卷进行描述）.
VGDA在硬盘的数量有如下规则:
一个卷组只有一块硬盘: 该硬盘有两个VGDA.
一个卷组有两块硬盘: 第一块硬盘有两个VGDA, 第二块硬盘有一个VGDA.
一个卷组有三块或三块以上硬盘: 每块硬盘有一个VGDA.
在AIX系统中, quorum（一个卷组中的可用VGDA的比率）必须高于51%, 该卷组才可用.对于只有两块硬盘的卷组, 若第一块硬盘损坏, 则只有33%的VGDA可用, 那么整个卷租不可用了，这是我们不想看到的情况。照此推理:若第二块硬盘损坏, 则有66%的VGDA可用. 对于有三块或三块以上硬盘的卷组, 若损坏一块硬盘, 至少有66%的VGDA可用.如果因为VGDA不可用而造成整个VG VARYOFF了，我们也可以对该卷组aryonvg -f的命令强制varyon。
所以我们在做rootvg的时候，一般disable quorum。这样我们lsvg的时候，看到的就是quorum=1了。
郁闷，HACMP的C-SPOC没办法用
January 9th, 2005我用C-SPOC报错:
cl_extendvg: This operation is not allowed on a RAID device.
cl_extendvg: No node has access to volume group datavg
去IBM的SUPPORT上面搜了一下,看到一个APAR:
Error description
When trying extend an enhanced concurrent volume group using
CSPOC, the following error message appears:
================================================================
cl_extendvg: This operation is not allowed on a RAID device.
cl_extendvg Operation is not allowed because rawdeud01vg is a
RAID concurrent volume group.
================================================================
This operation should be supported with RAID disks in an
enhanced concurrent volume group.
Local fix
Problem summary
Attempting cspoc VG operations for enhanced
concurrent mode VG’s on disk subsystems like
fastT and the shark generated spurious warning
messages about the operations not being allowed
on raid type disks.
Problem conclusion
Changed the cspoc test for raid disk
types to accommodate enhanced concurrent
mode VG’s on disk subsystems like fasTt and
the shark. Performing VG operations for
enhanced concurrent mode VG’s under cspoc
no longer generates spurious warning messages
about the operation not being allowed on
raid type disks.
可能需要打补丁解决了，只好手工的IMPORTVG然后同步了…
对一个僵死进程的跟踪
December 30th, 2004最近对主机的性能做了一些测试，有一些应用因为强行中断退出，或者一些什么别的原因，系统出现了一些僵死进程，虽然不会耗费多大的资源，但是心里就是觉得不爽(:
尝试跟踪了一下其中一个僵死进程：
环境aix 5.2
node a>kdb
The specified kernel file is a 64-bit kernel
Preserving 1044294 bytes of symbol table
First symbol __mulh
START END
0000000000003500 0000000002483068 _system_configuration+000020
F00000002FF3A600 F00000002FFD0908 __ublock+000000
000000002FF22FF4 000000002FF22FF8 environ+000000
000000002FF22FF8 000000002FF22FFC errno+000000
F100008780000000 F100008790000000 pvproc+000000
F100008790000000 F100008798000000 pvthread+000000
F100000040000000 F1000000491E89B0 vmmdseg+000000
F200010010000000 F200016014800000 vmmswpft+000000
F100000BE0000000 F1000013E0000000 vmmswhat+000000
F100000050000000 F100000060000000 ptaseg+000000
F1000000A0000000 F1000000E0000000 ameseg+000000
F100009E10000000 F100009E20000000 KERN_heap+000000
F1000089C0000000 F1000089D0000000 MBUF_heap+000000
F100009C00000000 F100009C10000000 lkwseg+000000
PFT:
PVT:
id………………..0008
raddr…..0000000002400000 eaddr…..F200010040000000
size…………..03800000 align………….00400000
valid..1 ros….0 holes..0 fixlmb.1 seg….1 wimg…2
(0)> dcal 3518496
Value decimal: 3518496 Value hexa: 0035B020
(0)> tpid 0035B020
SLOT NAME STATE TID PRI RQ CPUID CL WCHAN
pvthread+040500 1029 db2bp SLEEP 405049 03C 4 0 F100009E582789C0
(0)> f 1029
pvthread+040500 STACK:
[0003BB9C]e_block_thread+0002EC ()
[0003C43C]e_sleep_thread+000064 (??, ??, ??)
[0068131C]atomic+0005E0 (??, ??, ??, ??, ??)
[0067FEF8]__semop+0003F0 (002C0022002C0022, 0FFFFFFFFFFFDC78,
0000000000000001)
[0000379C]sc_msr_2_point+000028 ()
(0)> dcal 3379254
Value decimal: 3379254 Value hexa: 00339036
(0)> tpid 00339036
SLOT NAME STATE TID PRI RQ CPUID CL WCHAN
pvthread+040C00 1036 db2sysc SLEEP 40C005 03C 6 0
(0)> f 1036
pvthread+040C00 STACK:
[0003CA00]et_wait+0002F4 (0900000001426CFC, A00000000000D0B2,
FFFFFFFFFFFFFFFF [??])
[0008AEAC]thread_wait+000200 (??)
[0000379C]sc_msr_2_point+000028 ()
[kdb_get_virtual_memory] no real storage @ FFFFFFFFFFF2550
(0)> dcal 1622046
Value decimal: 1622046 Value hexa: 0018C01E
(0)> tpid 0018C01E
SLOT NAME STATE TID PRI RQ CPUID CL WCHAN
pvthread+023400 564 db2sysc SLEEP 23406F 03C 0 0
(0)> f 564
pvthread+023400 STACK:
[0003CA00]et_wait+0002F4 (0900000001426CFC, A00000000000D0B2,
FFFFFFFFFFFFFFFF [??])
[0008AEAC]thread_wait+000200 (??)
[0000379C]sc_msr_2_point+000028 ()
[kdb_get_virtual_memory] no real storage @ FFFFFFFFFFFDE10
(0)> dcal 1999060
Value decimal: 1999060 Value hexa: 001E80D4
(0)> tpid 001E80D4
SLOT NAME STATE TID PRI RQ CPUID CL WCHAN
pvthread+028C00 652 db2sysc SLEEP 28C01F 03C 9 0 ulist_event+0006E0
(0)> f 652
pvthread+028C00 STACK:
[0003BB9C]e_block_thread+0002EC ()
[0008AB94]thread_waitlock+000314 (??)
[0000379C]sc_msr_2_point+000028 ()
[kdb_get_virtual_memory] no real storage @ FFFFFFFFFFFC010
(0)> dcal 3006650
Value decimal: 3006650 Value hexa: 002DE0BA
(0)> tpid 002DE0BA
SLOT NAME STATE TID PRI RQ CPUID CL WCHAN
pvthread+038300 899 db2sysc SLEEP 383007 03C 7 0
(0)> f 899
pvthread+038300 STACK:
[0003CA00]et_wait+0002F4 (0900000001426CFC, A00000000000D0B2,
FFFFFFFFFFFFFFFF [??])
[0008AEAC]thread_wait+000200 (??)
[0000379C]sc_msr_2_point+000028 ()
[900000001426CF8]sqloWaitEDUWaitPost+0003EC ([kdb_get_virtual_memory] no real storage @ FFFFFFFFFFFE090
(0)> dcal 2687006
Value decimal: 2687006 Value hexa: 0029001E
(0)> tpid 0029001E
SLOT NAME STATE TID PRI RQ CPUID CL WCHAN
pvthread+033500 821 db2sysc SLEEP 33506B 03C 1 0
(0)> f 821
pvthread+033500 STACK:
[0003CA00]et_wait+0002F4 (0900000001426CFC, A00000000000D0B2,
FFFFFFFFFFFFFFFF [??])
[0008AEAC]thread_wait+000200 (??)
[0000379C]sc_msr_2_point+000028 ()
[900000001426CF8]sqloWaitEDUWaitPost+0003EC ([kdb_get_virtual_memory] no real storage @ FFFFFFFFFFFE090
估计是做load的时候把所有内存都耗尽了….
看来只好reboot主机了，希望能找到彻底杀死僵死进程的办法…..
收集了一次RS6000的DUMP,还挺麻烦的
December 8th, 2004AIX收集DUMP的过程
AIX收集DUMP的过程
1.ps -ef
2.sysdumpdev -l
3.sysdumpstart -p(系统会锁死）
面板显示888 -xxxxxx 一直到0c0 -xxx0c0
4.reboot机器
5.回答dump文件放到什么地方
6.收集unix内核文件。
花了好几个小时，然后考到磁带上面给IBM公司发过去了，希望对解决问题有进展啊
给fcs0微码降级
September 7th, 2010负责维护的p670最近errpt一直报错，检查发现fcs0和fcs1的微码级别不一样，
fcs0的微码级别较高，但是在errpt里面频繁报错：
2F3E09A4 0224175406 I H fcs0 REPAIR ACTION
D5385D18 0224072906 T H hdisk8 ARRAY OPERATION ERROR
D5385D18 0224064506 T H hdisk8 ARRAY OPERATION ERROR
….
D5385D18 0222203006 T H hdisk8 ARRAY OPERATION ERROR
B8FBD189 0220155006 T S fscsi0 SOFTWARE PROGRAM ERROR
825849BF 0220155006 T H fcs0 ADAPTER ERROR
825849BF 0220155006 T H fcs0 ADAPTER ERROR
B8FBD189 0220152906 T S fscsi0 SOFTWARE PROGRAM ERROR
825849BF 0220152906 T H fcs0 ADAPTER ERROR
3074FEB7 0220152906 T H fscsi0 ADAPTER ERROR
