Re: [Libevent-users] Memory won't be freed in SSL connection.

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

2011/3/8 æåè Yu-Shun Lin <ys.ncku@xxxxxxxxx>:
> Thanks for your reply.
>
> My sample code is like as yours.
> I have try some release functions are mentioned in Openssl faq
> (http://www.openssl.org/support/faq.html#PROG13) , but nothing improve.
>
> The memory usage is different between 'summary of valgrind' and 'top'.
> And I cannot locate the 'lost' memory even use the valgrind. (Neither belong
> leak nor reachable)
>
> After analysis by tcmalloc, they are in the 'heap freelist', that is to say
> the memoy already be freed but didn't retrun to OS.
>
> I think it is caused by stormy test, I use ab to test ssl server with 10k
> connections per second. There are a lot of memory fragment remain in the
> freelist.
>
> The tcmalloc library provide a function to release these memory forcedly or
> raise the free frequency.
> Ref: http://google-perftools.googlecode.com/svn/trunk/doc/tcmalloc.html

Heap fragmentation can often be solved with a better malloc
implementation; I've found that glibc's is unusually
fragmentation-prone, as are those on some older Windows versions.

Something else to look for is whether anything in the code
(libevent's, openssl's, or yours) is following the pattern of "make
many small allocations of similar size, then free most of them but
keep the rest around for a very long time."  I've found that whenever
I run into long-term fragmentation problems, that's often to blame,
though of course there are other patterns that can give this kind of
result.

If it turns out to be something Libevent is doing that is leading to
fragmentation, please let us know so we can see whether it makes sense
to do things differently.

yrs,
-- 
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.