shmem release

Sean Chittenden sean at chittenden.org
Tue Mar 30 12:10:59 PST 2004


> 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



More information about the freebsd-performance mailing list