RE: Config for new live system

Neil Comments embedded. I've not encountered Sol VM, but if I were configuring this with Veritas I would just present the disk as 6 x 36 mirrored pairs to give the opportunity of placing certain dbspaces on certain spindles. Keep rootdbs separate from loglog dbs separate from physlog dbs. Keep each temp temp dbs separate from the other and separate from each logged temp dbs. Keith -> -----Original Message----- -> From: Neil Truby [mailto:neil.truby@ardenta.com] -> Sent: Friday, September 17, 2004 8:28 AM -> To: informix-list@iiug.org -> Subject: Config for new live system -> -> I'm implementing a brand new system for a brand new Informix -> customer soon. -> It's an on-line gambling system so it will be up for months on end. -> -> It's to be IDS 7.31FC6 on a Sun SureFire v440 with 2 -> processors and 4GBytes -> of RAM, running Solaris 9. The Informix database will be -> the only thing -> running, and will be replicated via HDR to an -> identically-configured server. -> -> The database server is expected only to grow to 50Gbytes. -> The SureFire v440 -> has 4 x 36GBytes disks, and a StorEdge arrears, to be -> presented as JBOD, has -> an additional 8 x 36Gbyte disks. I'm planning to use two of -> the internal -> disks as a RAID-1 mirror boot, and use Solaris Volume -> Manager to present the -> remaining 10 as a 5 x 36 = 180 Gbyte logical volume, also -> protected with -> RAID-1. -> -> It'll be up for months on end so I need to get the initial -> config correct. -> I'd be grateful for any comments on the above layout or the proposed -> onconfig below. btw, we'll be backing up data and logs with -> onbar/ISM. -> -> thanks -> -> Neil -> -> #************************************************************ -> ************** -> # -> # INFORMIX SOFTWARE, INC. -> # -> # Title: onconfig.std -> # Description: Informix Dynamic Server Configuration Parameters -> # -> #************************************************************ -> ************** -> -> # Root Dbspace Configuration -> -> ROOTNAME rootdbs # Root dbspace name -> ROOTPATH /opt/informix/dbspaces1/rootdbs -> # Path for device containing -> root dbspace -> ROOTOFFSET 0 # Offset of root dbspace into device -> (Kbytes) -> ROOTSIZE 51200 # Size of root dbspace (Kbytes) -> -> # Disk Mirroring Configuration Parameters -> -> MIRROR 0 # Mirroring flag (Yes = 1, No = 0) Set to 1, doesn't cost anything or require anything, but if you need to use Informix Mirroring in an emergency it saves a server rebuild! -> MIRRORPATH # Path for device containing -> mirrored root -> MIRROROFFSET 0 # Offset into mirrored -> device (Kbytes) -> -> # Physical Log Configuration -> -> PHYSDBS physdbs # Location (dbspace) of physical log -> PHYSFILE 102294 # Physical log file size (Kbytes) -> -> # Logical Log Configuration -> -> LOGFILES 40 # Number of logical log files -> LOGSIZE 1024 # Logical log size (Kbytes) Seems a bit small, size each log file to handle 1 hour of work (if you know how much that will be at this stage) -> -> # Diagnostics -> -> MSGPATH /opt/informix/online_1.log # System message -> log file path -> CONSOLE /opt/informix/console_1.log # System console -> message path -> ALARMPROGRAM /opt/informix/7.31/etc/log_full.sh # Alarm -> program path -> SYSALARMPROGRAM /opt/informix/7.31/etc/evidence.sh # System -> Alarm program -> path -> TBLSPACE_STATS 1 OK for development but a performance hit for live running -> -> # System Archive Tape Device -> -> TAPEDEV /opt/informix/dbspaces1/tapedev -> TAPEBLK 16 # Tape block size (Kbytes) -> TAPESIZE 2048000 # Maximum amount of data to -> put on tape -> (Kbytes) -> -> # Log Archive Tape Device -> -> LTAPEDEV /opt/informix/dbspaces1/ltapedev # Log -> tape device -> path -> LTAPEBLK 16 # Log tape block size (Kbytes) -> LTAPESIZE 10240 # Max amount of data to put -> on log tape -> (Kbytes) -> -> # Optical -> -> STAGEBLOB # Informix Dynamic -> Server/Optical staging -> area -> -> # System Configuration -> -> SERVERNUM 1 # Unique id corresponding to -> a Dynamic -> Server instance -> DBSERVERNAME fafdb1_tcp # Name of default database server -> DBSERVERALIASES fafdb1_shm # List of alternate dbservernames -> NETTYPE tlitcp,2,100,NET -> DEADLOCK_TIMEOUT 60 # Max time to wait of lock -> in distributed -> env. -> RESIDENT 0 # Forced residency flag (Yes -> = 1, No = 0) Better to set Resident. -> -> MULTIPROCESSOR 1 # 0 for single-processor, 1 for -> multi-processor -> NUMCPUVPS 2 # 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 50000 # Maximum number of locks -> BUFFERS 1024000 # Maximum number of shared buffers Seems a bit large (total of 2Gb buffer space) I know the engine is all that is running, but with LRU_MAX and MIN of 60 and 50 you will be potentially writing 1Gb to disk at each checkpoint. Try 500000 and only increase if you get buffer contention or ovr-buffers. -> NUMAIOVPS 2 # Number of IO vps -> PHYSBUFF 32 # Physical log buffer size (Kbytes) -> LOGBUFF 32 # Logical log buffer size (Kbytes) -> LOGSMAX 60 # Maximum number of logical log files -> CLEANERS 29 # Number of buffer cleaner processes Make this the same as the number of LRUS -> SHMBASE 0x10a000000 # Shared memory base address -> SHMVIRTSIZE 768000 # initial virtual shared -> memory segment size -> SHMADD 81920 # Size of new shared memory segments -> (Kbytes) -> SHMTOTAL 0 # Total shared memory -> (Kbytes). 0=>unlimited -> CKPTINTVL 300 # Check point interval (in sec) -> LRUS 32 # Number of LRU queues This would be better as 31 or 33 -> LRU_MAX_DIRTY 60 # LRU percent dirty begin -> cleaning limit -> LRU_MIN_DIRTY 50 # LRU percent dirty end -> cleaning limit Change after monitoring checkpoints -> LTXHWM 50 # Long transaction high water mark -> percentage -> LTXEHWM 60 # Long transaction high water mark -> (exclusive) -> TXTIMEOUT 0x12c # Transaction timeout (in sec) -> STACKSIZE