ontape -s -L 0 too slowly(locks&buffers)

continue:Locks address wtlist owner lklist type tblsnum rowid key#/bsiz a423bcc 0 440dfb64 0 HDR+S 100002 203 0 1 active, 2000000 total, 262144 hash buckets Buffers address userthread flgs pagenum memaddr nslots pgflgs xflgs owner waitlist 113e30ac 0 84 bba255 16f38000 21 90 80 ffffffff 0 118ee82c 0 84 dded2a 1e4a0000 20 90 80 ffffffff 0 11e87ab4 0 84 c6ef43 266e9800 30 90 80 ffffffff 0 121e59f4 0 84 dde586 2b545800 21 90 80 ffffffff 0 123c5cc4 0 84 bb5c28 2e0ec800 20 90 80 ffffffff 0 124b8ea4 0 84 bba342 2f706800 25 90 80 ffffffff 440dfb64 12bd7d7c 0 84 c6ea66 39cbf000 39 90 80 ffffffff 0 12c59ee4 0 84 dde927 3a892800 20 90 80 ffffffff 0 12ddc27c 0 0 2b7f9af 3cbaf000 15 2001 80 440e2344 0 12ea0d84 0 802 c6ee2f 3dd90800 31 90 10 0 0 277 modified, 0 resident, 400000 total, 524288 hash buckets, 2048 buffer size partnum total btree data other resident dirty 0 224944 224854 82 8 0 37 4194306 1 1 0 0 0 0 4194336 15397 15396 0 1 0 25 4194337 7 7 0 0 0 0 4194338 43016 43015 0 1 0 78 4194339 1 1 0 0 0 0 4194340 286 285 0 1 0 0 4194342 5360 5360 0 0 0 0 4194346 1 1 0 0 0 0 4194348 38 38 0 0 0 0 4194351 1 1 0 0 0 0 4194352 28 28 0 0 0 0 4194353 11 11 0 0 0 0 4194355 1 0 1 0 0 1 4194356 1 1 0 0 0 0 4194357 37 37 0 0 0 0 4194358 4665 4641 24 0 0 24 4194362 4820 4796 24 0 0 24 4194395 48 48 0 0 0 0 4194396 808 808 0 0 0 0 4194397 415 415 0 0 0 0 4194398 36 36 0 0 0 0 4194401 100 100 0 0 0 0 4194402 14172 14150 22 0 0 22 4194404 914 914 0 0 0 0 4194431 4 4 0 0 0 0 4194437 34 34 0 0 0 0 4194441 40292 40229 0 63 0 0 4194442 4 4 0 0 0 0 4194445 256 255 1 0 0 2 4194446 554 535 19 0 0 0 4194447 43748 43733 0 15 0 64 Totals: 400000 399738 173 89 0 277 Percentages: Data 0.04 Btree 99.93 Other 0.02

This: Percentages: Data 0.04 Btree 99.93 Other 0.02 Is a problem. Your buffer cache is populated almost entirely with index pages! This is a VERY OLD bug that was fixed several years ago. The workaround is to set LRUAGE=1 and export it in the environment of the session that is starting IDS and bounce the engine to resolve it. Here's a cut from an old forum post (2002) on the subject: LRUAGE is an environmental parameter which should be set to 1 and exported by the session starting the engine. It is the recommended fix for bug 121515. This bug causes the LRU queues to become clogged with high priority index pages rather than being used for the lower priority data pages. You can tell if you are suffering from the bug by checking the last five lines of onstat -P (onstat -P |tail -5) if Btree %age is significantly higher than Data %age and the MED_HIGH and HIGH values from onstat -R are greater than LOW. The impact of the bug is slightly extended checkpoints, LRU contention and generally a degradation in performance. A feature of the fix is that the engine starts to record foreground writes. These are not really happening, they are ghosts and this is what I suspect you are seeing. Hope this helps you. Art Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, Oct 27, 2009 at 7:48 PM, CHEN JANSEN <njjansen@163.com> wrote: > continue:Locks > address wtlist owner lklist type tblsnum rowid key#/bsiz > a423bcc 0 440dfb64 0 HDR+S 100002 203 0 > 1 active, 2000000 total, 262144 hash buckets > > Buffers > address userthread flgs pagenum memaddr nslots pgflgs xflgs owner waitlist > 113e30ac 0 84 bba255 16f38000 21 90 80 ffffffff 0 > 118ee82c 0 84 dded2a 1e4a0000 20 90 80 ffffffff 0 > 11e87ab4 0 84 c6ef43 266e9800 30 90 80 ffffffff 0 > 121e59f4 0 84 dde586 2b545800 21 90 80 ffffffff 0 > 123c5cc4 0 84 bb5c28 2e0ec800 20 90 80 ffffffff 0 > 124b8ea4 0 84 bba342 2f706800 25 90 80 ffffffff 440dfb64 > 12bd7d7c 0 84 c6ea66 39cbf000 39 90 80 ffffffff 0 > 12c59ee4 0 84 dde927 3a892800 20 90 80 ffffffff 0 > 12ddc27c 0 0 2b7f9af 3cbaf000 15 2001 80 440e2344 0 > 12ea0d84 0 802 c6ee2f 3dd90800 31 90 10 0 0 > 277 modified, 0 resident, 400000 total, 524288 hash buckets, 2048 buffer > size > partnum total btree data other resident dirty > 0 224944 224854 82 8 0 37 > 4194306 1 1 0 0 0 0 > 4194336 15397 15396 0 1 0 25 > 4194337 7 7 0 0 0 0 > 4194338 43016 43015 0 1 0 78 > 4194339 1 1 0 0 0 0 > 4194340 286 285 0 1 0 0 > 4194342 5360 5360 0 0 0 0 > 4194346 1 1 0 0 0 0 > 4194348 38 38 0 0 0 0 > 4194351 1 1 0 0 0 0 > 4194352 28 28 0 0 0 0 > 4194353 11 11 0 0 0 0 > 4194355 1 0 1 0 0 1 > 4194356 1 1 0 0 0 0 > 4194357 37 37 0 0 0 0 > 4194358 4665 4641 24 0 0 24 > 4194362 4820 4796 24 0 0 24 > 4194395 48 48 0 0 0 0 > 4194396 808 808 0 0 0 0 > 4194397 415 415 0 0 0 0 > 4194398 36 36 0 0 0 0 > 4194401 100 100 0 0 0 0 > 4194402 14172 14150 22 0 0 22 > 4194404 914 914 0 0 0 0 > 4194431 4 4 0 0 0 0 > 4194437 34 34 0 0 0 0 > 4194441 40292 40229 0 63 0 0 > 4194442 4 4 0 0 0 0 > 4194445 256 255 1 0 0 2 > 4194446 554 535 19 0 0 0 > 4194447 43748 43733 0 15 0 64 > > Totals: 400000 399738 173 89 0 277 > > Percentages: > Data 0.04 > Btree 99.93 > Other 0.02 > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --00032555666ec2edc70476f37381

Art Kagel wrote: > This: > > Percentages: > Data 0.04 > Btree 99.93 > Other 0.02 > > Is a problem. Your buffer cache is populated almost entirely with index > pages! This is a VERY OLD bug that was fixed several years ago. The > workaround is to set LRUAGE=1 and export it in the environment of the > session that is starting IDS and bounce the engine to resolve it. Here's a > cut from an old forum post (2002) on the subject: > > LRUAGE is an environmental parameter which should be set to 1 and exported > by the session starting the engine. It is the recommended fix for bug > 121515. > This bug causes the LRU queues to become clogged with high priority index > pages rather than being used for the lower priority data pages. You can tell > if you are suffering from the bug by checking the last five lines of onstat > -P (onstat -P |tail -5) if Btree %age is significantly higher than Data %age > and the MED_HIGH and HIGH values from onstat -R are greater than LOW. The > impact of the bug is slightly extended checkpoints, LRU contention and > generally a degradation in performance. A feature of the fix is that the > engine starts to record foreground writes. These are not really happening, > they are ghosts and this is what I suspect you are seeing. > Hope this helps you. > > Art LRUAGE was introduced in 7.31.UD1 ( or may be UC6 ) not sure. However, I recall there have been some bugs associated with it (other than the ghost foreground writes) - and there have been other nasty bugs in the early UD versions. So you may want to ensure you are on a recent 7.31.UD fixpack level. Apart from that - you are aware of the fact that 7.31 went out of support by 30 Sep this year . I suggest to upgrade to IDS 11.5. IDS 10 ain't a good alternative as IDS 10.00 will be retired next year. HTH Tilman