IDS on Linux weirdnesses

Hello to all, after we had a catastrophich failure yesterday (finally the restore from tape worked and everything seems to run smoothly again) i have some questions about Linux and IDS. We made the following observations 1. - when MULTIPROCESSOR is set to 0 network connections don't work and shared memory connections work quite well - when MULTIPROCESSOR is set to 1 network connections work but shared memory connections become quite slow. Here is the problem that longer network transactions sometimes simply timeout without warning or an entry in the logs. Shared memory connections work reliably. Playing with keep alive didn't help. 2. the restore of the logical logs seems not to work. during the restore (ontape -r) the backup of the logical logs is read but the data does not appear and as the log says a logical restore didn't appear. The logs were backed up using ontape -a. No other backup activity did take place between the level0 backup and the ontape -a. --- online.log Tue Dec 28 18:39:51 1999 18:39:51 Event alarms enabled. ALARMPROG = '/opt/informix/etc/log_full.sh' 18:39:56 DR: DRAUTO is 0 (Off) 18:39:56 Requested shared memory segment size rounded from 588KB to 592KB 18:39:56 Informix Dynamic Server Version 7.30.UC7 Software Serial Number AAC# 18:39:59 Informix Dynamic Server Initialized -- Shared Memory Initialized. 18:39:59 Dataskip is now OFF for all dbspaces 18:39:59 Recovery Mode 18:40:04 Physical Restore of rootdbs, blobspace, workspace, logspace, logspace1 18:40:20 Checkpoint Completed: duration was 0 seconds. 18:40:52 Checkpoint Completed: duration was 0 seconds. 18:44:53 Checkpoint Completed: duration was 0 seconds. 18:44:53 Checkpoint Completed: duration was 0 seconds. 18:44:54 Checkpoint Completed: duration was 0 seconds. 18:44:54 Physical Restore of rootdbs, blobspace, workspace, logspace, logspace1 18:44:54 Checkpoint Completed: duration was 0 seconds. 18:46:20 Logical Recovery Started. 18:46:20 Checkpoint Completed: duration was 0 seconds. 18:46:20 Start Logical Recovery - Start Log 141, End Log ? 18:58:15 Physical Recovery Started. 18:58:16 Physical Recovery Complete: 0 Pages Restored. 18:58:16 Logical Recovery Started. 18:58:19 Logical Recovery Complete. 0 Committed, 0 Rolled Back, 0 Open, 0 Bad Locks 18:58:19 Bringing system to Quiescent Mode with no Logical Restore. I append our onconfig. Maybe someone is able to see what I did wrong. --- onconfig #************************************************************************** # # INFORMIX SOFTWARE, INC. # # Title: onconfig.std # Description: Informix Dynamic Server Configuration Parameters # #************************************************************************** # Root Dbspace Configuration ROOTNAME rootdbs # Root dbspace name ROOTPATH /opt/database/rootdbs # Path for device containing root dbspace ROOTOFFSET 0 # Offset of root dbspace into device (Kbytes) ROOTSIZE 500000 # 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 LOGFILES 13 # Number of logical log files LOGSIZE 10000 # Logical log size (Kbytes) # Diagnostics MSGPATH /opt/informix/online.log # System message log file path CONSOLE /dev/tty9 # System console message path ALARMPROGRAM /opt/informix/etc/log_full.sh # Alarm program path SYSALARMPROGRAM /opt/informix/etc/evidence.sh # System Alarm program path TBLSPACE_STATS 1 # System Archive Tape Device TAPEDEV /dev/st0 # Tape device path TAPEBLK 16 # Tape block size (Kbytes) TAPESIZE 30000000 # Maximum amount of data to put on tape (Kbytes) # Log Archive Tape Device LTAPEDEV /opt/database/logtape # Log tape device path LTAPEBLK 16 # Log tape block size (Kbytes) LTAPESIZE 1000000 # Max amount of data to put on log tape (Kbytes) # Optical STAGEBLOB # Informix Dynamic Server/Optical staging area # System Configuration SERVERNUM 0 # Unique id corresponding to a Dynamic Server in stance DBSERVERNAME express_tcp # Name of default database server DBSERVERALIASES express_shm # List of alternate dbservernames DEADLOCK_TIMEOUT 180 # 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 1 # Number of user (cpu) vps SINGLE_CPU_VP 1 # If non-zero, limit number of cpu vps to one NOAGE 0 # Process aging AFF_SPROC 0 # Affinity start processor AFF_NPROCS 0 # Affinity number of processors # Shared Memory Parameters LOCKS 80000 # Maximum number of locks BUFFERS 80000 # 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 15 # Maximum number of logical log files CLEANERS 1 # Number of buffer cleaner processes SHMBASE 0x10000000 # Shared memory base address SHMVIRTSIZE 16000 # initial virtual shared memory segment size SHMADD 16384 # Size of new shared memory segments (Kbytes) SHMTOTAL 384000 # Total shared memory (Kbytes). 0=>unlimited CKPTINTVL 1800 # Check point interval (in sec) LRUS 8 # Number of LRU queues LRU_MAX_DIRTY 60 # LRU percent dirty begin cleaning limit LRU_MIN_DIRTY 50 # 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)

Peter Eckhardt wrote: > > Hello to all, > > after we had a catastrophich failure yesterday (finally the restore from > tape > worked and everything seems to run smoothly again) i have some questions > about Linux and IDS. > > We made the following observations > > 1. > - when MULTIPROCESSOR is set to 0 network connections don't work and > shared memory connections work quite well > - when MULTIPROCESSOR is set to 1 network connections work but shared > memory connections become quite slow. Here is the problem that longer > network > transactions sometimes simply timeout without warning or an entry in > the logs. > Shared memory connections work reliably. Playing with keep alive > didn't help. I've never seen problems like this, but I suspect part of the problem is that you do not have any NETTYPE parameters in the ONCONFIG file you posted. I also do not see any physical log parameters (PHYSFILE, PHYSDBS) which are required (I don't even KNOW if there are defaults for these). Also for performance sake you should configure 1.5 AIO VP (in NUMAIOVPS) per chunk plus 3 for overhead (which of course has nothing to do with your connection problems). > 2. the restore of the logical logs seems not to work. during the restore > (ontape -r) the backup of the logical logs is read but the data does > not appear and > as the log says a logical restore didn't appear. The logs were backed > up using > ontape -a. No other backup activity did take place between the level> 0 backup > and the ontape -a. I suspect that your database was created without logging, right? If so there are no substantive log records to restore. Only system activity and DDL are logged if the database has no logging. If you are not sure, check onmonitor status>database to see the log mode of the database. BTW be sure to bring the engine to full online mode (onmode -m) after a restore and before shutting down, or your dbspaces and chunks will all be marked in an Inconsistent state when you try to start the engine again and you will have to restore all over again to fix it. Art S. Kagel