Hi, On Tue, Oct 22, 2013 at 03:16:30PM +0200, [email protected] wrote: > thank you so much. > Meanwhile, we can define the substantial memory growth for the phase of > the first renegotiation cycle. > Memory is growing by almost double. > Surely, if one had only 50 to 100 concurrent sessions, it is not quit > hurting anything. But driving the amount of concurrent session as we got > it in our scenario, memory treatment seems to become key.
I'm not sure I found everything yet, but what I've seen to far will
definitely raise memory consumption for long-term connected clients
(as in: for every renegotiation, memory goes up). This particular gc
is cleared upon client disconnection, thogh - so maybe that is why it
wasn't noticed earlier.
About your user base: is this more dynamic clients (like "mobile users"),
or are these very persistent long-term sessions (like "1000s of sensors
that come online upon reboot, and stay online for weeks at a time")?
I'd like to understand your usage scenaro better to see whether what I'm
tracking can be relevant at all, or not.
(As an extra question: if I find something and have tested it enough to
say "this should fix things for you", can you run a test version in
your environment? Or is this all production and needs to come in form
of a binary distribution, etc.?)
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]
fax: +49-89-35655025 [email protected]
pgpRShKDMlXG8.pgp
Description: PGP signature
