RE: Best way to config OWS on SCO box

See comments below... > -----Original Message----- > From: Steven L Cooper [mailto:scooper@thecompounders.com] > Sent: Tuesday, December 28, 1999 2:08 PM > To: informix-list@iiug.org > Subject: Best way to config OWS on SCO box > > > Howdy, > We are running SCO 5.0.4 on a 4-way (P200) Intel DG AV/3600 > Running RAID5 (yes Art, I know this is bad) w/100+ users > using 4GL based > OE/IC/AR/etc. > > I have tried to "tune" the config for OLTP per suggestions from this > newgroup over the years and the good news is that is runs OK > most of the > time...but I feel that it should be better than OK. Should I > expect "good" > performance on this box w/OWS? > > I do not want to do anything major at this point (even if I > could take the > system down!) because we are buying a bigger/faster server > next week, so any > help ya'll can give me that is "quick and dirty" to make the > users happy > until I can setup the new server would be great! > > Of course any suggestions for my new server (4-way Xeon 550s) > setup (I know > my logs are too big, etc.) would be great also! > > Thanks, > Steve > > Details below: > $ onstat -p> > INFORMIX-OnLine Version 7.20.UC2 -- On-Line -- Up 18:28:49 -- 112616 Kbytes > > Profile > dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached > 3086067 4180218 119925341 97.43 153417 253147 656013 76.61 > > isamtot open start read write rewrite delete commit rollbk > 20515282 455288 1903144 10703740 230826 69360 91159 51334 51 > > ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes > 0 0 0 5251.65 1278.36 18 54 > > bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans > 474976 87 28812323 0 0 35 25181 107350 > > ixda-RA idx-RA da-RA RA-pgsused lchwaits > 1786162 34335 741556 2541548 16452 > > $ onstat -m> > INFORMIX-OnLine Version 7.20.UC2 -- On-Line -- Up 18:29:10 -- 112616 Kbytes > > Message Log File: /inxsys/informix/etc/online.log > > 06:27:39 Logical Log 360 Complete. > 06:39:33 Checkpoint Completed: duration was 3 seconds. > 07:25:04 Checkpoint Completed: duration was 4 seconds. > 08:10:33 Checkpoint Completed: duration was 2 seconds. > 08:56:03 Checkpoint Completed: duration was 2 seconds. > 09:36:17 Logical Log 361 Complete. > 09:41:38 Checkpoint Completed: duration was 6 seconds. > 10:27:09 Checkpoint Completed: duration was 3 seconds. > 11:00:31 Checkpoint Completed: duration was 4 seconds. > 11:25:19 Checkpoint Completed: duration was 5 seconds. > 12:08:00 Checkpoint Completed: duration was 4 seconds. > 12:38:12 Logical Log 362 Complete. > 12:53:11 Checkpoint Completed: duration was 5 seconds. > 13:38:19 Checkpoint Completed: duration was 4 seconds. > 14:06:01 Checkpoint Completed: duration was 5 seconds. > 14:35:52 Checkpoint Completed: duration was 7 seconds. > 15:07:35 Checkpoint Completed: duration was 4 seconds. > 15:23:21 Logical Log 363 Complete. > 15:36:22 Checkpoint Completed: duration was 5 seconds.> > $ onstat -F> > INFORMIX-OnLine Version 7.20.UC2 -- On-Line -- Up 18:30:37 -- 112616 > Kbytes > > > Fg Writes LRU Writes Chunk Writes > 9 102908 1633 > > address flusher state data > 11c38448 0 I 0 = 0X0 > 11c3887c 1 I 0 = 0X0 > 11c38cb0 2 I 0 = 0X0 > 11c390e4 3 I 0 = 0X0 > 11c39518 4 I 0 = 0X0 > 11c3994c 5 I 0 = 0X0 > 11c39d80 6 I 0 = 0X0 > 11c3a1b4 7 I 0 = 0X0 > 11c3a5e8 8 I 0 = 0X0 > 11c3aa1c 9 I 0 = 0X0 > 11c3ae50 10 I 0 = 0X0 > 11c3b284 11 I 0 = 0X0 > 11c3b6b8 12 I 0 = 0X0 > 11c3baec 13 I 0 = 0X0 > 11c3bf20 14 I 0 = 0X0 > 11c3c354 15 I 0 = 0X0 > states: Exit Idle Chunk Lru > > Here is my config: > #************************************************************* > ************* > # > # INFORMIX SOFTWARE, INC. > # > # Title: onconfig.ows > # Description: INFORMIX-OnLine Configuration Parameters > # > #************************************************************* > ************* > > # Root Dbspace Configuration > > ROOTNAME rootdbs # Root dbspace name> ROOTPATH dev/data/ROOTDATA.DS > ROOTOFFSET 0 # Offset of root dbspace into device > (Kbytes) > ROOTSIZE 300000 # Size of root dbspace (Kbytes)> > # Disk Mirroring Configuration Parameters > > MIRROR 0 # Mirroring flag (Yes = 1, No = 0) > MIRRORPATH /data2/IFMXDATA/pcca/ROOTMIRR.000 You must set MIRROR to 1 in order to enable Informix mirroring. With this combination of values, I doubt that your rootdbs is being mirrored. > MIRROROFFSET 0 # Offset into mirrored device (Kbytes)> > # Physical Log Configuration > > PHYSDBS rootdbs # Location (dbspace) of physical log > PHYSFILE 5000 # Physical log file size (Kbytes) You should move your physical log out of the rootdbs. > > # Logical Log Configuration > > LOGFILES 9 # Number of logical log files > LOGSIZE 18000 # Logical log size (Kbytes)> > # Diagnostics > > MSGPATH /inxsys/informix/etc/online.log # System > message log file > path > CONSOLE /dev/tty02 # System console message path > ALARMPROGRAM /inxsys/informix/etc/log_full.sh # Alarm program path> > # System Archive Tape Device > > TAPEDEV /dev/rStp0 > TAPEBLK 20 # Tape block size (Kbytes) > TAPESIZE 3999999 # Maximum amount of data to put on tape (Kbytes)> > # Log Archive Tape Device > > LTAPEDEV /dev/null > LTAPEBLK 20 # Log tape block size (Kbytes) > LTAPESIZE 3999999 # Max amount of data to put on log tape (Kbytes)> > # Optical > > STAGEBLOB # INFORMIX-OnLine/Optical staging area > > # System Configuration > > SERVERNUM 0 # Unique id corresponding to a OnLineinstance > DBSERVERNAME pcca # Name of default database server > DBSERVERALIASES pcca_shm # List of alternate dbservernames > NETTYPE tlitcp,1,150,NET > NETTYPE ipcshm,1,150,CPU > DEADLOCK_TIMEOUT 60 # Max time to wait of lock in distributed env. > RESIDENT 0 # Forced residency flag (Yes = 1, No = 0) > > MULTIPROCESSOR 0 # 0 for single-processor, 1 formulti-processor > NUMCPUVPS 1 # Number of user (cpu) vps > SINGLE_CPU_VP 0 # If non-zero, limi

"Bernstein, Rick" wrote: > > See comments below... > > > -----Original Message----- > > From: Steven L Cooper [mailto:scooper@thecompounders.com] > > Sent: Tuesday, December 28, 1999 2:08 PM > > To: informix-list@iiug.org > > Subject: Best way to config OWS on SCO box [SYNC] > > MIRROR 0 # Mirroring flag (Yes = 1, No = 0) > > MIRRORPATH /data2/IFMXDATA/pcca/ROOTMIRR.000 > > You must set MIRROR to 1 in order to enable Informix mirroring. > With this combination of values, I doubt that your rootdbs is being > mirrored. Oo, good catch Rick I missed that and the log location. > > MIRROROFFSET 0 # Offset into mirrored device (Kbytes)> > > > # Physical Log Configuration > > > > PHYSDBS rootdbs # Location (dbspace) of physical log > > PHYSFILE 5000 # Physical log file size (Kbytes)> > You should move your physical log out of the rootdbs. > > > > > # Logical Log Configuration > > > > LOGFILES 9 # Number of logical log files > > LOGSIZE 18000 # Logical log size (Kbytes)While you're at it the logical logs should be on a different disk than either the rootdbs or the physical log for best performance. [SNIP] > > LRU_MAX_DIRTY 2 # LRU percent dirty begin cleaning limit > > LRU_MIN_DIRTY 0 # LRU percent dirty end cleaning limit> > Your write cache % is lower than desired and very few of your writes > are chunk writes. Chunk writes are the most efficient writes and they > occur > during checkpoints. Try increasing LRU_MAX_DIRTY and LRU_MIN_DIRTY > gradually. > If you make these values too large, your checkpoints will take too long > (and users will complain). I have to disagree with you Rick. I know, the manual says that chunk writes are most efficient, and from the standpoint of minimizing the impact of the engine on the system overall that is true. HOWEVER, from the standpoint of minimizing the impact on the Informix engine itself you want as many of the page writes as possible to be LRU Writes NOT Chunk Writes. I prefer that from 65 to 100% of my writes by LRU writes for best engine throughput. As you note too much chunk writing will mean longer checkpoints which stop all update activity and pause any queries running in CPU VP #1 from the time the checkpoint begins until the buffers are flushed, usually about 1/2 of the checkpoint duration. This is true of all versions I have tested through 7.30 (I have been assured that the algorithms were rewritten for 7.31 so that the pause in queries does not happen anymore but I have not tested it myself). [SNIP] > > OPTCOMPIND 2 # To hint the optimizer> > For OLTP applications, OPTCOMPIND ususally provides better results. I think you intended to say that OPTCOMPIND set to zero (0) usually provides better results. Art S. Kagel

Thanks for the help Art and Rick... Just to fill in the blanks...see below... >> > MIRROR 0 # Mirroring flag (Yes = 1, No = 0) >> > MIRRORPATH /data2/IFMXDATA/pcca/ROOTMIRR.000 >> >> You must set MIRROR to 1 in order to enable Informix mirroring. >> With this combination of values, I doubt that your rootdbs is being >> mirrored. > >Oo, good catch Rick I missed that and the log location. That is true, but I stopped mirroring because it seemed silly with my RAID5 configuration since (as Art as schooled me over the years) if it goes bad, a mirror will not save me... >> during checkpoints. Try increasing LRU_MAX_DIRTY and LRU_MIN_DIRTY >> gradually. >> If you make these values too large, your checkpoints will take too long >> (and users will complain). > >I have to disagree with you Rick. I know, the manual says that chunk writes >are most efficient, and from the standpoint of minimizing the impact of the >engine on the system overall that is true. HOWEVER, from the standpoint of >minimizing the impact on the Informix engine itself you want as many of the >page writes as possible to be LRU Writes NOT Chunk Writes. I prefer that >from 65 to 100% of my writes by LRU writes for best engine throughput. As >you note too much chunk writing will mean longer checkpoints which stop all >update activity and pause any queries running in CPU VP #1 from the time the >checkpoint begins until the buffers are flushed, usually about 1/2 of the >checkpoint duration. This is true of all versions I have tested through >7.30 (I have been assured that the algorithms were rewritten for 7.31 so >that the pause in queries does not happen anymore but I have not tested it >myself). That has been my result also in my OLTP situation. The users do not care about chunk writes! All they know is the computer "stopped" and start yelling. When I was able to move the work to LRUs, the "steady-state" all day long was smoother (to the users) instead of doing the chunk write at checkpoints. > >[SNIP] >> > OPTCOMPIND 2 # To hint the optimizer>> >> For OLTP applications, OPTCOMPIND ususally provides better results. > >I think you intended to say that OPTCOMPIND set to zero (0) usually provides >better results. That answers my next question! If I am reading the docs right, I think I want this to be 0 to use my indexes? I have had problems with it NOT using an index. SE seems to always use any index, so on my development box everything is cool, but OWS was "deciding" to ignore the index... Thanks again! Steve