Hi,
On Tue, Oct 22, 2013 at 03:16:30PM +0200, arno.oderm...@ch.schindler.com 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
Hi,
On Tue, Oct 22, 2013 at 02:13:36PM +0200, Gert Doering wrote:
> On Tue, Oct 22, 2013 at 01:40:18PM +0200, Gert Doering wrote:
(I seem to be talking to myself a lot, lately...)
> > I could use some ideas on how to debug this further - if valgrind isn't
> > complaining, normally our memory man
Dear Gert,
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 s
Hi,
On Tue, Oct 22, 2013 at 01:40:18PM +0200, Gert Doering wrote:
> I could use some ideas on how to debug this further - if valgrind isn't
> complaining, normally our memory management should be OK, but why is
> VSZ/RSZ still growing, then...?
Arne brought up a good point. If we "lose" the memo
Hi,
On Mon, Oct 21, 2013 at 10:34:27AM +0200, arno.oderm...@ch.schindler.com wrote:
> thank you for replying.
> Do you see any time window, you potentially could have time for this?
I just gave it an initial try (using the "master" branch but that code
should have the same issues, if any, as no (
