Re: Q about LatchWaits, BufWaits and LRU-Writes

Dirk Scheer wrote: [SNIP] > from 512 MB to 1 GB of memory and I've increased the BUFFERS from 40000 to > 200000. Now the performance is ok. But I wonder why the values of LatchWaits > and BufWaits are constantly growing and if this have still negative affects on > performance. See my notes below. > > Furthermore I've some problems with LRU-Writes. Although I've set the > number of LRUs to 96 and LRU_MAX_DIRTY to 1 and LRU_MIN_DIRTY to 0 the > LRU-Writes are very low (2533 LRU-Writes vs. 146712 Chunk-Writes). Can anybody Looks like you are doing this right I do not know. [SNIP] [SNIP] > > LOCKS 150000 # Maximum number of locks > BUFFERS 200000 # Maximum number of shared buffers > NUMAIOVPS 4 # Number of IO vps > PHYSBUFF 32 # Physical log buffer size (Kbytes) > LOGBUFF 32 # Logical log buffer size (Kbytes)> LOGSMAX 60 # Maximum number of logical log files > CLEANERS 48 # Number of buffer cleaner processes > SHMBASE 0x0 # Shared memory base address > SHMVIRTSIZE 40000 # initial virtual shared memory segment size > SHMADD 8192 # Size of new shared memory segments (Kbytes) > SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited > CKPTINTVL 300 # Check point interval (in sec) > LRUS 96 # Number of LRU queues I had a similar problem. We had LRUS=64 with 200000 buffers and BUFWAITS were outrageous. I heard that another user had had the same problem at 64 and after resetting LRUS to 32 they did not have the problem and we tried LRUS=128 and the problem went away. I have since been convinced that a bug in the algorithm that the oninits use to select the next LRU to try when an LRU is busy that causes many sessions to chase each other around the LRU queues at certain numbers of LRUs. I have never had time to test whether 64 was a magic number of if the problem was multi-peaked, apparently 96 is another problem number. Try 128 or 32 or some number not a power of 2. I have had no luck convincing Informix that I am not halucinating. Let me know if this helps and you can call tech support and add fuel by asking them to research for our case and attaching you results if they agree with mine. Art S. Kagel