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