RE: NOLRUPRIO / LRUPRIORITY IDS 7.31_UC2

Thanks for the reply. >You definitely have the LRU Priority scheduling bug, I reckon. OK that's the good news...... >Here's a post from The Mighty Art Kagel: Thanks for that, knew of it as Art keeps referring to it, but couldn't find it, was in the process of searching for it when your reply arrived. > I'm not sure if this will work, but have you tried: > SET INDEXES DISABLED; > SET INDEXES ENABLED; > UPDATE STATISTICS LOW DROP DISTRIBUTIONS; Not familiar with the enable / disable indexes, will do some more reading and try it out this weekend, assume I need to run dostats again after that, is my assumption correct? >>Also please feel free to pick the hell out of our onconfig Hmmm. knew I was looking for trouble with that line :) >>LOCKS 200000>I'd allocate more locks (say *10) Sorry, but may I ask why? >>BUFFERS 293750>If you have 1.75GB and you're not using the box for anything else, why not >allocate more buffers? Because of very big SHMVIRTSIZE see comment below. >>PHYSBUFF 8>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHH!!! 32, at *least*!! Please post onstat -l output. >>LOGBUFF 8>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHH!!! 32, at *least*!! Please post onstat -l output. Note we are running unbuffered logging. Physical Logging Buffer bufused bufsize numpages numwrits pages/io P-2 0 4 544996 149719 3.64 phybegin physize phypos phyused %used 200035 20000 14734 3399 17.00 Logical Logging Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io L-1 3 4 9167941 580911 288759 15.8 2.0 Subsystem numrecs Log Space used OLDRSAM 9167941 888732260 >>SHMVIRTSIZE 625000>Wow! That's quite big -- what's the output from onstat -g seg? Yes I know, but by the end of the day and or while running ontape and or if we don't monitor it and run the occasional onmode -F it comes very very close to adding another segment, which is a bad thing when there's no more free memory and your running HP KAIO. <ask me how I know this> >Wouldn't you be better off decreasing this and giving more BUFFERS? Would love to, guess I need to investigate why the application servers chew up so much. Application is MIMS ERP system from Mincom, Clues on what to look for most welcome? >>CKPTINTVL 1200>onstat -m 17:18:16 Logical Log 64351 Complete. 17:18:19 Logical Log 64351 - Backup Started 17:18:30 Logical Log 64351 - Backup Completed 17:20:28 Checkpoint Completed: duration was 5 seconds. 17:35:25 Logical Log 64352 - Backup Started 17:35:25 Logical Log 64352 Complete. 17:35:36 Logical Log 64352 - Backup Completed 17:40:44 Checkpoint Completed: duration was 4 seconds. 17:49:37 Logical Log 64353 Complete. 17:49:39 Logical Log 64353 - Backup Started 17:49:51 Logical Log 64353 - Backup Completed 17:53:32 Checkpoint Completed: duration was 4 seconds. 18:00:48 Logical Log 64354 - Backup Started 18:00:48 Logical Log 64354 Complete. 18:01:00 Logical Log 64354 - Backup Completed 18:06:14 Checkpoint Completed: duration was 3 seconds. 18:20:34 Logical Log 64355 Complete. 18:20:36 Logical Log 64355 - Backup Started 18:20:48 Logical Log 64355 - Backup Completed 18:26:21 Checkpoint Completed: duration was 3 seconds. 18:37:39 Logical Log 64356 Complete. 18:37:43 Logical Log 64356 - Backup Started 18:37:55 Logical Log 64356 - Backup Completed 18:46:39 Checkpoint Completed: duration was 7 seconds. 19:01:48 Logical Log 64357 Complete. 19:01:48 Logical Log 64357 - Backup Started 19:02:00 Logical Log 64357 - Backup Completed 19:06:58 Checkpoint Completed: duration was 7 seconds. 19:27:15 Checkpoint Completed: duration was 4 seconds. 19:31:05 Logical Log 64358 Complete. 19:31:08 Logical Log 64358 - Backup Started 19:31:20 Logical Log 64358 - Backup Completed 19:47:32 Checkpoint Completed: duration was 4 seconds. >>USEOSTIME 1>You are aware that this is slower than USEOSTIME 0 ? Yes but from memory I thought I needed that to get 10th of seconds on the time stamps? Thanks again, Regards Matthew,.

Matthew Byrne wrote: > > Thanks for the reply. There is a bug in the NOLRUPRIO that is supposed to disable the LRU PRIORITY code. This was fixed in 7.31UC6X1 and I have it and am using that for now since on the server affected here it takes about 4 hours per index to rebuild and I have hundreds to do, so meantime. Get an upgrade as a short term fix, you should be able to arrange an FTP download of the install files. > >You definitely have the LRU Priority scheduling bug, I reckon. > > OK that's the good news...... > > >Here's a post from The Mighty Art Kagel: > > Thanks for that, knew of it as Art keeps referring to it, but couldn't find > it, was in the process of searching for it when your reply arrived. > > > I'm not sure if this will work, but have you tried: > > SET INDEXES DISABLED; > > SET INDEXES ENABLED; > > UPDATE STATISTICS LOW DROP DISTRIBUTIONS;> > Not familiar with the enable / disable indexes, will do some more reading No better or worse than drop index, create index you just do not need to know the format of the index so you can automate the rebuild more easily this way. Like a rebuild_indexes_for_table script looks like this: dbaccess mydatabase - <<EOF set indexes for table $1 disabled; set indexes for table $1 enabled; EOF > and try it out this weekend, assume I need to run dostats again after that, > is my assumption correct? > >>Also please feel free to pick the hell out of our onconfig > > Hmmm. knew I was looking for trouble with that line :) > > >>LOCKS 200000> >I'd allocate more locks (say *10) > > Sorry, but may I ask why? > > >>BUFFERS 293750> >If you have 1.75GB and you're not using the box for anything else, why not > >allocate more buffers? > > Because of very big SHMVIRTSIZE see comment below. > > >>PHYSBUFF 8> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHH!!! 32, at *least*!! Please post onstat > -l output. > >>LOGBUFF 8> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHH!!! 32, at *least*!! Please post onstat > -l output. > > Note we are running unbuffered logging. > > Physical Logging > Buffer bufused bufsize numpages numwrits pages/io > P-2 0 4 544996 149719 3.64 ^^^^^ The small physical and logical log buffers are why you are only seeing 2-4 pages per IO on physical and logical logging. Remember EVEN unbuffered logging writes ONLY to the logical log buffers until there is a commit or rollback which forces a cache flush as opposed to BUFFERED logging which only flushes when the buffer fills. So even with BUFFERED logging you can take advantage of larger log buffers UNLESS all of your transactions are smaller than 4 pages? The physical log buffering ignores the logging mode of the database/table and ALWAYS uses its buffers to capacity. > phybegin physize phypos phyused %used > 200035 20000 14734 3399 17.00 > > Logical Logging > Buffer bufused bufsize numrecs numpages numwrits recs/pages pages/io > L-1 3 4 9167941 580911 288759 15.8 2.0 > Subsystem numrecs Log Space used > OLDRSAM 9167941 888732260 > > >>SHMVIRTSIZE 625000> >Wow! That's quite big -- what's the output from onstat -g seg? > > Yes I know, but by the end of the day and or while running ontape and or if > we don't monitor it and run the occasional onmode -F it comes very very > close to adding another segment, which is a bad thing when there's no more > free memory and your running HP KAIO. <ask me how I know this> > > >Wouldn't you be better off decreasing this and giving more BUFFERS? > > Would love to, guess I need to investigate why the application servers chew > up so much. Application is MIMS ERP system from Mincom, Clues on what to > look for most welcome? > > >>CKPTINTVL 1200> >onstat -m> > 17:18:16 Logical Log 64351 Complete. > 17:18:19 Logical Log 64351 - Backup Started > 17:18:30 Logical Log 64351 - Backup Completed > 17:20:28 Checkpoint Completed: duration was 5 seconds. > 17:35:25 Logical Log 64352 - Backup Started > 17:35:25 Logical Log 64352 Complete. > 17:35:36 Logical Log 64352 - Backup Completed > 17:40:44 Checkpoint Completed: duration was 4 seconds. > 17:49:37 Logical Log 64353 Complete. > 17:49:39 Logical Log 64353 - Backup Started > 17:49:51 Logical Log 64353 - Backup Completed > 17:53:32 Checkpoint Completed: duration was 4 seconds. > 18:00:48 Logical Log 64354 - Backup Started > 18:00:48 Logical Log 64354 Complete. > 18:01:00 Logical Log 64354 - Backup Completed > 18:06:14 Checkpoint Completed: duration was 3 seconds. > 18:20:34 Logical Log 64355 Complete. > 18:20:36 Logical Log 64355 - Backup Started > 18:20:48 Logical Log 64355 - Backup Completed > 18:26:21 Checkpoint Completed: duration was 3 seconds. > 18:37:39 Logical Log 64356 Complete. > 18:37:43 Logical Log 64356 - Backup Started > 18:37:55 Logical Log 64356 - Backup Completed > 18:46:39 Checkpoint Completed: duration was 7 seconds. > 19:01:48 Logical Log 64357 Complete. > 19:01:48 Logical Log 64357 - Backup Started > 19:02:00 Logical Log 64357 - Backup Completed > 19:06:58 Checkpoint Completed: duration was 7 seconds. > 19:27:15 Checkpoint Completed: duration was 4 seconds. > 19:31:05 Logical Log 64358 Complete. > 19:31:08 Logical Log 64358 - Backup Started > 19:31:20 Logical Log 64358 - Backup Completed > 19:47:32 Checkpoint Completed: duration was 4 seconds.> > >>USEOSTIME 1> >You are aware that this is slower than USEOSTIME 0 ? > > Yes but from memory I thought I needed that to get 10th of seconds on the > time stamps? Correct, but the clown is also correct this is slower as it calls gettimeofday() every time you want a DATETIME (and when the engine does internally as well. With this set to zero the gettimeofday() function is called about once a second to make sure the internal timer does not get out-of-sync. Art S. Kagel