j2_inodeCacheSize调优操纵和内存DR操纵的潜匿伤害副浸染
|
跟踪日志和报告 跟踪日志可帮助我们进一步理解这一问题。 #ioo -a | grep j2_inodeCacheSize #trace -anl -C all -T100M -L200M -K vmm -o trace.raw; #trcrpt -C all -o trc.out trace.raw 我们可从跟踪日志中发现,ioo 命令调用了 pile_config_max() 函数来降低 maxtotalpg 值, #ioo -a | grep j2_inodeCacheSize #trace -anl -C all -T100M -L200M -K vmm -o trace.raw; #trcrpt -C all -o trc.out trace.raw#grep pile_config_max trc.out 从跟踪日志中我们可以发现,在增加 j2_inodeCacheSize 时,未调用 pile_config_max() 函数,这就是 maxtotalpg 原封未动的原因。 执行内存 DR 操作可获得类似的跟踪日志:删除内存时调用了 pile_config_max() 函数,但增加内存时未调用它。 inode 缓存耗尽 maxtotalpg 只能降低的事实意味着,在偶然降低 j2_inodeCacheSize 或执行 DLPAR 内存删除后,inode 缓存可能被耗尽,甚至在一次 j2_inodeCacheSize 增加或 DLPAR 内存添加后就被耗尽。 查看本栏目更多精彩内容:http://www.bianceng.cn/OS/unix/ 下面的测试演示了 inode 缓存耗尽情况。
# ioo -o j2_inodeCacheSize=50
Setting j2_inodeCacheSize to 50
# ioo -o j2_inodeCacheSize=400
Setting j2_inodeCacheSize to 400
#kdb
(0)> i2 -c
iCache:
nInode: 0xB3306 (733958)
nMaxInode: 0xB3306 (733958)
nCacheClass: 17
nHashClass: 0xFFFF (65535)
nNewHashClass: 0xFFFF (65535)
cacheTable: 0xF10001003A70F000
hashTable: 0xF10001003B57D000
Cache table:
CLASS LOCK INODES CACHELIST.HEAD PILE FULL
0 0 282 F10001003FAFA080 F10001003B50D300 0
1 0 280 F10001003D4B4480 F10001003B50D600 0
……
16 0 281 F10001003FAEA080 F10001003B510500 0
(0)> dw iCache 12
iCache+000000: 000B3306 00110000 F1000100 3A70F000 ..3.........:p..
iCache+000010: 0000A8A6 0000FFFF 0000FFFF 00000010 ................
iCache+000020: F1000100 3B57D000 000029D5 000B3306 ....;W....)...3.
(0)> pile F10001003B50D300
name........iCache
……
maxtotalpg..0x0000000000000539 mintotalpg..0x0000000000000000
curtotalpg..0x0000000000000060
然后,我们编写了一个程序来打开许多文件(参见 openfile.c)。 #./openfile 1000 100 /home/testdir 以下错误消息被显示: open 90 failed Resource temporarily unavailable (编辑:宣城站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |

