Steffen DETTMER wrote:
> * Ramashish Baranwal wrote on Tue, Oct 30, 2007 at 15:06 +0530:
>
>>> The heap size will never be reduced again regardless of the
>>> amount of "free()" calls, the memory can however be reused.
>>> Therefore, if your application at one point in time needs a
>>> lot of heap space the memory consumption shown may be higher.
>>>

>> I am monitoring the memory usage for the process by using top
>> command in Linux.
>> The difference is almost an order of magnitude (few hundred MBs
>> vs. around 2 GB). Is openssl using some kind of memory caching
>> for its ssl handshake which is not getting released when the
>> handshake is over?
>>

>
> If I understood correctly Lutz said that the memory usage
> displayed by top is not neccesarily the current memory usage but
> the highest peak memory usage. It might be the case that only 100
> MB of those 2 GB are currently used.
>

Yes, only 100MB might be actually used but the 2GB would still be
reserved in memory.
To get an idea about this behavior you can write a simple program like
....
pointer = malloc(2_gigabyte);
fill_memory_with_something(pointer, 2_gigabyte);
free(pointer);
sleep(verylong);
....
and observe "top" still occupying the memory...
> I think, having a big peak may not be very surprising when
> attempting to create heaps of connections at the same time
> (meaning that probably a lot of temporary memory is used
> concurrently, maybe some certificate structures for each
> connection and so on) in contrast to sequential connections
> (where that temporary memory also appears sequentially and can
> reuse pages allocated from the system). If I calculated correctly
> (2 GB for 4000?) that would be 524 KB per connection, no idea if
> this is a reasonable value or too much.
> (hope I didn't got it too wrong, its guessed )
>

524kB does indeed not seem to be a reasonable amount of memory
used per connection. SSL read and write buffers are 16kB each
so for just the open connection I would expect a value of about
4000*2*16kB=128MB (plus some data structures, etc) so the value
observed for the sequential handling of session establishment
seems to be reasonable.

Best regards,
Lutz
__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majordomo@openssl.org