Re: shared memory error SCO install

Brian Did the instance crash or was brought down abnormally prior to startup? If so, the shared memory segments are probably still hanging around - use ipcs to view and ipcrm to remove. Do you have multiple resident instances? If so you could be specifying the same SERVERNUM. Ensure that the SERVERNUM for this instance is unique. Also check the message log for more information. HTH Sujit Brian Adams <adams@saw.net> on 06/23/99 05:47:09 PM Please respond to adams@saw.net To: informix-list@iiug.org cc: (bcc: Sujit Pal) Subject: shared memory error SCO install Why are getting this error "Fatal error inshared memory creation" Here is a copy of the possibly relevant partsof our config file: ROOTNAME rootdbs # Root dbspace name ROOTPATH /usr/informix/data/db_space # Path for device containing root dbspace ROOTOFFSET 64 # Offset of root dbspace into device (Kbytes) ROOTSIZE 100000 # Size of root dbspace (Kbytes) MULTIPROCESSOR 0 # 0 for single-processor, 1 formulti-processor NUMCPUVPS 1 # Number of user (cpu) vps SINGLE_CPU_VP 0 # If non-zero, limit number of cpu vpsto one NOAGE 0 # Process aging AFF_SPROC 0 # Affinity start processor AFF_NPROCS 0 # Affinity number of processors # Shared Memory Parameters LOCKS 2000 # Maximum number of locks BUFFERS 200 # Maximum number of shared buffers NUMAIOVPS 1 # Number of IO vps PHYSBUFF 32 # Physical log buffer size (Kbytes) LOGBUFF 32 # Logical log buffer size (Kbytes)LOGSMAX 6 # Maximum number of logical log files CLEANERS 1 # Number of buffer cleaner processes SHMBASE 0x0 # 0x82000000 # Shared memorybase address SHMVIRTSIZE 8000 # initial virtual shared memory segmentsize SHMADD 8192 # Size of new shared memory segments (Kbytes) SHMTOTAL 2048 # Total shared memory (Kbytes). 0=>unlimited CKPTINTVL 300 # 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 markpercentage LTXEHWM 60 # Long transaction high water mark (exclusive) TXTIMEOUT 0x12c # Transaction timeout (in sec) STACKSIZE 32 # Stack size (Kbytes) Thanks, byram@saw.net adams@saw.net

Sujit.Pal@BankAmerica.com wrote: : Brian : Did the instance crash or was brought down abnormally prior to startup? If : so, the shared memory segments are probably still hanging around - use ipcs : to view and ipcrm to remove. : Do you have multiple resident instances? If so you could be specifying the : same SERVERNUM. Ensure that the SERVERNUM for this instance is unique. : Also check the message log for more information. : HTH : Sujit : Brian Adams <adams@saw.net> on 06/23/99 05:47:09 PM : Please respond to adams@saw.net : To: informix-list@iiug.org : cc: (bcc: Sujit Pal) : Subject: shared memory error SCO install : Why are getting this error "Fatal error inshared memory creation" [snip] For fun and profit, try oninit -v. This little nugget will bring up the server in verbose mode, giving more clues to the reason it might die.

As I recall with SCO Openserver, the default shared memory parameter SHMMAX is set to a very low value (maybe 512 kb ). Attempts to acquire memory in excess of SHMMAX will produce the error condition you have described. Run the scoadmin kernel configuration utility and check SHMMAX to assure it exceeds your total shared memory requirement. If not, increase SHMMAX to an appropriate value and relink the kernel. Also, Informix engines will complain that SHMBASE is wrong (e.g. SHMBASE should be blah, blah) when the kernel has inadequate SHMMAX resources. Don't be misled and change SHMBASE -- the problem lies with the operating systems shared memory parameters. Generally from what I have experienced with SCO Openserver, SHMMAX is the only kernel parameter that needs to be increased, however, if you expect to use a large amount of shared memory, you may also need to increase MAXUMEM (maximum memory per user). Rob Wilson wrote: > Sujit.Pal@BankAmerica.com wrote: > > : Brian > > : Did the instance crash or was brought down abnormally prior to startup? If > : so, the shared memory segments are probably still hanging around - use ipcs > : to view and ipcrm to remove. > : Do you have multiple resident instances? If so you could be specifying the > : same SERVERNUM. Ensure that the SERVERNUM for this instance is unique. > > : Also check the message log for more information. > > : HTH > : Sujit > > : Brian Adams <adams@saw.net> on 06/23/99 05:47:09 PM > > : Please respond to adams@saw.net > > : To: informix-list@iiug.org > : cc: (bcc: Sujit Pal) > : Subject: shared memory error SCO install > > : Why are getting this error "Fatal error inshared memory creation" > > [snip] > > For fun and profit, try oninit -v. This little nugget will bring up the > server in verbose mode, giving more clues to the reason it might die.

On Fri, 25 Jun 1999 21:19:56 -0400, in article <37742ABC.B9FAE7B1@maine.rr.com>, Larry Benoit <lbenoit@maine.rr.com> wrote: >As I recall with SCO Openserver, the default shared memory parameter SHMMAX is >set to a very low value (maybe 512 kb ). Attempts to acquire memory in excess of >SHMMAX will produce the error condition you have described. Run the scoadmin >kernel configuration utility and check SHMMAX to assure it exceeds your total >shared memory requirement. If not, increase SHMMAX to an appropriate value and >relink the kernel. Also, Informix engines will complain that SHMBASE is wrong >(e.g. SHMBASE should be blah, blah) when the kernel has inadequate SHMMAX >resources. Don't be misled and change SHMBASE -- the problem lies with the >operating systems shared memory parameters. Generally from what I have >experienced with SCO Openserver, SHMMAX is the only kernel parameter that needs >to be increased, however, if you expect to use a large amount of shared memory, >you may also need to increase MAXUMEM (maximum memory per user). > The info is in the docs directory of the Informix install. > > >Rob Wilson wrote: > >> Sujit.Pal@BankAmerica.com wrote: >> >> : Brian >> >> : Did the instance crash or was brought down abnormally prior to startup? If >> : so, the shared memory segments are probably still hanging around - use ipcs >> : to view and ipcrm to remove. >> : Do you have multiple resident instances? If so you could be specifying the >> : same SERVERNUM. Ensure that the SERVERNUM for this instance is unique. >> >> : Also check the message log for more information. >> >> : HTH >> : Sujit >> >> : Brian Adams <adams@saw.net> on 06/23/99 05:47:09 PM >> >> : Please respond to adams@saw.net >> >> : To: informix-list@iiug.org >> : cc: (bcc: Sujit Pal) >> : Subject: shared memory error SCO install >> >> : Why are getting this error "Fatal error inshared memory creation" >> >> [snip] >> >> For fun and profit, try oninit -v. This little nugget will bring up the >> server in verbose mode, giving more clues to the reason it might die. -- for i in databasix.com ntrnet.net primenet.com ; do ; gburnore@$i ; done --------------------------------------------------------------------------- How you look depends on where you go. --------------------------------------------------------------------------- Gary L. Burnore | ÝÛ³ºÝ³Þ³ºÝ³³Ýۺݳ޳ºÝ³Ý³Þ³ºÝ³ÝÝÛ³ | ÝÛ³ºÝ³Þ³ºÝ³³Ýۺݳ޳ºÝ³Ý³Þ³ºÝ³ÝÝÛ³ DOH! | ÝÛ³ºÝ³Þ³ºÝ³³Ýۺݳ޳ºÝ³Ý³Þ³ºÝ³ÝÝÛ³ | ÝÛ³ 3 4 1 4 2 ݳ޳ 6 9 0 6 9 ÝÛ³ spamgard(tm): zamboni | Official Proof of Purchase ===========================================================================