Re: checkpoint time > 15 sec.

Art S. Kagel wrote: > The incidence and impact of bufwaits due to individual buffers is minor > compared to the incidence and impact of bufwaits due to not being able > to latch an LRU queue. Why would that be a bufwait? Surely that would be a latchwait or a mutexwait. (Don't really know, myself, just speculating.) > Since there are 10s or 100s of thousands of > buffers and only 10s or 100s users the likelyhood of multiple users, > plus perhaps the occassional page cleaner, wanting to lock the same > buffer is rare. I disagree. The whole concept of LRU is that the most-recently used buffer is the most likely to be used again. This is also why write cache rates will go down if you decrease LRU_MAX_DIRTY to increase LRU writes. Also, multiple users inserting rows into the same table at the same time will try to insert them onto the same page, potentially causing bufwaits. I can increase bufwaits on my system by a factor of 5 just by lowering LRU_MAX_DIRTY from 80 to 2 and running dbaccessdemo7, when I'm the only person on the system. Here's another interesting data point: if I have two users simultaneously inserting about 100 rows into the same table, I don't get any bufwaits with LRU_MAX_DIRTY at 80, but when I lower it to 2, I get 50. My initial guess is that the writes to buffers in memory are so fast, the lock isn't held long enough to cause contention, but the writes to disk are slower, and cause contention. Help, Madison, where are you? June -- june_t@hotmail.com Grounded in Palo Alto, living on animal crackers