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 (编辑:PHP编程网 - 黄冈站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |