RE: Checkpoint duration too long sometimes--no fixed pattern [105

Vineet It looks as though your dirty buffers are never reaching the 2% required to start the LRU Writes run 'onstat -R' a few times, especially just before a checkpoint, to see what percentage of buffers become dirty. Even 2% of 500000 buffers is 10000 which will take a while to write. Three ways to reduce the number of dirty buffers at checkpoint time, either reduce the overall number of buffers, reduce the LRU percentages or reduce the time between checkpoints. What are your cached percentages from onstat -p. Reduce the number of buffers until these start to decline and if this doesn't improve matters significantly then reduce LRU percentages to 1 and 0. A third alternative is to remove the responsibility for writing from the checkpoint by running onmode -B (undocumented, flushes all dirty buffers as a back-ground task) immediately before a checkpoint is due (see also a recent thread regarding this). Keith -> -----Original Message----- -> From: Vineet Mehr.... [mailto:vin_us@yahoo.com] -> Sent: Wednesday, April 30, 2003 9:52 PM -> To: ids@iiug.org -> Subject: Checkpoint duration too long sometimes--no fixed -> pattern [1054] -> -> -> -> Environment: -> -> -> Informix Dynamic Server 7.31 UD2 R1 -> -> HP-UX 11.0 -> -> As you can see below -> -> 10:44:50 Checkpoint Completed: duration was 0 -> seconds. -> 10:59:59 Checkpoint Completed: duration was 0 -> seconds. -> 11:15:08 Checkpoint Completed: duration was 0 -> seconds. -> 11:30:17 Checkpoint Completed: duration was 0 -> seconds. -> 11:45:26 Checkpoint Completed: duration was 0 -> seconds. -> 12:00:53 Checkpoint Completed: duration was 19 -> seconds. -> 12:16:02 Checkpoint Completed: duration was 0 -> seconds. -> 12:31:34 Checkpoint Completed: duration was 23 -> seconds. -> 12:46:44 Checkpoint Completed: duration was 0 -> seconds. -> 13:01:54 Checkpoint Completed: duration was 1 -> seconds. -> 13:17:05 Checkpoint Completed: duration was 2 -> seconds. -> 13:32:15 Checkpoint Completed: duration was 0 -> seconds. -> 13:47:24 Checkpoint Completed: duration was 0 -> seconds. -> 14:02:33 Checkpoint Completed: duration was 1 -> seconds. -> 14:17:43 Checkpoint Completed: duration was 1 -> seconds. -> 14:32:54 Checkpoint Completed: duration was 0 -> seconds. -> 14:48:03 Checkpoint Completed: duration was 0 -> seconds. -> 15:03:13 Checkpoint Completed: duration was 2 -> seconds. -> 15:18:23 Checkpoint Completed: duration was 0 -> seconds. -> 15:35:08 Checkpoint Completed: duration was 97 -> seconds. -> -> we have at times checkpoints of duration more than a -> minute. This is totally unacceptable in production -> environment. -> -> We are unable to diagnose a pattern for this. It could -> happen at any time throughout the day. I don't have -> any clues where to look for and what could be the -> possible reason for this behaviour. -> Here are the related checkpoint parameters which we -> have set in our environment for your reference. -> -> MULTIPROCESSOR 1 # 0 for -> single-processor, 1 for multi-processor -> NUMCPUVPS 5 # Number of user (cpu) -> vps -> SINGLE_CPU_VP 0 -> -> -> BUFFERS 500000 -> -> CLEANERS 128 -> -> CKPTINTVL 900 -> -> LRUS 128 -> -> LRU_MAX_DIRTY 2 -> -> LRU_MIN_DIRTY 1 -> -> -> Also interesting most of the times we have 0 LRU -> writes in the system and only writes happen are the -> chunkwrites at the time of checkpoint. -> -> Fg Writes LRU Writes Chunk Writes -> 0 2 14620 -> -> Are we hitting some kind of bug? Or doing something -> wrong. -> -> Any help on this is highly appreciated. -> -> Do let me know if you need more information. -> -> Thanks and regards, -> -> Vineet -> -> -> -> -> -> __________________________________ -> Do you Yahoo!? -> The New Yahoo! Search - Faster. Easier. Bingo. -> http://search.yahoo.com -> ******************************************************************************** ** This message is sent in strict confidence for the addressee only. It may contain legally privileged information. The contents are not to be disclosed to anyone other than the addressee. Unauthorised recipients are requested to preserve this confidentiality and to advise the sender immediately of any error in transmission. This footnote also confirms that this email message has been swept for the presence of computer viruses, however we cannot guarantee that this message is free from such problems. ******************************************************************************** **