Hi Willy,
Yes, please send me the script.
Thanks!
-- Georges-Etienne
Le 2015-02-06 à 01:55, Willy Tarreau w...@1wt.eu a écrit :
Hi Georges-Etienne,
On Thu, Feb 05, 2015 at 09:10:25PM -0500, Georges-Etienne Legendre wrote:
Hi Willy,
I'm not sure how to document this leak. I don't
On 06/02/2015 11:19 πμ, Georges-Etienne Legendre wrote:
Hi Willy,
Yes, please send me the script.
Willy,
If it isn't against the policies of this ML to send attachments and the
script is few kilobytes size, could you please send it to the list?
Thanks,
Pavlos
signature.asc
Description:
Hi Georges-Etienne,
On Thu, Feb 05, 2015 at 09:10:25PM -0500, Georges-Etienne Legendre wrote:
Hi Willy,
I'm not sure how to document this leak. I don't know exactly how is
implemented the firewall SSL health check... Would the Wireshark trace be
enough to report the issue?
Yes I think it
Hi Willy,
I'm not sure how to document this leak. I don't know exactly how is
implemented the firewall SSL health check... Would the Wireshark trace be
enough to report the issue?
Thanks!
-- Georges-Etienne
On Tue, Feb 3, 2015 at 5:52 PM, Willy Tarreau w...@1wt.eu wrote:
Hi Georges-Etienne,
Hi Georges-Etienne,
On Tue, Feb 03, 2015 at 08:09:15AM -0500, Georges-Etienne Legendre wrote:
Hi Willy,
Thanks a lot for this investigation, it was really helpful.
My OpenSSL is up-to-date on this server. I first tried to remove the chroot
statement. I'm pretty sure this in itself solved
Thanks for your help.
The configuration is now back to 5000 maxconn, and Haproxy has been running
with this config over the last weekend. The memory footprint is now 1G.
# ps -u nobody u
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
nobody9103 0.7 3.9 1334192
Hi Georges-Etienne,
On Mon, Feb 02, 2015 at 08:35:21AM -0500, Georges-Etienne Legendre wrote:
Thanks for your help.
The configuration is now back to 5000 maxconn, and Haproxy has been running
with this config over the last weekend. The memory footprint is now 1G.
OK, so there's no doubt
Georges-Etienne,
your captures were extremely informative. While I cannot reproduce the
behaviour here even by reinjecting the same health check requests, I'm
seeing two really odd things in your trace below :
We accept an SSL connection from the firewall :
08:15:52.297357 accept(6,
OpenSSL sometimes acts stupidly like this inside a chroot. We've
encountered a few issues in the past with openssl doing totally crazy
stuff inside a chroot, including abort() on krb5-related things. From
what I understood (others, please correct me if I'm wrong), such
processing may be
The maxconn was set to 4096 before, and after 45 days, haproxy was using
20gigs...
What else could it be?
-- Georges-Etienne
On Fri, Jan 30, 2015 at 1:49 PM, Lukas Tribus luky...@hotmail.com wrote:
With maxconn 5 this is expected behavior, because haproxy will use
RAM up to an amount
The maxconn was set to 4096 before, and after 45 days, haproxy was
using 20gigs...
Ok, can you set maxconn back to 4096, reproduce the leak (to at least
a few gigabytes) and a run show pools a few times to see where
exactly the memory consumption comes from?
Lukas
On Sat, Jan 31, 2015 at 12:59:34AM +0100, Lukas Tribus wrote:
The maxconn was set to 4096 before, and after 45 days, haproxy was
using 20gigs...
Ok, can you set maxconn back to 4096, reproduce the leak (to at least
a few gigabytes) and a run show pools a few times to see where
exactly
With maxconn 5 this is expected behavior, because haproxy will use
RAM up to an amount that is justified for 5 concurrent connections.
Configure maxconn to a proper and real value and the RAM usage will be
predictable.
Lukas
Hi all,
We're deploying HAproxy and we're experiencing what apprears to be a memory
leak. After couple of days, HAproxy is consuming gigs of RAM.
Running a ps command returns:
# ps -u nobody u
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
nobody 29960 0.2 1.0
14 matches
Mail list logo
