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

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.

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

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.

i'll give u a reply tomorrow

thx

Hi,

Remember that NUMAIOVP >= CLEANERS.

Gustavo.

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****/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

one question

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

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

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.