Date: Tue, 30 Mar 2004 12:10:49 -0800 From: Sean Chittenden <sean@chittenden.org> To: Tim Traver <tt-list@simplenet.com> Cc: freebsd-performance@freebsd.org Subject: Re: shmem release Message-ID: <5686BD90-8286-11D8-89F3-000A95C705DC@chittenden.org> In-Reply-To: <6.0.1.1.0.20040330113631.01ef7ec0@mail1.simplenet.com> References: <6.0.1.1.0.20040330113631.01ef7ec0@mail1.simplenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Ok, I am running a 4.7 FreeBSD box that is a web server running apache. > > It looks like some module that I have is leaking memory, and > eventually, apache crashes on restarts becuase of this error : > > shmget() failed: No space left on device Look in your logs and see if there's an error message being logged that could help you identify what module it is. Otherwise, get a crash dump of a crashed process and run gdb on it to see if the module that's crashing is obvious from the back trace. > which means it can't get any more memory, which I understand. > > When I look at the top list, it shows me something like this : > > Mem: 140M Active, 879M Inact, 151M Wired, 181M Cache, 199M Buf, 660M > Free > > But when you look at the processes that are still up, they hardly take > up any memory. > > So, my question is this. > > Is there a way to free up Inactive memory from crashed processes ??? You don't need to worry about that. http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/admin.html#TOP- MEMORY-STATES There's a better article that I remember reading that went into great detail explaining this, but I can't seem to dig it up. > Without just rebooting the box ??? Inactive, buffered, cached, and free memory is memory that the system will use to fulfill memory allocation requests (ie, don't worry about it, your box has plenty of memory available). > I know that I need to find the source of the leaking and crashing to > begin with, but in the mean time, if it happens, I'd like to free up > the memory manually, so I can get the box running again... shmget() means you've run out of semaphores, not RAM. From postgresql's post-install-notes: To allow many simultaneous connections to your PostgreSQL server, you should raise the SystemV shared memory limits in your kernel. Here are example values for allowing up to 180 clients (tinkering in postgresql.conf also needed, of course): options SYSVSHM options SYSVSEM options SYSVMSG options SHMMAXPGS=65536 options SEMMNI=40 options SEMMNS=240 options SEMUME=40 options SEMMNU=120 You don't have a RAM issue or memory leak, but you're running into a limit for the number semaphores. Dime to dollar you've got mod_ssl installed and its using semaphore locking and not using a file. Google is your friend, this is a pretty common configuration problem/task that many run into. -sc -- Sean Chittenden
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5686BD90-8286-11D8-89F3-000A95C705DC>