Ree: long checkpoints

muchos gracias! we have 250,000 buffers - starting to think that maybe that is too many....whatever is exactly going on - we are getting this blocking information on (it seems) every checkpoint (running onstat -u and onstat -R while checkpoints run): seems i will need to somehow drilldown into what exactly is causing this BLOCKING...? : Informix Dynamic Server 2000 Version 9.21.HC5 -- On-Line (Prim) (CKPT REQ) -- Up 1 days 18:08:56 -- 1004948 Kbytes Blocked:CKPT # Shared Memory Parameters LOCKS 500000 # Maximum number of locks (8,000,000informix max; will allocate max of 15 100,000 additional blocks) # LOCKS 300000 # Maximum number of locks mb 12/4/01 BUFFERS 250000 # Maximum number of shared buffers NUMAIOVPS 2 # Number of IO vps PHYSBUFF 32 # Physical log buffer size (Kbytes) LOGBUFF 32 # Logical log buffer size (Kbytes)LOGSMAX 40 # Maximum number of logical log files CLEANERS 50 # Number of buffer cleaner processes SHMBASE 0x0 # Shared memory base address SHMVIRTSIZE 196608 # initial virtual shared memorysegment size SHMADD 32768 # Size of new shared memory segments (Kbytes) SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited CKPTINTVL 300 # Check point interval (in sec) LRUS 50 # Number of LRU queues LRU_MAX_DIRTY 4 # LRU percent dirty begin cleaning limit -- 30 changed 6/6/03 LRU_MIN_DIRTY 2 # LRU percent dirty end cleaning limit -- 25 changed 6/6/03 LTXHWM 50 # Long transaction high water markpercentage LTXEHWM 60 # Long transaction high water mark (exclusive) TXTIMEOUT 0x12c # Transaction timeout (in sec) STACKSIZE 128 # Stack size (Kbytes) ---- was 32 changed 5/10/03 "David Williams" <djw@smooth1.fsnet.co.uk> wrote in message news:<bc8dph$dt3$1@news6.svr.pol.co.uk>... > "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