Ree: long checkpoints

thanks, Rob here is our onstat -F: Fg Writes LRU Writes Chunk Writes 0 58117 306213 address flusher state data a3684614 0 I 0 = 0X0 a3684c10 1 I 0 = 0X0 a368520c 2 I 0 = 0X0 a3685808 3 I 0 = 0X0 a3685e04 4 I 0 = 0X0 a3686400 5 I 0 = 0X0 a36869fc 6 I 0 = 0X0 a3686ff8 7 I 0 = 0X0 a36875f4 8 I 0 = 0X0 a3687bf0 9 I 0 = 0X0 a36881ec 10 I 0 = 0X0 a36887e8 11 I 0 = 0X0 a3688de4 12 I 0 = 0X0 a36893e0 13 I 0 = 0X0 a36899dc 14 I 0 = 0X0 a3689fd8 15 I 0 = 0X0 a368a5d4 16 I 0 = 0X0 a368abd0 17 I 0 = 0X0 a368b1cc 18 I 0 = 0X0 a368b7c8 19 I 0 = 0X0 a368bdc4 20 I 0 = 0X0 a368c3c0 21 I 0 = 0X0 a368c9bc 22 I 0 = 0X0 a368cfb8 23 I 0 = 0X0 a368d5b4 24 I 0 = 0X0 a368dbb0 25 I 0 = 0X0 a368e1ac 26 I 0 = 0X0 a368e7a8 27 I 0 = 0X0 a368eda4 28 I 0 = 0X0 a368f3a0 29 I 0 = 0X0 a368f99c 30 I 0 = 0X0 a368ff98 31 I 0 = 0X0 a3690594 32 I 0 = 0X0 a3690b90 33 I 0 = 0X0 a369118c 34 I 0 = 0X0 a3691788 35 I 0 = 0X0 a3691d84 36 I 0 = 0X0 a3692380 37 I 0 = 0X0 a369297c 38 I 0 = 0X0 a3692f78 39 I 0 = 0X0 a3693574 40 I 0 = 0X0 a3693b70 41 I 0 = 0X0 a369416c 42 I 0 = 0X0 a3694768 43 I 0 = 0X0 a3694d64 44 I 0 = 0X0 a3695360 45 I 0 = 0X0 a369595c 46 I 0 = 0X0 a3695f58 47 I 0 = 0X0 a3696554 48 I 0 = 0X0 a3696b50 49 I 0 = 0X0 states: Exit Idle Chunk Lru can anyone tell me more about the relevance of our Fg Writes and LRU Writes and Chunk Writes? thanks again..... Rob Wilson <rob_wilson@ameritech.net> wrote in message news:<DuGFa.2662$87.1640483@newssrv26.news.prodigy.com>... > tomL wrote: > > Thanks for all the help. But we have lowered our > > LRU_MAX_DIRTY/MIN_DIRTY from 30/25 to 4/2 and still receive > > checkpoints in the 25-50 second range - way too long. We notice that > > checkpoints still seem to occur at the 5 minute CKPTINTVL interval > > (rather than the % MIN/MAX), which is surprising to me. We are > > thinking now about concentrating on whether we have too many buffers > > or if it would help to lower our CKPTINTVL setting to something like 2 > > minutes. Any ideas? > > > > > > It is better to tune the time between checkpoints by tinkering with the > physical log size. > > The LRU_MIN_DIRTY/LRU_MAX_DIRTY parameters cause LRU writes which occur > in the background. If you look at onstat -F then you wlil see FG writes > (there were no clean buffers when a clean buffer was needed), LRU writes > (caused my min/max dirty), and chunk writes (occurs at checkpoint time). > LRU writes should be higher with the lower min/max - unless something > else is going on. > > A very good discussion about checkpoint tuning can be found at: > http://www.smooth1.demon.co.uk/ifaq06.htm#6.23

"tomL" <schmotom@yahoo.com> wrote in message news:e70357eb.0306111425.75612c7e@posting.google.com... > thanks, Rob > here is our onstat -F: > > Fg Writes LRU Writes Chunk Writes > 0 58117 306213 > > can anyone tell me more about the relevance of our > Fg Writes and LRU Writes and Chunk Writes? > Fg Write= No free buffers found so a 'foreground' as oppose to 'background' write of a dirty buffer was done. i.e. the sessions blocked whilst the dirty buffer was written to disk. You have 0 which is perfect! LRU Write = write done in background as far as sessions are concerned. Sessions do not block whilst the write occurs. This is what the cleaner threads do, they start queuing I/O when LRU_MAX_DIRTY percentage of buffers are dirty and stop queuing I/O when LRU_MIN_DIRTY percentage of buffers are dirty. This is best in terms of response times for users since they do not block at checkpoint time. It is less efficient from the machine perspective since writes are not ordered (i.e. random writes rather then writes ordered by position in the chunk). Checkpoint writes = writes done at checkpoint time. At checkpoint time each cleaner a) is assigned to the next chunk in chunk id order b)sorts all dirty buffers by offset within the chunk (to reduce disk seeksm hence more efficient). c) queues all writes for the dirty buffers d) waits for KAIO or AIO threads to complete the writes e) is assigned the next chunk to work on. However whilst a checkpoint is occuring all sessions which require writes are frozen. You want almost all LRU writes to reduce checkpoint time. Get the last time from onstat -b to your buffer size in bytes (2048/4096). LRU_MIN_DIRTY * BUFFERS * <buffer size> = how many meg ? LRU_MAX_DIRTY * BUFFERS * <buffer size> = how many meg ? How many buffers do you have? > thanks again..... > > > Rob Wilson <rob_wilson@ameritech.net> wrote in message news:<DuGFa.2662$87.1640483@newssrv26.news.prodigy.com>... > > tomL wrote: > > > Thanks for all the help. But we have lowered our > > > LRU_MAX_DIRTY/MIN_DIRTY from 30/25 to 4/2 and still receive > > > checkpoints in the 25-50 second range - way too long. We notice that > > > checkpoints still seem to occur at the 5 minute CKPTINTVL interval > > > (rather than the % MIN/MAX), which is surprising to me. We are > > > thinking now about concentrating on whether we have too many buffers > > > or if it would help to lower our CKPTINTVL setting to something like 2 > > > minutes. Any ideas? > > > > > > > > > > It is better to tune the time between checkpoints by tinkering with the > > physical log size. > > > > The LRU_MIN_DIRTY/LRU_MAX_DIRTY parameters cause LRU writes which occur > > in the background. If you look at onstat -F then you wlil see FG writes > > (there were no clean buffers when a clean buffer was needed), LRU writes > > (caused my min/max dirty), and chunk writes (occurs at checkpoint time). > > LRU writes should be higher with the lower min/max - unless something > > else is going on. > > > > A very good discussion about checkpoint tuning can be found at: > > http://www.smooth1.demon.co.uk/ifaq06.htm#6.23