Re: Gradual Performance Drop on 7.23.UC1 x86

So it sounds like 2 things at work here. One is that reordering the data (accomplished by the "create clustered index") helps as does clearing all the buffers (dropping the engine). The first one is addressable. You might consider fragmenting your table by expression. This will force the data to stay "together". What is is your read-buffer percentage? I noticed that the RA parameters are still at the defaults. If your reads access data rows as a group, you might consider increasing this. If your reads are typically one row at a time, consider DECREASING your RA values. Another item that could alter performance is OPTCOMPIND. This should be set to "0" in an OLTP style environment. What other indices are on table 2? As your index pages become fragmented, updates (and selects) will take longer. Are you using multiple VARCHAR columns? This will change the way Informix reuses space during updates and may force the engine to allocate new data pages (which will further un-order your data). Finally, consider resetting your engine stats periodically (onstat -z) and watch your cache hits. If a reboot consistently helps, you may have tripped over a bug in the way Informix is caching the table data. hope this helps.... -d The Dad wrote in message <67bm1f$8ua@scottlee.mindspring.com>... >We are having some performance problems that increase gradually over time. > >We found that we could get some relief from this by idling our client >processes and creating and dropping a clustered index on the table. This >improved performance somewhat, as did running an "UPDATE STATISTICS" on the >table, but while this helps for a while (or seems to) it will eventually >slow down. Ultimately what fixes things for another 5-7 days is to bring >Informix down, start it back up, create the cluster index and then drop it. >It is now up to its normal, speedy, self. > >Scott Lee scottlee@mindspring.com