checkpoints and unix sync

[Jvb]

Hi,

we are having an issue with DB checkpoints. We managed to have zero buffers flushed on the checkpoints, but still we experience a freeze of 15 to 30 seconds during a checkpoint.

platform : AIX 4.3.3
progress :9.1B20
DB block size : 4 Kb
BI block size : 16K
BI cluster size : 16 MB
AI block size : 8k
2 APW's
1 BIW,
1 AIW,
-B 300000
-spin 1000

checkpoint promon output :



06/05/02 Checkpoints
11:48:49

Ckpt ------ Database Writes ------
No. Time Len Dirty CPT Q Scan APW Q Flushes

380 11:38:50 0 9617 7749 0 0 0

379 11:28:03 647 8939 8933 817 0 0
378 11:16:44 679 9997 9997 605 0 0
377 11:03:37 787 10116 10134 325 0 0
376 10:53:24 613 8928 8952 849 0 0
375 10:44:28 536 11228 11252 254 0 0
374 10:33:19 669 10420 10445 581 0 0
373 10:22:27 652 10681 10706 415 0 0


Could this be the unix SYNC issue ?

Trying a "time sync" gives results varying from 15-30 seconds.

What steps can be taken next to improve this situation and has somebody experience with this kind of issue ?


TIA.

Jurgen Van Bouchaute
ICSAT nv.

 

[ChrisPaulson]

You could get the sync deamon to run at more regular intervals or you move over to directio.

Add -directio into your .pf to do this.

If you do -directio you may need to add more apw's.

 

[MurrayH]

We say 4-8 second check points on a SunFire 6800 with 4 disk arrays and 20 CPUs. If you look ""very"" carefully at Progress' benchmark graphs you will see that they had I/O drops of about the same time. I'm assuming that these were checkpoints so some of this may be normal. More APWs may help, or it may not. Maybe reducing the number of records the APWs look at?? Not really sure.

Hope that helps

Murray

 

[fpullen]

As to why the checkpoint takes so long, that may be easy: It's writing 16MB. By creating such a large BI cluster, you're basically gambling that Progress can flush dirty buffers into the database faster than the cluster will fill. When you lose, you lose big, in that now 16MB has to be written.

By default, you have four BI clusters. If you use "bigrow," you can increase this. The syntax is "proutil dbname -C bigrow <number>", where <number> is the number of clusters MORE than four that you want. If you say "bigrow 2" for example, you'll end up with six total clusters.

This is a gamble, but I'd try increasing the number of clusters, but decreasing the cluster size. Why? If the cluster size is, for example, 8MB, then when you do encounter a checkpoint condition, it will take less time. And by having more clusters, your BI has more places to store data, so hopefully that will reduce the number of checkpoints.

I just started consulting on my own, after working for Progress customers since 1992, and for a Frontstep Business Partner off and on since 1998. I don't mind answering questions via email, though I'd certainly like to find some clients at some point, too. (Helps pay the bills, eh?)

Regards,
--Fred Pullen