From: Chuck Lam (chuck_lam@yahoo.com)
Date: Tue Aug 13 2002 - 16:09:44 EDT
Thank you the following persons who took time to reply
to my question:
Rita Workman, Harry Pfeffer, Steve Illgen, and Bill
Hassell.
It appeared that the problem that we encountered was
common in a 32-bit OS environment. I attached the
following reply from Bill Hassell which I found it to
be very informative. I would increase the SHMMAX as
others suggested on my next maintenance to see if that
helps.
Chuck
--- Bill Hassell <pooderbill@mindspring.com> wrote:
> Hi Chuck,
>
>
> > I have a K420 running HP-UX10.20.
>
> Since you are running a 32bit operating system,
> you will always have this
> problem.
>
> > "Unable to create shared memory segment of size
> > 746560. No space left on device"
>
> Very common.
>
>
> > I understood that the application failed due to
> > the
> > exhaustion of the shared memory and the problem
> > went
> > away after the reboot.
>
> Correct.
>
> > I like to see if anyone
> > has
> > any idea for me to prevent this from happeninng
> > again.
>
> There are 2 very good papers on shared memory
> mapping in /usr/share/doc:
> mem_mgt and proc_mgt. However, the underlying cause
> is starting and stopping
> processes that use shared memory, or worse, shared
> memory processes that crash
> or killing shared memory processes with kill -9!
>
> Here's what is happening. Any program can request a
> shared memory segment.
> The segment must always be contiguous so if there
> are 2 100 megs sections in
> shared memory, then a request for 150 megs will fail
> because the needed memory
> is not in one piece. Now a process runs and gets 500
> megs of shared memory but
> it crashes or is killed with kill -9. The process
> never has a chance to give
> the memory back and therefore, no other program can
> use it.
>
> The command ipcs -bmop will report on segments that
> are in use. If NATTCH=0
> and the PID shows a job number that is not actually
> there, then that segment
> is an orphan. You can remove it with ipcrm but keep
> in mind that if you
> specify the wrong ID number, it can crash other
> programs.
>
> > Is there any way for me to increase the shared
> > memory?
>
> Yes. Migrate to a 64bit machine such as the
> A-series and recompile your
> programs so they are 64bit executables. Then there
> are no practical limits for
> shared memory.
>
> > The system has been very stable and I have
> > never seen
> > this error before in this server.
>
> This is common even when stopping and restarting
> programs normally. Each
> process gets it's memory in a certain order and if
> you're approaching the 940
> meg limit for standard programs, stopping a couple
> of programs, starting
> another and the restarted the previous two will
> fragment shared memory.
>
> --
>
> Shortsig: Those that haven't lost any data are going
> to.
>
> Bill Hassell
__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
--
---> Please post QUESTIONS and SUMMARIES only!! <---
To subscribe/unsubscribe to this list, contact majordomo@dutchworks.nl
Name: hpux-admin@dutchworks.nl Owner: owner-hpux-admin@dutchworks.nl
Archives: ftp.dutchworks.nl:/pub/digests/hpux-admin (FTP, browse only)
http://www.dutchworks.nl/htbin/hpsysadmin (Web, browse & search)
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 11:02:17 EDT