Hi Patrick,
On Mon, Apr 04, 2016 at 04:57:49PM -0400, Patrick Hemmer wrote:
> It looks like the mailing list archives stopped working mid-December.
>
> https://marc.info/?l=haproxy
The people at marc.info are currently working on fixing this.
In the mean time you can use gmane instead :
http
It looks like the mailing list archives stopped working mid-December.
https://marc.info/?l=haproxy
-Patrick
One is process-wide, one is per frontend and both counts for a maximum
accepted incoming connections.
Baptiste
On Mon, Apr 4, 2016 at 9:07 PM, CJ Ess wrote:
> Funny you should mention that, I pushed out the revised config and
> immediately got warning about session usage from our moniting. Turns
Funny you should mention that, I pushed out the revised config and
immediately got warning about session usage from our moniting. Turns you
you need Maxconn defined as global for hard limits and default for the soft
limit. In this case I'm not completely clear why the global maxconn is
different th
Hi Nenad,
I suggest you try reverting commit 7610073a. I have exhibited very
similar issues and everything points to this commit (which was Willy's
first suspect).
So I assume this affects 1.6 and 1.7-dev as well, the bug is not
specific to the
1.5 backport, right?
Thanks,
Lukas
Title: Beauty on the Moon
Jusqu'à 70% de réduction et 10% de remise supplémentaire avec notre code promo !
Consultez la version en ligne
Hi Sachin,
(due to email troubles on my side this may look like a new thread, sorry
about that)
> We have quite a few regex and acls in our config, is there a way to
profile
> haproxy and see what could be slowing it down?
You can use strace for syscalls or ltrace for library calls to see i
Hi,
Le 04/04/2016 19:14, CJ Ess a écrit :
Moving the setting to global worked perfectly AND it upped the ulimit-n
to a more appropriate value:
I feel unconfortable with the "Moving the setting" part.
Did you really MOVE the maxconn declaration from defaults (or
listen/frontend) to the global
Moving the setting to global worked perfectly AND it upped the ulimit-n to
a more appropriate value:
...
Ulimit-n: 131351
Maxsock: 131351
Maxconn: 65535
Hard_maxconn: 65535
...
So we'll write this down as a learning experience. We recently transitioned
from doing one request per connection to usi
On 04/04/2016 05:23 μμ, Sachin Shetty wrote:
> Hi,
>
> I am chasing some weird capacity issues in our setup.
>
> Haproxy which also does SSL is forwarding request to various other
> servers upstream. I am seeing a simple 100MB file download from our
> upstream components starts to slow down time
Hi,
I am chasing some weird capacity issues in our setup.
Haproxy which also does SSL is forwarding request to various other servers
upstream. I am seeing a simple 100MB file download from our upstream
components starts to slow down time to time like hitting as low as 1MBPS,
usually is it greater
Hi Craig,
This is partially handled by the "http-reuse" featureof HAProxy 1.6.
A real connection pool is on its way, it's a requirement for HTTP/2.
That said, no idea when we'll have it.
Baptiste
On Thu, Mar 31, 2016 at 5:11 PM, Craig McLure wrote:
> Hi Baptiste,
>
> Thanks for the answer, it
HI all,
After the important cleanup of this week end, here a much more modest one.
Basically some gcc warnings suppressions.
Hope it is useful.
From 39d833189abea2f6c4671cc969302365dc7d9c45 Mon Sep 17 00:00:00 2001
From: David Carlier
Date: Mon, 4 Apr 2016 11:54:42 +0100
Subject: [PATCH] CLEANUP
2016-03-31 9:46 GMT+02:00 Janusz Dziemidowicz :
> About the CPU problem. Reverting 7610073a indeed fixes my problem. If
> anyone has any idea what is the problem with this commit I am willing
> to test patches:)
> Some more details about my setup. All servers have moderate traffic
> (200-500mbit/s
14 matches
Mail list logo
