Re: Online is RAM-Hungry

Hi Cosmo, First question(s): What version of OnLine? What platform/OS? Cosmo Lee wrote: > I've been called in to troubleshoot an Online installation. The problem > is that upon startup, Online immediately starts to "dynamically" > allocate additional shared memory segments. The logfile shows 10 > allocations of 8,388,608 additional memory segments (A whopping > additional 83 Meg!). I'm not sure how this is possible, given that > SHMVIRTSIZE is set to 64,536 (64 Meg?) - the system only has 96 meg of > memory total. What does onstat -g seg show? Are these segments in addition to the 64 Mb initial virtual segment? What about onstat -g mem? > Another weird thing is that they've got their chunks pointed to > "/dev/dsk"-Block slices, rather than "/dev/rdsk"-Character slices. I'm > not sure what affect this has, but the DB seems to be running ok. I've > never seen that before... This is *not good*. It will degrade performance. Unfortunately it is non- trivial to fix unless they have used symbolic links to the devices as the chunk paths. *ALWAYS* use raw devices, never cooked. *ALWAYS* use symbolic links, not real device paths as they are *much* more flexible. > In their Onconfig file, I can't seem to find anything that would need to > have 83 additional MB of memory. The following are the possibly > meaningful differences I've found. I'd appreciate it if anybody would > let me know if they see anything that looks like it might be causing the > prolem. > > theirs onconfig.std > ------ ------------ > PHYSFILE 2560 1000 > SERVERNUM 7 0 > BUFFERS 1024 200 This is very low for OLTP (unless DB is very small) but may be fine for a DSS oriented system. > PHYSBUF 2560 32 This is pretty large! > LOGBUFF 2560 32 As is this! > USERTHREADS no entry 100 > TRANSACTIONS no entry 100 > TBLSPACES no entry 200 > CHUNKS no entry 8 > DBSPACES no entry 8 These parameters disappeared in later 7.1x releases. > SHMVIRTSIZE 64536 8000 Do they need 64 Mb? Are they mainly running DSS type, parallel queries or are they mainly an OLTP shop? > TIMEOUT 0x12c 300 > STACKSIZE 256 32 Why have they changed the stack size? They should *never* do this unless advised by tech support. This may well be part of the reason for all the additional allocations. Every thread will start with 256 Kb stack instead of 32 Kb stack. > PDQPRIORITY 10 0 Again, if they are primarily OLTP, this should be 0. > (dual-processor machine, but only 1 CPU enabled) There are lots of other issues that may be relevant: How many users? Type of workload (OLTP, batch, DSS)? NETTYPE settings in ONCONFIG etc. etc. -- ------------------------------------------------------------ Chris Jenkins, Advanced Technology Group, Informix Software Standard disclaimers apply