________________________________
From: Daniel Stenberg <daniel_at_haxx.se>
To: libcurl development <curl-library_at_cool.haxx.se>
Sent: Wed, December 22, 2010 4:19:09 PM
Subject: Re: Memory usage

On Wed, 22 Dec 2010, Kevin Baughman wrote:

> I wrote a simple program to reproduce something I have been seeing. If I run
>the program and execute the loop a lot of times the memory usage spikes. I ran
>it under >massif and after a while the memory usage was very large:

>>It would be interesting to see it compared to a run using another SSL library,
>>as from my reading it seems a lot of the memory is allocated by NSS there.

> The code to do this is below. Note that if I do not set FORBID_REUSE there
> seems to be no issue.

>> Isn't that ironic? If you keep less connections alive you use *more* memory?

>>Is this "normal" curl on Fedora, or did you build your own? Which version is it?
>>(The pem_* functions in the Massif output made me suspect the pem stuff from the
>>>>patch Fedora uses, but I did not do any analysing that got anywhere near me
>>actually casting blame on anyone.)

Yes this is the Fedora 11 curl. I tried running it on F14 as well, same memory
bloat happened there.

> Is there some kind of cleanup function or flag that I can set that will
>alleviate this? The FORBID_REUSE just illustrates the behavior I am seeing with
>the server that I >need to communicate with. It causes me to always close the
>connection.

>>No, there's no additional option. FORBID_REUSE forces connections to close and
>>not be re-used and that should cleanup most things. The notable exception would
>>>>be the session-id caching, but a session-id is not a lot of data...

-- 
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
      

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-12-22