Re: Ratio (bufwrites + pagreads)/buffwts

----- Original Message ----- To: tstainer@styria.com At: 6/19 13:40 ----- Original Message ----- From: Thomas Stainer <tstainer@styria.com> At: 6/19 10:51 > Dear Art, > from the discussions in the iiug you seem to be a real expert on > Informix problems. Therefore I'd like to ask you two questions: > > 1) you once wrote in the iiug that the number of buffwts should not > exceed 7% of (bufwrites + pagreads), otherwise performance will suffer. > I'm running IDS 7.30 UC6 on a k360/4 engine (hp-ux 10.20) with the > following parameters: > NUMCPUVPS=4, > LRUS=8 (99% of LRUs are free LRUs) No. All of your 8 LRUS are being used. Do you mean that 99% of buffers are in the clean LRU queues rather than the dirty LRU queues? > CLEANERS=8 > BUFFERS=82000 > read cache=98.86% > write cache=96.04% > checkpoint duration 5-10 secs. With only 82000 buffers you can get this down to 3 secs on average by dropping LRU_MIN/MAX_DIRTY to 5 & 1 respectively. > Informix Performance Guide (Version 7.3, Feb. 98) recommends for these > parameters > NUMCPUVPS = number of cpus in engine > LRUS = CLEANERS ~ number of cpus (but can also be higher) This is a fine starting point but you have to monitor your own usage and bufwaits ratio to see if there is LRU contention and adjust accordingly. You cannot HURT performance until LRUS exceeds the average number of concurrent sessions. > BUFFERS = from 20 to 25% of phys. memory (in MB) that is in my case (100 > MB phys. mem) 10000 - 12500. The performance guide, however, warns of > allocating too many buffers (can lead to excess paging activity). > What do you think about these recommandations? Will performance be > improved increasing LRUS/CLEANERS and/or BUFFERS or should the least be > decreased? Again a good rule of thumb and starting point. If other apps are running and much system I/O is being performed then you need to leave more memory for the OS. On the other hand if this machine is a dedicated server and is not performing much system I/O and no other apps are running besides Informix clients, and especially if even the clients are remote, then you can steal more memory from the OS (even configuring the kernel to limit the size of the UNIX buffer pool to minimize the OS's use of memory) and increase the engine's use of memory to 50-70%! As for buffers and when you will need to add more physical memory so you can add buffers, watch you buffer turnover rate (ie number of (pagreads + bufwrits) divided by BUFFERS then divided by hours since stats were last zero'd (onstat -z or startup). If your write cache rate is low you can discount bufwrits by the cache ratio to get a truer picture but at 96% it makes little difference. You do not want to be turning over the entire buffer pool more than a few times per hour. > 2) we're planning to migrate from AutoRaid (Raid5) to XP256. I've read > the discussion in the iiug about this topic but as a real newbie in the > field of Raids, I do not know, what exactly Raid10 means? RAID10 (aka RAID1+0) is the designation give to one of the possible combinations of striping (RAID0) and mirroring (RAID1), the other being RAID01 (or RAID0+1). There used to be much confusion over the question of what was meant by RAID10 and RAID01 with many vendors using both interchangeably for different configurations. About two and half years ago I proposed the following standardization of notation: The order of the digits is the key to the difference. A RAID10 array is produced by first creating N mirrored pairs (or rarely triplets) and striping these pairs into a single stripe set. Since the RAID1 is applied first then RAID0 it is known as RAID10. An array created by building two RAID0 stripe sets and mirroring one to the other (ie RAID1) is thus known as RAID01. Both RAID01 and RAID10 perform equivalently and the difference is in recovery. RAID01 requires the entire stripe set be recovered taking more time and more resources during recovery and increasing the risk of catastrophic data loss from a second drive failure during recovery over RAID10. With RAID10 only a single mirrored pair is being recovered and one is only at risk of catastrophic data loss if the particular mirror being used for recovery fails during the shorter recovery period. Other drive pairs continue to perform at nearly 100% and if each mirrored pair is built from drives from different manufacturer's lots the risk is negligible. It is theoretically possible to build a RAID01 that is intelligent enough to recover a single drive in which case it will be functionally identical to RAID10 but I know of no such systems in production or development. Art S. Kagel