RE: Checkpoints getting longer

LRUS=127 Cleaners=50 LRU_MAX_DIRTY 3 # LRU percent dirty begin cleaning limit LRU_MIN_DIRTY 0 CKPTINTVL 1800 # If you have UPS on server Wayne E. Martin Informix Database Administrator Kmart Corp. -----Original Message----- From: Elena Korol [mailto:ekorol@styleclick.com] Sent: Wednesday, December 13, 2000 6:37 PM To: informix-list@iiug.org Subject: Checkpoints getting longer Hi , I wonder if someone can give us an advise on the most effective way to reduce the checkpoints duration. IDS 9.21, Sun-Solaris 5.8, 1G RAM, max number of users is 600. Database is very right intensive, and during last moths and a half duration of the checkpoints grew from 2 sec to 8-10 sec. Sample: 14:58:44 Fuzzy Checkpoint Completed: duration was 8 seconds, 590 buffersnot flushed. 15:03:53 Fuzzy Checkpoint Completed: duration was 9 seconds, 654 buffersnot flushed. 15:09:01 Fuzzy Checkpoint Completed: duration was 7 seconds, 783 buffersnot flushed. 15:14:07 Fuzzy Checkpoint Completed: duration was 7 seconds, 1000 buffersnot flushed. 15:19:16 Fuzzy Checkpoint Completed: duration was 8 seconds, 738 buffersnot flushed. 15:24:23 Fuzzy Checkpoint Completed: duration was 8 seconds, 670 buffersnot flushed. 15:29:32 Fuzzy Checkpoint Completed: duration was 8 seconds, 735 buffersnot flushed. Here are some onconfig parameters: LOCKS 500000 # Maximum number of locks BUFFERS 200000 # Maximum number of shared buffers NUMAIOVPS 8 # Number of IO vps PHYSBUFF 32 # Physical log buffer size (Kbytes) LOGBUFF 32 # Logical log buffer size (Kbytes)LOGSMAX 35 # Maximum number of logical log files CLEANERS 8 # Number of buffer cleaner processes SHMBASE 0xa000000 # Shared memory base address SHMVIRTSIZE 600000 # initial virtual shared memory segment size SHMADD 16284 # Size of new shared memory segments (Kbytes) SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited CKPTINTVL 300 # Check point interval (in sec) LRUS 16 # Number of LRU queues LRU_MAX_DIRTY 5 # LRU percent dirty begin cleaning limit LRU_MIN_DIRTY 3 # LRU percent dirty end cleaning limit LTXHWM 50 # Long transaction high water markpercentage LTXEHWM 60 # Long transaction high water mark (exclusive) TXTIMEOUT 0x258 # Transaction timeout (in sec) STACKSIZE 32 # Stack size (Kbytes) Thank you in advance, ____________________________ Elena Korol e-mail: ekorol@styleclick.com Tel: 310-751-2164

I do not have the original post, so I will respond to this one. If tyou are using User defined data types, or large objects, I think LRU_MAX_DIRTY as suggested will have a pretty good effect. Otherwise, the only thing I can guess is that it is taking awhile for all of the processes to finish their critical sections. I would watch onstat -u for an X in position 5 during the checkpoint. Also watch i/o activity on the system during the checkpoint. If I/O is heavy, decrease LRU_MAX_DIRTY, and try to find out how to optimize your I/O. If onstat -u has sessions with an X in position 5 which is holding up the checkpoint, the only thing I can think of is you need more horsepower. FYI an X in position 5 of onstat -u means that that session is in a critical section, and the checkpoint can not complete till it finishes. Hope this helps, Will In article <91ao5o$3ji$1@news.xmission.com>, "Martin, Wayne E." <WMartin@kmart.com> wrote: > > LRUS=127 > Cleaners=50 > LRU_MAX_DIRTY 3 # LRU percent dirty begin cleaninglimit > LRU_MIN_DIRTY 0 > CKPTINTVL 1800 # If you have UPS on server> > Wayne E. Martin > Informix Database Administrator > Kmart Corp. > > -----Original Message----- > From: Elena Korol [mailto:ekorol@styleclick.com] > Sent: Wednesday, December 13, 2000 6:37 PM > To: informix-list@iiug.org > Subject: Checkpoints getting longer > > Hi , > > I wonder if someone can give us an advise on the most effective way to > reduce the checkpoints duration. > > IDS 9.21, Sun-Solaris 5.8, 1G RAM, max number of users is 600. > > Database is very right intensive, and during last moths and a half duration > of the checkpoints grew from 2 sec to 8-10 sec. > Sample: > 14:58:44 Fuzzy Checkpoint Completed: duration was 8 seconds, 590buffers > not flushed. > 15:03:53 Fuzzy Checkpoint Completed: duration was 9 seconds, 654buffers > not flushed. > 15:09:01 Fuzzy Checkpoint Completed: duration was 7 seconds, 783buffers > not flushed. > 15:14:07 Fuzzy Checkpoint Completed: duration was 7 seconds, 1000buffers > not flushed. > 15:19:16 Fuzzy Checkpoint Completed: duration was 8 seconds, 738buffers > not flushed. > 15:24:23 Fuzzy Checkpoint Completed: duration was 8 seconds, 670buffers > not flushed. > 15:29:32 Fuzzy Checkpoint Completed: duration was 8 seconds, 735buffers > not flushed. > > Here are some onconfig parameters: > > LOCKS 500000 # Maximum number of locks > BUFFERS 200000 # Maximum number of shared buffers > NUMAIOVPS 8 # Number of IO vps > PHYSBUFF 32 # Physical log buffer size (Kbytes) > LOGBUFF 32 # Logical log buffer size (Kbytes)> LOGSMAX 35 # Maximum number of logical log files > CLEANERS 8 # Number of buffer cleaner processes > SHMBASE 0xa000000 # Shared memory base address > SHMVIRTSIZE 600000 # initial virtual shared memorysegment size > SHMADD 16284 # Size of new shared memory segments > (Kbytes) > SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited > CKPTINTVL 300 # Check point interval (in sec) > LRUS 16 # Number of LRU queues > LRU_MAX_DIRTY 5 # LRU percent dirty begin cleaninglimit > LRU_MIN_DIRTY 3 # LRU percent dirty end cleaning limit > LTXHWM 50 # Long transaction high water mark> percentage > LTXEHWM 60 # Long transaction high water mark > (exclusive) > TXTIMEOUT 0x258 # Transaction timeout (in sec) > STACKSIZE 32 # Stack size (Kbytes)> > Thank you in advance, > ____________________________ > Elena Korol > e-mail: ekorol@styleclick.com > Tel: 310-751-2164 > > Sent via Deja.com http://www.deja.com/