To know if your cache is too big run onstat -P and look at the first line
of the report which is for partnum zero (0). In the "other" column you
should see a zero or very low buffer count. If the count is significant,
most of those buffers are unused and you can probably reduce the cache by
that number unless you know that there are larger periodic tasks that will
need those buffers later.
If the cache is too small, the Buffer Turnover Rate (BTR) metric:
(((pagreads + bufwrites) / #buffers) / <fractional hours since stats were
zero'd out>)
will be high. Ideally you should be turning the cache less often than once
every six minutes which works out to a BTR of 10.00 or less. You can also
watch the onstat -P output over time to see how many pages are being
replaced or shifted from partnum to partnum over each six minute period.
That will tell you approximately how many more buffers you can likely take
advantage of.
How to estimate a good starting cache size? Ideally you want your
application's complete common working set of data to reside in memory all
day long. For some applications you can estimate that pretty well. For
example, if you know that a typical day will produce 10,000 new invoiced
and modify 2,000 older ones affecting 9,000 customers, 60,000 inventory
items from 500 vendors residing in 120 warehouses you can make that
calculation, add in some overhead for index pages. Don't forget to allow
for weekly and monthly management reports which will span more data -
although the data for those reports will not have to reside in the cache
for long, you don't want these reports to chase all of your operational
data out of the cache, so you will have to allow some extra cache to
prevent periodic batch reports from trashing OLTP performance (unless you
are using the Informix Warehouse Accelerator or a secondary server to run
those reports of course).
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions
and do not reflect on my employer, Advanced DataTools, the IIUG, nor any
other organization with which I am associated either explicitly,
implicitly, or by inference. Neither do those opinions reflect those of
other individuals affiliated with any entity with which I am affiliated nor
those of the entities themselves.
Post by joeBUFFERS too small , read cache will be poor!
So increase it , will improve the performance.
How many is suitable and reasonble ?
How can I tell that BUFFERS size is too large ?
Will too much more BUUFER hurt the system performance ?
_______________________________________________
Informix-list mailing list
http://www.iiug.org/mailman/listinfo/informix-list