Re: BUFFERS setting

This is a multi-part message in MIME format. --------------4F2687A743 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bill Ennis wrote: > > You need to consider that you will be reading from the buffers as well > as writing to them. > > I would be careful lowering since your read cache percentage is already > lower than the suggested 95%. Neil Truby wrote: > } I'm running OnLine 7.13 on a Sun Sparcserver 20. It has 160M of physical > } memory. We have a bought-in application which is very resource hungry. > } At the suggestion of Tech Support I bumped BUFFERS up to 20K > } (40MBytes). However, onstat -b consistently shows only a few hundred of > } the 20,000 BUFFERS modified at any one time. Am I correct in inferring > } that I therefore have BUFFERS too high, and could begin to reduce it > } until I notice degradation in my read/write cache percentages (currently > } 93 and 87 respectively)? Bill is absolutely correct. In fact, trying to tune buffers based on write cacheing is pointless. Write cacheing as reported is really meaningless, as ALL writes are cached - we NEVER write directly to disk when updating/inserting/deleting a row, it is ALWAYS done via the buffer pool. What write cache is telling you is the ratio of database updates to page flushes. What really controls that is your checkpoint interval and LRU flushing parameters. Decrease checkpoint interval and increase LRU_MAX_DIRTY, and your write cache rate will go up (NOTE: THIS DOES NOT CONSTITUTE A RECOMMENDATION, but is simply a point of discussion. DO NOT do this tuning to your system except as an exercise in curiousity). Therefore, when tuning BUFFERS, tune for read cacheing, as that is what affects performance. The only time you need to consider tuning buffers for writes is when you are seeing fg writes in onstat -F (which means not enough buffers for the update activity occurring), which means you need more of em. Furthermore, Neil is looking at things incorrectly. Onstat -b simply shows you which buffers are LATCHED at the current time, which means the buffer itself is being modified at that time. It does not indicate that the buffer is dirty (i.e. contains modified but unflushed data), and thus is no indication of the write performance of the system. Generally speaking, the method for tuning BUFFERS is rather obvious: keep increasing it until you see no improvement in the read cache value. -- Dave Kosenko, Informix Software, Inc. --------------4F2687A743 Content-Type: text/plain; charset=us-ascii; name="Disclaim" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Disclaim" ************************************************************************* Disclaimer: All opinions expressed in this message are well-reasoned and insightful; needless to say, they are not those of Informix Software, its partners or lackeys. Anyone who says otherwise is itching for a fight. --------------4F2687A743--