Re: Write cache rate

On 12/2/05, Christopher Coleman <Christopher.Coleman@mediware.com> wrote: >[...] > As I said, we have usually found that we need to over allocate buffers, beyond the normal > 20-25% of physical memory described in the manuals. This does not hurt us during the > day, so long as the box has plenty of memory. We try to make certain our customers have > more physical memory than they will ordinarily use, in order to avoid the disk swapping, > which we have seen become catastrophic. In my view, this is one of those ratios that was plausible back in the days of 10's of MB of main memory, but is not applicable in these days of 1000's of MB of main memory. Let's take a system with 100 MB main memory. IDS might have 25 MB shared memory; the o/s might use 10 MB (a guess - how big is the o/s buffer pool?); and you've got 65 MB left of main memory - a lot more virtual memory, of course - for the oninit processes, plus the system processes, plus the user processes. If you've got a dozen oninit processes (a couple of CPU VPs, plus an array of IO VPs, ADM, MISC, etc), then your space allocation is not too unreasonable. Let's take a system with 1 GB main memory. Your oninit processes are much the same size as before (ignoring the shared memory); the rest of the o/s is much the same as before, so you could probably think in terms of reserving say 256 MB to the system, and letting IDS use the other 3/4 GB of shared memory. Is that 75%? Oh well, I was suggesting that 20-25% was too conservative. You do the arithmetic for your machine - but if you have multiple GB of main memory, you can look towards using multiple GB for IDS shared memory, unless there's other code running on the machine that needs to use the space. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/ sending to informix-list