Since upgrading from 2.4.5 to 2.5, I've noticed Pound gradually
consuming more and more memory until it has to be restarted lest it
consume all my RAM. I've observed this on both OpenBSD 4.6 i386 and
FreeBSD 8 x64.

For example, an instance that's been around for about a week now is
eating up 154MB. This instance is running a pretty limited
configuration (basically just serving as SSL termination and header
sanitization for a different app) that I've pasted below. There are
only two things I can think of that are even noteworthy:

 - Configuration flag --with-maxbuf=16384
 - The SSL certificate is a wildcard cert and I'm serving about 2000
matching subdomains

Any idea what's going on or what I can look at?

-HKS





User            "pound"
Group           "pound"
Control         "/var/run/pound-se-ctl.socket"
LogFacility     daemon
LogLevel        5
Alive           30
Client          30
ConnTO          5
TimeOut         30
Grace           30

ListenHTTP
        Address 10.2.1.83
        Port    80
        RewriteLocation 0

        HeadRemove "X-Forwarded-For"
        AddHeader  "X-Forwarded-By: pound"
        HeadRemove "X-SSL"
End

ListenHTTPS
        Address 10.2.1.83
        Port 443
        Cert "/usr/local/etc/pound/private/se.pem"
        RewriteLocation 0

        HeadRemove "X-Forwarded-For"
        AddHeader  "X-Forwarded-By: pound"
        HeadRemove "X-SSL"
        AddHeader "X-SSL: yes"
End

Service
        Backend
                Address 127.0.0.1
                Port 9083
        End
End

I discovered an issue with freeing session memory last month and Robert
integrated the fix, but we haven't had a 2.5.1 yet so it's still present in
your version.

Try replacing your svc.c with this one:
https://users.k12system.com/mrwizard/pound/svc-leakfix_unofficial.c

And let us know if you have any problems.


For that matter, did you try the base64 patch from 2/15 and how did that work
for you?

Joe
[...]

On Mon, Apr 19, 2010 at 2:41 PM, Joe Gooch <mrwizard(at)k12system.com>
wrote:[...]

Ah, I was aware of this but discounted it because it's happening even
in the "sessionless" configuration above. Presumably there is still
some internal session tracking? I'll give this a shot.

[...]

I did not. I ran into some other issues with OpenBSD around that time
and made moving to FreeBSD my top priority. Since it's still happening
on this new platform, I'll give it a shot and get back to you. Sorry
for the delay there.

-HKS
[...][...][...]

Hmm, if it's sessionless then the memory leak I found shouldn't occur.

I checked the headers code and it looks right to me... Not sure what else it
might be then.

Joe
[...]

On Tue, Apr 20, 2010 at 11:17 AM, Joe Gooch <mrwizard(at)k12system.com>
wrote:[...]


After more careful examination, I think it's safe to say that this is
not actually a memory leak. I'm sorry for the alarmist OP.

My naive understanding for anyone who sees this on their own box:
Pound runs on a thread-per-concurrent-connection model, but doesn't
allocate the space for all thread stacks right on startup. So memory
usage rises in sync with threadcount. The part that I was missing was
that it *does not* return memory used by a defunct thread back to the
OS. Instead, that space is reused for future threads until you hit
your high watermark and need to claim more memory for additional
thread stacks. The increased memory usage I was seeing was because my
traffic was growing. The increased stack size for 64-bit FreeBSD
(http://www.apsis.ch/pound/pound_list/archive/2010/2010-03/1268259652000#1268259652000)
naturally doubled the rate of memory growth, which should have been
expected but still managed to catch me off guard.

Maybe this is all common knowledge to someone more familiar with
pthreads and BSD memory management, but it was news to me.

Thanks for the help, though.

-HKS



[...][...][...]