Re: dynamically allocated new shared memory segment - What is this?

From: Gary Quiring <gquiring@netlabs.net> > >We had a pause in our Informix 7.3 system today around 5:00pm. The >system just 'froze' for almost a minute. Is there something that >needs to be tuned? This is the log during that period: Yeah, there's some code in the engine that detects that it's time to go home and it just tries to complete all the work still outstanding by 5PM. >16:44:50 Logical Log 23611 Complete. >16:48:13 Logical Log 23612 Complete. >16:49:25 Checkpoint Completed: duration was 12 seconds. >16:52:56 Logical Log 23613 Complete. >16:54:41 Checkpoint Completed: duration was 13 seconds. Those are two quite long checkpoints. >16:55:05 dynamically allocated new shared memory segment (size >33554432) > >16:55:44 dynamically allocated new shared memory segment (size >33554432) This means the system was busy doing something that required a lot of virtual memory (like a big query or something? or it could be a bug) If it happens again, see if an onmode -F frees the virtual memory (check with onstat -g seg) -- if it does, it's just a temporary thing, if it doesn't, and you're sure that the thread causing the memory usage is over, you may have a bug. >16:58:20 Logical Log 23614 Complete. >17:00:17 Checkpoint Completed: duration was 32 seconds. That is one mean momma of a checkpoint -- 32 seconds? Did you do a batch load or mass update/delete? >17:04:02 Logical Log 23615 Complete. >17:05:33 Checkpoint Completed: duration was 12 seconds. >17:10:42 Checkpoint Completed: duration was 7 seconds. >17:13:00 Logical Log 23616 Complete.> >onconfig file: > >ROOTNAME rootdbs # Root dbspace name >ROOTPATH /dev/lrootdbs # Path for device containing root>dbspace >ROOTOFFSET 0 # Offset of root dbspace into device >(Kbytes) >ROOTSIZE 200000 # 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 > >PHYSDBS plogdbs >PHYSFILE 100000> ># Logical Log Configuration > >LOGFILES 100 # Number of logical log files >LOGSIZE 2500 # Logical log size (Kbytes)> ># Diagnostics > >MSGPATH /u/ifmx/online.log # System message log file path >CONSOLE /dev/console # System console message path >ALARMPROGRAM # /u/ifmx/etc/log_full.sh # Alarm program path>SYSALARMPROGRAM /u/ifmx/etc/evidence.sh # System Alarm program path >TBLSPACE_STATS 1> ># Optical > >STAGEBLOB # Informix Dynamic Server/Optical >staging area > ># System Configuration > >SERVERNUM 0 # Unique id corresponding to a Dynamic>Server in >stance >DBSERVERNAME emco1_shm # Name of default database server >DBSERVERALIASES emco1_net # List of alternate dbservernames >NETTYPE ipcshm,2,200,CPU # Configure poll thread(s) for shared>mem >NETTYPE tlitcp,2,130,NET # Configure poll thread(s) for>network >DEADLOCK_TIMEOUT 60 # Max time to wait of lock in>distributed env. >RESIDENT 1 # Forced residency flag (Yes = 1, No = >0) Try -1 >MULTIPROCESSOR 1 # 0 for single-processor, 1 for>multi-processor >NUMCPUVPS 3 # 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 1000000 # Maximum number of locks >BUFFERS 300000 # Maximum number of shared buffers >NUMAIOVPS # Number of IO vps >PHYSBUFF 32 # Physical log buffer size (Kbytes) >LOGBUFF 32 # Logical log buffer size (Kbytes)>LOGSMAX 200 # Maximum number of logical log files >CLEANERS 20 # Number of buffer cleaner processes >SHMBASE 0x82000000 # Shared memory base address >SHMVIRTSIZE 131072 # initial virtual shared memory>segment size >SHMADD 32768 # Size of new shared memory segments >(Kbytes) >SHMTOTAL 0 # Total shared memory (Kbytes). >0=>unlimited >CKPTINTVL 300 # Check point interval (in sec) >LRUS 20 # Number of LRU queues Try more LRUS and CLEANERS >LRU_MAX_DIRTY 3 # LRU percent dirty begin cleaning>limit >LRU_MIN_DIRTY 1 # LRU percent dirty end cleaning limit Try setting these to 1 and 0. But keep an eye it the LRUs (onstat -F), these settings can cause problems sometimes. >LTXHWM 40 # Long transaction high water mark>percentage >LTXEHWM 50 # Long transaction high water mark >(exclusive) >TXTIMEOUT 0x12c # Transaction timeout (in sec) >STACKSIZE 32 # Stack size (Kbytes)> > ># Recovery Variables ># OFF_RECVRY_THREADS: ># Number of parallel worker threads during fast recovery or an offline >restore. ># ON_RECVRY_THREADS: ># Number of parallel worker threads during an online restore. > >OFF_RECVRY_THREADS 10 # Default number of offline worker>threads >ON_RECVRY_THREADS 1 # Default number of online worker>threads > ># Data Replication Variables ># DRAUTO: 0 manual, 1 retain type, 2 reverse type >DRAUTO 0 # DR automatic switchover >DRINTERVAL 30 # DR max time between DR buffer >flushes (in sec) > >DRTIMEOUT 30 # DR network timeout (in sec) >DRLOSTFOUND /u/ifmx/etc/dr.lostfound # DR lost+found file path> ># CDR Variables >CDR_LOGBUFFERS 2048 # size of log reading buffer pool >(Kbytes) >CDR_EVALTHREADS 1,2 # evaluator threads >(per-cpu-vp,additional) >CDR_DSLOCKWAIT 5 # DS lockwait timeout (seconds) >CDR_QUEUEMEM 4096 # Maximum amount of memory for any CDR >queue (Kb >ytes)> ># Backup/Restore variables >BAR_ACT_LOG /tmp/bar_act.log >BAR_MAX_BACKUP 0 >BAR_RETRY 1 >BAR_NB_XPORT_COUNT 10 >BAR_XFER_BUF_SIZE 31> ># Informix Storage Manager variables >ISM_DATA_POOL ISMData # If the data pool name is changed, be >sure to > # update $INFORMIXDIR/bin/onbar. >Change to > # ism_catalog -create_bootstrap -pool ><new name> > >ISM_LOG_POOL ISMLogs > ># Read Ahead Variables >RA_PAGES # Number of pages to attempt to read>ahead >RA_THRESHOLD # Number

On Thu, 06 Apr 2000 08:02:56 BST, "Obnoxio The Clown" <obnoxio@hotmail.com> wrote: > >From: Gary Quiring <gquiring@netlabs.net> >> >>We had a pause in our Informix 7.3 system today around 5:00pm. The >>system just 'froze' for almost a minute. Is there something that >>needs to be tuned? This is the log during that period: > >Yeah, there's some code in the engine that detects that it's time to go home >and it just tries to complete all the work still outstanding by 5PM. Where's the option for 4:00pm!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >This means the system was busy doing something that required a lot of >virtual memory (like a big query or something? or it could be a bug) > >If it happens again, see if an onmode -F frees the virtual memory (check >with onstat -g seg) -- if it does, it's just a temporary thing, if it >doesn't, and you're sure that the thread causing the memory usage is over, >you may have a bug. Does this new shared memory allotment eventually get released, or do I need to restart the engine? Here's the onstat -g seg for today. Informix Dynamic Server Version 7.30.UC2 -- On-Line -- Up 6 days 03:37:55 -- 8 84736 Kbytes Segment Summary: id key addr size ovhd class blkused blkfree 1 1381386241 82000000 704643072 11604 R* 85557 459 2 1381386242 ac000000 134217728 2640 V 5039 11345 3 1381386243 b4000000 4194304 656 M 261 251 4 1381386244 b4400000 4194304 656 M 259 253 9 1381386245 b4800000 33554432 1104 V 185 3911 10 1381386246 b6800000 33554432 1104 V 73 4023 Total: - - 914358272 - - 91374 20242 > >>16:58:20 Logical Log 23614 Complete. >>17:00:17 Checkpoint Completed: duration was 32 seconds.> >That is one mean momma of a checkpoint -- 32 seconds? Did you do a batch >load or mass update/delete? Nothing special going on, but the financials are NewERA and are not written well. I see 1-6 long transactions being aborted in the log daily. We have reported this to the software vendor, but no luck in getting them to fix it. I really appeciate your help and tips. Thanks Gary Quiring