Re: Slowness

"Art S. Kagel" wrote: > > Tavis Elliott wrote: > > > > * snip * > > > > > > ********** OUTPUT FROM onstat-p ********** > > > > > > > > Informix Dynamic Server Version 7.31.UC5 -- On-Line -- Up 8 days 14:55:04 > > > > -- 491520 Kbytes > > > > > > > > Profile > > > > dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached > > > > 682295405 18023000 3083027087 77.87 71759590 15652589 1036581591 93.08 > > > > > > REALLY POOR read cache %, Informix normally averages over 90%! Need more > > > buffers. > > > > > > > isamtot open start read write rewrite delete commit > > > > rollbk > > > > 1492423941 18991866 243150836 3111959883 1137426567 4844731 2152933 80738 > > > > 0 > > > > > > > > gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs > > > > 0 0 0 0 0 0 0 > > > > > > > > ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes > > > > 0 0 0 855488.77 72041.35 2699 5398 > > > > > > > > bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans > > > > 30666291 5573 3559009654 0 0 22997 4401153 1335818 > > > > > > BUFWAITS RATIO is nearly 100%! Anything over 10% is death and over 7% is > > > slow. Definitely need more LRUS and CLEANERS make both 128. > > > > Pardon my ignorance, I recently started reading the newsgroups about > > performance issues. What is the 'BUFWAITS RATIO' ? > > The bufwaits ratio is a diagnostic I reasoned out and posted here and others > have found useful, towit: > > BR = (bufwaits / (pagreads + bufwrits)) * 100% > > Because pages read from disk need a fresh buffer to write into and writes > to existing buffers (all Informix writes are to existing buffers) each > require the modification of an LRU queue and so an LRU latch. It turns out > that if there are not enough LRUS to prevent contention for them from many > clients many of the bufwaits will actually be LRU latch waits. From my own > experience and gathering the observations of others using the ratio we have > determined that any OLTP server with a BR greater than 7% is running rather > more slowly than it needs to and values over 10% always correspond to users > complaining of poor response time. Increasing LRUS and CLEANERS will > always reduce the BR until you hit the max of 128 LRUS for IDS (256 for > XPS). Or 512 for IDS on a decent platform. :-) It's at this level of tuning that the H/W decision becomes important. It's when you hit 128 LRU queues that you wish you'd gone 64 bit in the first place. ;-) Cheers, -- Mark. +----------------------------------------------------------+-----------+ | Mark D. Stock mailto:mdstock@mydas.freeserve.co.uk |//////// /| | http://www.informix.com http://www.informixhandbook.com |///// / //| | http://www.iiug.org +-----------------------------------+//// / ///| | |This email will self-destruct in |/// / ////| | |10 sec. If you received this email |// / /////| | |in error, sorry about the mess. |/ ////////| +----------------------+-----------------------------------+-----------+