We are running stunnel and noticed an issue with what ended up being an issue creating a new thread due to running out of memory at 2gb - error (8) on create_client Are there any known issues with 4.53 around memory usage? We only terminate 2 ports against the installation 443 on 2 different interfaces / IP addresses and we ran into this issue with just under 5000 total connections We are not doing ECDH , but are using a 1024-bit param file
On 2013-04-24 02:13, Michael Curran wrote:
We are running stunnel and noticed an issue with what ended up being an issue creating a new thread due to running out of memory at 2gb - error (8) on create_client
Are there any known issues with 4.53 around memory usage?
We only terminate 2 ports against the installation 443 on 2 different interfaces / IP addresses and we ran into this issue with just under 5000 total connections
What do you mean by "5000 total connections"? 5000 from opened and closed? 5000 concurrent?
I'm afraid 5000 concurrent connections may be about as many as 32-bit stunnel can handle on this platform. 64-bit build is on my TODO list, but it requires my time and money for a new compiler. This feature is currently not my top priority. Of course, as usual, a sponsor could change my priorities... http://www.stunnel.org/sdf_todo.html
Another option to improve the memory management could be LFH: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366750%28v=vs.85%2... I will try to enable it in stunnel 5.00.
Since 4.53 I have fixed memory management bugs in configuration file reload and protocol negotiations. You may try to upgrade stunnel if you use any of these features. http://www.stunnel.org/sdf_ChangeLog.html
Mike
On 2013-05-01 13:25, I wrote:
Another option to improve the memory management could be LFH: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366750%28v=vs.85%2... I will try to enable it in stunnel 5.00.
O maybe I won't. 8-) I just realized it's enabled by default on Win2K8. Implementing new features just for XP and Win2K3 doesn't really make sense anymore.
Mike
Thanks for the reply Michael -- Yes it was approx 5000 concurrent connections that caused this issue, and we came to the same conclusion -- just wanted to do a double check to rule out possibilities. Will take a look at the latest version in regards to memory management bugs you have mentioned below. We are also looking at running 2 copies of stunnel and splitting out traffic across 2 different interfaces to cut that connection total to something manageable.
Date: Wed, 1 May 2013 13:25:27 +0200 From: [email protected] To: [email protected] Subject: Re: [stunnel-users] 4.53 32-bit on Windows 2k8 R2 64bit
On 2013-04-24 02:13, Michael Curran wrote:
We are running stunnel and noticed an issue with what ended up being an issue creating a new thread due to running out of memory at 2gb - error (8) on create_client
Are there any known issues with 4.53 around memory usage?
We only terminate 2 ports against the installation 443 on 2 different interfaces / IP addresses and we ran into this issue with just under 5000 total connections
What do you mean by "5000 total connections"? 5000 from opened and closed? 5000 concurrent?
I'm afraid 5000 concurrent connections may be about as many as 32-bit stunnel can handle on this platform. 64-bit build is on my TODO list, but it requires my time and money for a new compiler. This feature is currently not my top priority. Of course, as usual, a sponsor could change my priorities...
http://www.stunnel.org/sdf_todo.html
Another option to improve the memory management could be LFH:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366750%28v=vs.85%2...
I will try to enable it in stunnel 5.00.
Since 4.53 I have fixed memory management bugs in configuration file reload and protocol negotiations. You may try to upgrade stunnel if you use any of these features.
http://www.stunnel.org/sdf_ChangeLog.html
Mike
_______________________________________________ stunnel-users mailing list [email protected] https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
-
Michael Curran -
Michal Trojnara