Re: shmem release

• Previous message: Tim Traver: "shmem release"
• In reply to: Tim Traver: "shmem release"
• Next in thread: Tim Traver: "Re: shmem release"
• Reply: Tim Traver: "Re: shmem release"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Tue, 30 Mar 2004 12:10:49 -0800
To: Tim Traver <tt-list@simplenet.com>

> 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
_______________________________________________
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To unsubscribe, send any mail to "freebsd-performance-unsubscribe@freebsd.org"

• Previous message: Tim Traver: "shmem release"
• In reply to: Tim Traver: "shmem release"
• Next in thread: Tim Traver: "Re: shmem release"
• Reply: Tim Traver: "Re: shmem release"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]