Re: out of virtual shared memory

In article <530p0d$o12@cssun.mathcs.emory.edu>, Ralph.Halter@pac.panmail.com writes >Hi all! > >We're running OnLine 7.10.UD1 on AIX 4.1.2 on an RS6000-J30 with 256MB memory >and 480MB paging space. There are 15 uniface developers/users filling about >50MB of logical logs per day with a peak of 30 concurrent users. > >My question: Why can't OnLine free some memory instead of just adding >more and more virtual segments? > It only adds them when needed. It does not free them for performance reasons. It you need an extra segment at any one time it assumes you may well need it again on a regular basis and so does not free it. otherwise it would keep on added and freeing it which takes time and so decreases performance. >The case: >Just lately (as always for no apparent reason, no new release or programs,...) >we are getting ugly error messages in our OnLine logfile >... >2:53:30 Checkpoint Completed: duration was 1 seconds. >12:54:51 dynamically allocated new shared memory segment (size 8388608) >12:58:35 Checkpoint Completed: duration was 4 seconds. >13:23:36 Checkpoint Completed: duration was 0 seconds. >13:28:17 shmat: [EINVAL][22]: shared memory base address illegal >13:28:17 using 0xd0000000, needs 0xffffffff >13:28:17 out of virtual shared memory >13:28:17 shmat: [EINVAL][22]: shared memory base address illegal >13:28:17 using 0xd0000000, needs 0xffffffff >13:28:17 out of virtual shared memory >...> Also check your release notes in $INFORMIXDIR/release for more info, especially ONLINE_7.1. It may well recommend a new value of SHMBASE in your ONCONFIG file. >When I saw this message today I checked with onstat -g seg and saw that >we have the following segments >id key addr size ovhd class blkused blkfree >98305 1381451777 30000000 70541312 1880 R 8607 4 Resident segment size is segment 70MB, this is for fixed size tables and mainly dependent on the number of BUFFERS configured. >98306 1381451778 40000000 30720000 1064 V 2529 1221 One vritual segment. >77827 1381451779 50000000 557056 604 M 65 3 One message segment used to send messages to/from client, size not configurable. >plus seven additional virtual segments with a size of 8388608 of which >most of the space was "used". The onmode -F freed so much of the space >that one or two virtual segments would have been more than sufficient. > Your initial segment size and additional segment size are set far too low. >Is it my uniface/polyserver clients blocking the memory? Well at a maximum they use 30 + 7*8 = 86Mb of memory. >Is my ONCONFIG not appropriate? The SHMTOTAL is set to 200MB so there would be some left in case of a unix emergency - is this smart but wrong? Yes see below. > >SHMBASE 0x30000000 # Shared memory base address >SHMVIRTSIZE 30000 # initial virtual shared memory segment size >SHMADD 8192 # Size of new shared memory segments (Kbytes) >SHMTOTAL 200000 # Total shared memory (Kbytes). 0=>unlimited> SHMBASE <Value from release notes> # Shared memory base address SHMVIRTSIZE 100000 # initial virtual shared memory segment size SHMADD 16384 # Size of new shared memory segments (Kbytes) >SHMTOTAL 0 # Total shared memory (Kbytes). 0=>unlimited Limiting the amount of shared memory using SHMTOTAL is rarely a good idea. THings will start to fail once SHMTOTAL is reached. Why have things fail when the swap space is available to let them succeed. OK they will run slowly but surely that is better than them failing. >Hints on how to track memory usage or remedy the above problem will be >accepted gratefully. Use onstat -u to a list of sessions ids. Then onstat -g ses <session id>. Note also onstat -g sql <session id> show the current sql statement for that sesion.>Sorry for the somewhat lengthy message - PLEASE do not >include the whole thing in your reply! > Sorry, needed too. -- David Williams