Re: (2) Poor Performance with 7.31.uc6

A word to the wise: when you need to do your index rebuilds, set the following environment variables: PSORT_NPROCS=[2 * NUMCPUVPS] PDQPRIORITY=100 PSORT_DBTEMP=/tmp1:/tmp2:/tmp3 # i.e., 3 temporary filesystems You will be mildly impressed by the index build speed. I've been fooling about with a 100M row table, and it builds a single-column index in < 20 minutes. On a 2-way HP box. From: "Ty O'Kelly" <tokelly@maxor.invalid.com> > >Obnoxio The Clown wrote: > > > From: "Ty O'Kelly" <tokelly@maxor.invalid.com> > > >After the upgrade I performed the "Update Statistics" as noted in > > >the documentation, but I have seen a post from Clown suggesting "UPDATE > > >STATISTICS DROP DISTRIBUTIONS". Would this make a significant > > >difference? Using recent posts as a guide I am including output from > > > > Of course not! I made the suggestion purely out of spite. > >Ok, let me rephrase the question. Will the performance increase be >significant enough to justify my staying up late for however many nights it >will take to do this, since we typically do this sort of thing when the >user >load is light? Of course, if I wind up having to drop and recreate the all >indexes this might not really matter... > > > > >onstat -P | tail -5:> > > > > >Percentages: > > >Data 6.77 > > >Btree 92.40 > > >Other 0.82 > > > > This looks ugly. What is the output of > > > > onstat -B | grep " d0 " | wc -l> > 0 > > > > It really looks like you've run into the LRU priority scheduling bug? I > > could have sworn this was fixed. Can you try dropping and recreating >your > > indexes, as well as USLDD? > >I may not have much choice but to drop and recreate indexes. Sounds like I >will get to enjoy quite a few late nights. What is USLDD? I don't find a >reference to that abbreviation anywhere. > >Thanks, >Ty >-- >Ty O'Kelly >DBA >tokelly@maxor.invalid.com >806-324-5521 > > ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Obnoxio The Clown wrote: > A word to the wise: when you need to do your index rebuilds, set the > following environment variables: > > PSORT_NPROCS=[2 * NUMCPUVPS] > PDQPRIORITY=100 > PSORT_DBTEMP=/tmp1:/tmp2:/tmp3 # i.e., 3 temporary filesystems how will PDQPRIORITY=100 be affected by the onconfig parameter MAX_PDQPRIORITY which is currently10? (i am at home and don't have the fm to read.) thanks, ty

Is there a utility to rebuild indexes? or is dbschema/dbaccess the best? In article <397E269B.B55E93FF@maxor.invalid.com>, Ty O'Kelly <tokelly@maxor.invalid.com> writes >Obnoxio The Clown wrote: > >> A word to the wise: when you need to do your index rebuilds, set the >> following environment variables: >> >> PSORT_NPROCS=[2 * NUMCPUVPS] >> PDQPRIORITY=100 >> PSORT_DBTEMP=/tmp1:/tmp2:/tmp3 # i.e., 3 temporary filesystems > >how will PDQPRIORITY=100 be affected by the onconfig parameter MAX_PDQPRIORITY >which is currently10? (i am at home and don't have the fm to read.) > >thanks, >ty > > Andrew Lennard andy@kontron.demon.co.uk

Ty O'Kelly wrote: > > Obnoxio The Clown wrote: > > > A word to the wise: when you need to do your index rebuilds, set the > > following environment variables: > > > > PSORT_NPROCS=[2 * NUMCPUVPS] > > PDQPRIORITY=100 > > PSORT_DBTEMP=/tmp1:/tmp2:/tmp3 # i.e., 3 temporary filesystems > > how will PDQPRIORITY=100 be affected by the onconfig parameter MAX_PDQPRIORITY > which is currently10? (i am at home and don't have the fm to read.) PDQPRIORITY is multiplied by MAX_PDQPRIORITY so if the former is 60 and the latter is 10 the result is as if PDQPRIORITY were 6 and MAX_PDQPRIORITY were 100. Art S. Kagel