Re: chekcpoints, BUFFER settings, and optimization

In article <348e13e8.3351787@news.monmouth.com>, David Kosenko <dkosenko@monmouth.com> writes > David Williams <djw@smooth1.demon.co.uk> wrote: >>>INFORMIX-OnLine Version 7.22.UC1 -- On-Line -- Up 49 days 04:48:56 -- >>>85264 Kbytes >>> >>>Profile >>>dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached >>>10363 10367 1405830 99.26 3848 4447 >6678 42.38 >>> >> Why is write caching so poor? Try finding out which tables are being >>updated. select * from sysmaster:sysptntab? > Possibly unneccessary updates are occuring. Possibly updates not using indexes, hence sequential scans and lots of disk I/O. Remember checkpoint time is related to the TOTAL AMOUNT OF DISK I/O DURING THE CHECKPOINT. This including disk reads causing disk seeks and hence reducing disk response times. >Who cares? These stats, regarding write caching, are almost useless. ALL >writes are cached with online, i.e. every update occurs in memory. All that >stat tells you is how many flushes you've done relative to the number of records >updated. In order to keep checkpoint times low while maintaining maximum >possible READ caching (which DIRECTLY affects performance), you want to keep a >relatively steady stream of i/o going on at all times (assuming a brisk OLTP >profile). That means a relatively high amount of disk writes, which can drop No! Surely the whole idea is to minimize disk I/O. >the write cache. But as long as you are not thrashing the hell out of your >disks, who cares? Writes are not blocked from the transaction's perspective, >so the impact is general and thus typically diffuse in nature (as opposed to >writes occuring during checkpoints, during which time transactions are blocked >and thus drastically affected). But these writes still slow checkpoints. -- David Williams