Re: 7.22.UC1X2 Performance tuning questions....

I have been following this discussion with interest (any site which has 1GB RAM is always interesting). In article <5i0kv8$t6v@cssun.mathcs.emory.edu>, tony.edwards@bellsouth.co.nz (tony edwards) wrote: >We set the check point interval to 600 and I have checked the production >logs and we are only getting a check point every 10 minutes which means >that the PHYSBUFF setting is correct, The duration of the check point is >now always between 20-25. PHYSBUFF is not related to your actual checkpoint interval. It just defines the memory buffer used prior to flushing to Physical Log. > >We have just set LRU_MAX_DIRTY to 4 to try and reduced the check point >duration and we will see how it goes during the day and maybe go down to >as low as 2 at a later date (each 1% is 3000 pages of work on the >system). > Check the output of 'onstat -F' after some hours of typical activity. If 'Chunk writes' dominate 'LRU writes' (as I expect it will!), you can reduce your checkpoint duration by taking steps to increase your LRU writes (effectively keeping less of 'syncing' to be done during a checkpoint). LRU writes occurs between checkpoints and are asynchronous. This is the preferred method of syncing disks with Shared Memory in sites where OLTP is priority. You can increase LRU writes in at least 3 ways. 1. Reduce LRU_MAX_DIRTY - fairly obvious. 2. Reduce BUFFERS (keeping LRU_MAX..MIN constant) The number of buffers which get dirty are a factor of your OLTP activity. By reducing the number of BUFFERS, the % of dirty buffers is going to go up and more cleaning is going to take place between check points. The additional benefit is that the system has more available memory to run its processes and that may be a benefit. (We have reduced BUFFERS in our system from the recommended 25% of physical memory to close to 14% - we increased LRU_MAX from 2 to 5 to keep our avg. actual chkpoint duration at 2-3 seconds. Result - better performance, far less paging out (vmstat)) 3. Increase CKPTINTVL The larger the CKPTINTVL, the longer fast recovery will take following a system crash. As far as I can see, that is the only downside. The benefits : a) Better spread of disk writes (more LRU writes) b) Increased buffer writes (chances of overwriting a dirty page higher) c) Cumulative Checkpoint duration will reduce Caution : If required, increase the size of your physical log proportionately. Use a series of 'onstat -l's to decide. Our CKPTINTVL is currently 900, on its way up. HTH. ----------------------- Rudy Fernandes GIC, Kuwait OL 7.20UC4, 4GL 6.04UC1 -----------------------