RE: IDS 10 erratic run times

No, not much help, but thanks for sharing your story with us. We enjoyed it. --- "Hamilton, Jerry" <hamiltoj@fleishman.com> wrote: > I'm seeing the same problem with my v9.4 update > statistics jobs too. > I've had the same eight Update Stat jobs that run in > about 3.5 hours, in > parallel, on a 9.21 system for years. On my 9.4 > system these same jobs, > running in parallel, take almost 7 hours to run. > > I never had the time to look into my problem so I > run my jobs single > threaded on my v9.4 database now and they run in > less than 3 hours! > > Sorry that didn't help you... > > Jerry > > -----Original Message----- > From: owner-informix-list@iiug.org > [mailto:owner-informix-list@iiug.org] > On Behalf Of Neil Truby > Sent: Sunday, September 18, 2005 7:02 PM > To: informix-list@iiug.org > Subject: IDS 10 erratic run times > > IDS 10.0FC3 on Solaris 2.9 > > This is a brand new server which we are preparing to > migrate a v9 system > to. > Over the past few weeks I have run multiple > dbimports from more-or-less > the same data source - certainly the same schema - > but the import time > varies widely. > > The fastest I've done it is 9h, the slowest 14. > This weekend's took 13h > > 10m. There's never anyhting else going on on it. > In the UPDATE > STATISICS > phase the elapsed time was 3h: during the "fast" run > it was just 1h. I > had a look during this period: often onstat -p > onstat -m onstat -D would> show periods of perhaps 2 minutes with no activity > at all: no bufreads > or physreads, no checkpointing for 20 minutes (the > checkpoint interval > is 5 mins), the relevant thread just "sleeping > forever". > > I haven't changed the disk layout (a 60G database > striped across three > disks in a JBOD array with the standard Solaris LVM > interlace of 16k, > this stripe mirrored to another 3 disks identically > configured attached > to another controller on the same array); I have > experimented with > different buffer sizes (perversely one 9h run was > with BUFFERS set to > just 100,000 rather than the usual 1,000,000 > although there's no > consistent pattern to this now I've cut the LRU MIN > and MAX, and I've > had another 9h run with the 2GBytes of BUFFERS > since). > > It's the fact that all activity just seems to stop > for long periods that > puzzles me. If, during such a period, I fire up > dbaccess and run a > sysmater query it returns instantly, so I can't see > a systemic cause. > The new box is still 1.5 to twice the speed of the > old in comparative > testing but this disparity in times is just puzzling > me and I don't want > it to come back and bite us after go live. > > Any suggestions or inspiration welcome! > > thanks > Neil > sending to informix-list sending to informix-list