Re: Reducing checkpoints

hope NO RAID 5 NO RAID 5 NO RAID 5 for starters: CKPTINTVL 360 # Check point interval (in sec) i would set it much bigger so you get a checkpoint each half hour be aware that fast recovery may take longer in case of a crash. also i assume that > PHYSFILE 250000 # Physical log file size (Kbytes)is big enough not to trigger a checkpoint. during checkpoints i would check my disks how busy they are; if 100% busy then you need to redistribute your chunks on different devs you could try and generate your own checkpoints based on dono before executeing onmode -c, execute onmode -B which will flush the buffer cache this may help however if your disks can not cope then you are still in trouble. --may be create and add a few more tempspaces.. > RESIDENT 0 # Forced residency flag (Yes = 1, No = may want to set this to resident??? Superboer. PapaKiKi schreef: > Hi,i have a database with 80gigabytes of data with 360users and up to > 400 when at peak.I use IDS 7.31 running on HP-UX 11.0 and 8 Gig of > memory.The checkpoints get to as high as 58sec at peak periods .Users > often run out of connections into informix.How can i reduce these > checkpoints to acceptable levels like 3seconds.What others measures can > help me.Below is the configuration from the onconfig.live in informix > ******************************************************************** > # > # INFORMIX SOFTWARE, INC. > # > # Title: onconfig.std > # Description: Informix Dynamic Server Configuration Parameters > # > #************************************************************************** > > # Root Dbspace Configuration > > ROOTNAME rootdbs # Root dbspace name > ROOTPATH /dev/rootdbs # Path for device containing root> dbspace > ROOTOFFSET 0 # Offset of root dbspace into device > (Kbytes) > ROOTSIZE 1000000 # Size of root dbspace (Kbytes)> > # Disk Mirroring Configuration Parameters > > MIRROR 0 # Mirroring flag (Yes = 1, No = 0) > MIRRORPATH # Path for device containing mirrored> root > MIRROROFFSET 0 # Offset into mirrored device (Kbytes)> > # Physical Log Configuration# Physical Log Configuration > > PHYSDBS rootdbs # Location (dbspace) of physical log > PHYSFILE 250000 # Physical log file size (Kbytes)> > # Logical Log Configuration > > LOGFILES 30 # Number of logical log files > LOGSIZE 5000 # Logical log size (Kbytes)> > # Diagnostics > > MSGPATH /u/informix/online.log # System message log file path > CONSOLE /dev/console # System console message path > ALARMPROGRAM /u/informix/etc/log_full.sh # Alarm program path> SYSALARMPROGRAM /u/informix/etc/evidence.sh # System Alarm program path > TBLSPACE_STATS 0> > # System Archive Tape Device > > TAPEDEV /dev/rmt/c5t3d0BEST # Tape device path > TAPEBLK 6144 # Tape block size (Kbytes)TAPEDEV > /dev/rmt/c5t3d0BEST # Tape device path > TAPEBLK 6144 # Tape block size (Kbytes) > TAPESIZE 80000000 # Maximum amount of data to put on tape > (Kbytes)> > # Log Archive Tape Device > > LTAPEDEV /dev/rmt/c5t4d0BEST dev/rmt/1m # Log tape device > pat > LTAPEBLK 6144 # Log tape block size (Kbytes) > LTAPESIZE 80000000 # Max amount of data to put on log tape > (Kbytes)> > # Optical > > STAGEBLOB # Informix Dynamic Server/Optical > staging area > > # System Configuration > > SERVERNUM 2 # Unique id corresponding to a Dynamic Server> instance > DBSERVERNAME ok_srvr # Name of default database server > DBSERVERALIASES ok_tcp # List of alternate dbservernames > NETTYPE ipcshm,1,800,CPU # Configure poll thread(s) for nettype > NETTYPE soctcp,1,100,NET # Configure poll thread(s) for> nettype > DEADLOCK_TIMEOUT 60 # Max time to wait of lock in> distributed env. > RESIDENT 0 # Forced residency flag (Yes = 1, No => 0)ERVERNUM 2 # Unique id corresponding to a Dynamic Server > instance > DBSERVERNAME ok_srvr # Name of default database server > DBSERVERALIASES ok_tcp # List of alternate dbservernames > NETTYPE ipcshm,1,800,CPU # Configure poll thread(s) for nettype > NETTYPE soctcp,1,100,NET # Configure poll thread(s) for> nettype > DEADLOCK_TIMEOUT 60 # Max time to wait of lock in> distributed env. > RESIDENT 0 # Forced residency flag (Yes = 1, No = > 0) > > MULTIPROCESSOR 1 # 0 for single-processor, 1 for> multi-processor > NUMCPUVPS 4 # Number of user (cpu) vps > SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vps> to one > > NOAGE 1 # Process aging > AFF_SPROC 0 # Affinity start processor > AFF_NPROCS 0 # Affinity number of processors> > # Shared Memory Parameters > > LOCKS 500000 # Maximum number of locks > BUFFERS 200000 # Maximum number of shared buffers > NUMAIOVPS 8 # Number of IO vps > PHYSBUFF 128 # Physical log buffer size (Kbytes)CKS > 500000 # Maximum number of locks > BUFFERS 200000 # Maximum number of shared buffers > NUMAIOVPS 8 # Number of IO vps > PHYSBUFF 128 # Physical log buffer size (Kbytes) > LOGBUFF 128 # Logical log buffer size (Kbytes)> LOGSMAX 100 # Maximum number of logical log files > CLEANERS 127 # Number of buffer cleaner processes > SHMBASE 0x0 # Shared memory base address > SHMVIRTSIZE 300000 # initial virtual shared memory segment> size > SHMADD 40000 # Size of new shared memory segments > (Kbytes) > SHMTOTAL 0 # Total shared memory (Kbytes). > 0=>unlimited > CKPTINTVL 360 # Check point interval (in sec) > LRUS 127 # Number of LRU queues > LRU_MAX_DIRTY 1 # LRU percent dirty begin cleaning> limit > LRU_MIN_DIRTY 0 # LRU percent dirty end cleaning limit > LTXHWM 50 # Long transaction high water mark> percentage > LTXEHWM 60 # Long transaction high water mark > (exclusive) > TXTIMEOUT 0x12c # Transaction timeout (in sec) > STACKSIZE 64 # Stack size (Kbytes)> > # System Page Size > # BUFFSIZE - Dynamic Server no longer supports this configuration > parameter. > # To determine the page size used by Dynamic Server on > # System Page Size > # BUFFSIZE - Dynamic Server no longer supports this configuratio

Superboer wrote: > hope NO RAID 5 NO RAID 5 NO RAID 5 > > for starters: > > CKPTINTVL 360 # Check point interval (in sec)> > i would set it much bigger so you get a checkpoint each half hour > be aware that fast recovery may take longer in case of a crash. How would this help reduce the checkpoint *duration*? I would suggest that we have some form of O/S or H/W issue here. The instance is not configured that big : BUFFERS 400Mb. LRU_MAX_DIRTY 1 - which represents about ... 4 Mb - not a lot really,and certainly not enough to cause a 58 second checkpoint. CLEANERS 127 LRUS 127 But we don't know how many chunks, nor whether KAIO is in use - presumably not KAIO 'cos RESIDENT is not set. NUMAIOVPS 8. But, to me at least, looks like something outside of the engine.