Re: Adding BUFFERS slowed Checkpoints

In order I would: 1. Set LRU_MAX_DIRTY to 2. (Start LRU writes sooner...) 2. Shorten the checkpoint interval. (Less time to make dirty pages...) 3. Slowly reduce buffers as long as hit ratio stays acceptable. Buffers seem a bit high, how is your paging rate?? 4. Use your favorite reorg technique to minimize extents, and optimize / rebuild indexes. 5. Check App code to reduce sequential scans. 6. Get disk arrays with enough (static) memory to do staged writes at checkpoint time. That'll sure light a fire under things, but is more difficult and expensive. Since you are only writing about 1MByte per checkpoint, this probably can be avoided. It's those 100 Megabyte checkpoints that are a bear.... ;-) Greg p.s. use "onstat -g seg " to verify only 3 shared memory segments. Additional virtual pool segments *really* hose throughput on HP machines. David & Adina Samson wrote: > > We had a system with which had a cache read hit rate of 94%. > Originally, the BUFFERS parameter were set to 26,000 (i.e. 52Mb). Since > the machine has 512Mb, we increased the BUFFERS to 132,000 (i.e. > 264Mb). This improved the cache hit rate issue. However, it actually > caused some problems. > > Our LRU_MAX_DIRTY and MIN_DIRTY are 3 & 1, respectively. Our > system doesn't write enough to hit the MAX dirty (3% * 132000 buffers = > 3960 dirty pages). Therefore, the cleaner threads aren't being used > and all writing is being done at checkpoint time. (On average, we're > writing about 500 pages per checkpoint.) These checkpoints have taken > about 4-5 seconds. In our environment, that's too long. > > How do we shorten the checkpoints? I need them to be on the > order of 1 second each. > Are there kernel parameters that need to be changed when we > increase the BUFFERS so high? > > We're running OnLine 7.22.UC1 under HP-UX 10.20. snip...