[erlang-questions] Garbage Collection, BEAM memory and Erlang memory
Wed Mar 4 18:12:23 CET 2015
Interesting. What kind of load were you throwing at stud that it couldn’t handle? We terminate all our SSL using stud. We easily do >2000 handshakes per second and as much as 8Gb/s per server. Granted, these are pretty beefy boxes, but the only part of the stud setup that doesn’t scale for us is when we’re trying to scale up past 1.5M external connections (which means 4.5M sockets).
From: Roberto Ostinelli <roberto@REDACTED<mailto:roberto@REDACTED>>
Date: Wednesday, March 4, 2015 at 7:56 AM
To: Benoit Chesneau <bchesneau@REDACTED<mailto:bchesneau@REDACTED>>
Cc: Erlang Questions <erlang-questions@REDACTED<mailto:erlang-questions@REDACTED>>
Subject: Re: [erlang-questions] Garbage Collection, BEAM memory and Erlang memory
It stabilized impressively the whole thing.
I also tried HAproxy (single CPU), and stud. Both were far from being able to handle the load that I'm throwing at them. I mean, *far*.
On Wed, Mar 4, 2015 at 1:08 PM, Benoit Chesneau <bchesneau@REDACTED<mailto:bchesneau@REDACTED>> wrote:
On Thu, Feb 26, 2015 at 12:56 PM, Roberto Ostinelli <roberto@REDACTED<mailto:roberto@REDACTED>> wrote:
Ah yes, indeed. The SSL processes I keep forgetting about.
I'm tempted to do another run with this option in.
Did you have any success with it? In our own tests it just mitigate the issue for some times, but it is still growing over the time.
On Thu, Feb 26, 2015 at 11:17 AM, Loïc Hoguin <essen@REDACTED<mailto:essen@REDACTED>> wrote:
He makes a good point, you are using hibernate yes, but that doesn't hibernate SSL processes themselves. With hibernate_after the SSL processes would hibernate too.
Not sure if that would solve anything though, and SSL can probably be made more stable without the need to hibernate, which has a cost on its own.
erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions