Results 1 to 9 of 9
  1. #1
    Join Date
    Oct 2005
    Posts
    12

    Unanswered: Very Bad Checkpoint Duration

    I have a very VERY bad checkpoint Duration

    02:09:50 Checkpoint Completed: duration was 9 seconds.
    02:09:50 Checkpoint loguniq 18385, logpos 0x9c3754, timestamp: 0x205edcbd

    02:09:50 Maximum server connections 69
    02:09:50 Logical Log 18385 Complete, timestamp: 0x205ee560.
    02:10:50 Checkpoint Completed: duration was 42 seconds.
    02:10:50 Checkpoint loguniq 18386, logpos 0xf45a8, timestamp: 0x20670aa3

    02:10:50 Maximum server connections 69
    02:30:09 Checkpoint Completed: duration was 390 seconds.
    02:30:09 Checkpoint loguniq 18386, logpos 0x435018, timestamp: 0x208fb824

    02:30:09 Maximum server connections 69
    02:37:26 Unloading Module <SPLNULL>
    02:37:27 Logical Log 18386 Complete, timestamp: 0x20962f28.
    02:37:43 Logical Log 18387 Complete, timestamp: 0x20975ec4.
    02:38:01 Loading Module <SPLNULL>
    02:38:19 Checkpoint Completed: duration was 37 seconds.
    02:38:19 Checkpoint loguniq 18388, logpos 0x78018, timestamp: 0x20976096

    as you see, 390 SECONDS are deadly (the highest was near 980seconds)

    LRU_MAX_DIRTY 5.000000 # LRU percent dirty begin cleaning limit
    LRU_MIN_DIRTY 2.000000 # LRU percent dirty end cleaning limit

    thats the parameter in the onconfig

    i hope someone has a good answer for mir

    greetz

  2. #2
    Join Date
    Sep 2002
    Posts
    102
    You can set your LRU_MAX_DIRTY 2 and LRU_MIN_DIRTY 1, but that is not enough. I need to see the rest of the onconfig parameters.

    Also, you need to check how busy your disks are. You might have disk contention. Try running iostat -xn 5 and check the value of %b.

  3. #3
    Join Date
    Oct 2005
    Posts
    12
    thanks for the reply
    ive tried ioatst -x 5, but didnt find the %b value (im running an suse linux 9.2)

    the onconfig find you as an attachement
    Attached Files Attached Files

  4. #4
    Join Date
    Sep 2002
    Posts
    102
    Change to:

    CKPTINTVL 300
    LRUS 16


    If you can reduce BUFFERS to 200000, then change it.

    Retain at this point:
    LRU_MAX_DIRTY 5
    LRU_MIN_DIRTY 2


    Tell me the checkpoints after the change.

  5. #5
    Join Date
    Oct 2005
    Posts
    12
    i'll give u a reply tomorrow

    thx

  6. #6
    Join Date
    Aug 2003
    Location
    Argentina
    Posts
    780
    Hi,

    Remember that NUMAIOVP >= CLEANERS.

    Gustavo.

  7. #7
    Join Date
    Dec 2003
    Location
    North America
    Posts
    146
    I think you need more LRU's for 400K buffers 'cause you could have too many dirty buffers to flush when you hit 5% dirty (depends on how fast your hardware is) , maybe change LRU_MAX_DIRTY to 1 and LRU_MIN_DIRTY to 0 if you don't want to reduce total # of buffers, and monitor the # of dirty buffers with onstat -R.

    400K buffers / 7 LRU's = 50K buffers per LRU
    flushing at 5% dirty of each LRU would be 2500 buffers x 7 LRU's which means you could potentially have 17500 buffers to flush at 5% dirty .... unless you've got incredible hardware that's too much.

    I have 250K buffers, 127 LRU's, LRU_MAX_DIRTY = 1 & LRU_MIN_DIRTY = 0 which means I start flushing buffers per LRU when I hit 19 dirty buffers & the max # of dirty buffers I could ever have is about 2400 ... very manageable.

    I do almost entirely LRU writes with this set-up & chunk writes occur at checkpoints.

    Also possible PHYSFILE might be too big; it'll automatically flush when 75% full
    so I'd keep this parameter smaller (20K works for me) but you have to experiment ... every site is different.

    In a transaction heavy system, I think you'd want to maximize LRU writes so what do you see (top of output) when executing onstat -F?

    I'm far from a guru, so here's some useful reading that will help you get going in the right direction:

    http://docs.rinet.ru/InforSmes/

    http://www.oninit.com/

    http://www.prstech.com/tips/art_kagel_tuning_tips.shtml

    http://help.sap.com/saphelp_nw04/hel...d/frameset.htm


    good luck
    Last edited by mjldba; 10-12-05 at 15:48.

  8. #8
    Join Date
    Oct 2005
    Posts
    12
    one question

    17500 buffers x 2kb = 35000kb = ~35MB

    i think thats not to much to write back or iam wrong?

  9. #9
    Join Date
    Dec 2003
    Location
    North America
    Posts
    146
    Like I said, I'm not a guru. 35MB is manageable if you're thinking of copying a 35mb file from one VG to another .... or from one server to another. Flushing 35MB of dirty buffers is another matter.

    The physical log will flush when 75% full; your phy log is 80000K which means a phy log flush of 75% is flushing 60MB which is also a huge writing task so perhaps your phy log should be smaller.

    As always, the efficiency of your hardware & your disk setup (RAID, JBOD, etc) comes into play when addressing performance issues as does using raw space (more efficient) rather than cooked space.

    I think you need to bump-up the # of LRU's & the number of CLEANERS, most people use approx. the same value for both of these parameters.

    LRUS are limited to 128 so I have LRUS set to 127 & CLEANERS set to 128 so a CLEANER thread is always available when a LRU hits the 1% dirty mark.

    Just changing LRU_MIN_DIRTY & LRU_MAX_DIRTY from 5% and 2% to new settings of 1% & 0% would increase your LRU writes & reduce checkpoint times because the maximum number of buffers that can be dirty at checkpoint time will be reduced 'cause you're doing a lot of LRU writes.

    I keep my checkpoints manageable by doing mostly LRU writes rather than CHUNK writes which, I think, are triggered by CHECKPOINT interval of 4 hours. At a checkpoint, I'm usually writing about 1100 - 1300 dirty buffers and rarely do I see a checkpoint above 2 seconds.

    Between LRU writes (frequent) and CHECKPOINTs (every 4 hours) I let the physical log take care of dirty buffers by flushing dirty buffers when it hits 75% full. You want your physical log big enough to handle your average transaction volume but you don't want it to be bigger than necessary.

    Lots of good reading in the links I posted but there's no standard "best way" to setup IDS, only guide lines & some "best practice" suggestions.
    Last edited by mjldba; 10-13-05 at 13:58.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •