We are running this patch on top of 1.9.13 where it is needed. I will
report back if/when we have anything to add. Untill then consider no
news as good news in regards to this.
Dave.
On Tue, Jan 14, 2020 at 9:37 AM Willy Tarreau wrote:
>
> On Tue, Jan 14, 2020 at 09:31:07AM -0600, Dave
Can we get this backported onto the 2.0 and 1.9 stable streams? It
looks like it mostly cleanly patches. *(aside from line numbers).
Thanks,
Dave
On Tue, Jan 14, 2020 at 3:49 AM Willy Tarreau wrote:
>
> On Mon, Jan 13, 2020 at 10:11:57AM -0800, Sadasiva Gujjarlapudi wrote:
> > Sounds good to me
s.
On Wed, Dec 11, 2019 at 2:35 AM Baptiste wrote:
>
> On Mon, Dec 2, 2019 at 5:15 PM Dave Chiluk wrote:
>>
>> Since 2.0 nbproc and nbthreads are now mutually exclusive, are there
>> any ways to make lua multi-threaded?
>>
>> One of our proxy's makes heavy
Since 2.0 nbproc and nbthreads are now mutually exclusive, are there
any ways to make lua multi-threaded?
One of our proxy's makes heavy use of lua scripting. I'm not sure if
this is still the case, but in earlier versions of HAProxy lua was
single threaded per process. Because of this we were r
Ubuntu 16.04 is on 1.6 which is bug-fix "supported" till 2021. It's
probably fine to deprecate next year.
Ubuntu 18.04 is on 1.8 which is bug-fix "supported" till 2023.
Debian has 1.8 in their stable and 2.0.9 in unstable, but I'm not as
familiar with their release cycles.
RHEL/Centos 7 haproxy p
2019 at 3:30 PM Willy Tarreau wrote:
> On Thu, Jun 13, 2019 at 03:20:20PM -0500, Dave Chiluk wrote:
> > I've attached an haproxy.cfg that is as minimal as I felt comfortable.
> (...)
>
> many thanks for this, Dave, I truly appreciate it. I'll have a look at
> it hopefully tomorrow morning.
>
> Willy
>
of 7 it would be more pronounced.
I got perf stack traces for setsockopt from both versions on our production
servers, but inlining made those traces mostly useless.
Let me know if there's anything else i can grab.
Dave.
On Thu, Jun 13, 2019 at 1:30 AM Willy Tarreau wrote:
> On Wed
Jun 10, 2019 at 04:01:27PM -0500, Dave Chiluk wrote:
> > We are in the process of evaluating upgrading to 1.9.8 from 1.8.17,
> > and we are seeing a roughly 70% increase in sockets in TIME_WAIT on
> > our haproxy servers with a mostly idle server cluster
> > $ sudo nets
We are in the process of evaluating upgrading to 1.9.8 from 1.8.17,
and we are seeing a roughly 70% increase in sockets in TIME_WAIT on
our haproxy servers with a mostly idle server cluster
$ sudo netstat | grep 'TIME_WAIT' | wc -l
Looking at the source/destination of this it seems likely that thi
We have the same use case as Alex *(mesos load balancing), and also confirm
that our config worked without change 1.6->1.8.
Given our testing you should consider the seamless reload -x option, and
the dynamic server configuration apis. Both have greatly alleviated issues
we've faced in our micros
Signed-off-by: Dave Chiluk
---
include/common/cfgparse.h | 2 +-
src/session.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/common/cfgparse.h b/include/common/cfgparse.h
index c003bd3b0..6e35bc948 100644
--- a/include/common/cfgparse.h
+++ b
I'm sorry I just realized I applied this against the 1.8 stable.
I'll send another patch for 1.9.
On Thu, Jun 21, 2018 at 10:55 AM Dave Chiluk
wrote:
> Some spelling cleanup in comments.
>
> Signed-off-by: Dave Chiluk
> ---
> include/common/cfgparse.h | 2 +-
> i
Some spelling cleanup in comments.
Signed-off-by: Dave Chiluk
---
include/common/cfgparse.h | 2 +-
include/types/task.h | 2 +-
src/session.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/common/cfgparse.h b/include/common/cfgparse.h
index
The patches are all cherry picks from the 1.8 branch that i backported to
the 1.7 branch. They are all documented with the original development tree
sha as well.
Have fun
Dave.
On Fri, Jun 1, 2018, 6:16 AM Veiko Kukk wrote:
> On 31/05/18 23:15, William Lallemand wrote:
> > Sorry but unfortunat
s. The aim was to be able to send those listening sockets using
the -x option.
However to ensure the previous behavior which was to close those
sockets, we provided the "no-unused-socket" global option.
This patch changes this behavior, it will close unused sockets which are
not in the
We've battled the same issue with our haproxys. We root caused it to slow
dns lookup times while parsing the config was causing haproxy config
parsing to take so long that we were attempting to reload again before the
original reload had completed. I'm still not sure why or where the Signals
are
Assuming you are running an Ubuntu archive version of haproxy you should
consider opening a bug in launchpad as well.
https://launchpad.net/ubuntu/+source/haproxy/+filebug
It sounds like there's a missing dependency in the unit file against DNS or
network, but I haven't looked into it other than w
are doing all this using 1.8.7.
Thanks,
Dave
On Fri, Apr 13, 2018 at 12:35 PM Jonathan Matthews
wrote:
> On Fri, 13 Apr 2018 at 00:01, Dave Chiluk
> wrote:
>
>> Is there a way to force haproxy to not use a backend until it passes a
>> healthcheck? I'm also
Hi we're evaluating haproxy for use as the load balancer in front of our
mesos cluster. What we are finding is that even though we have requested
the check option in the server line, haproxy attempts to serve traffic to
the server on startup until the first healthcheck completes.
server slot1 10.
I'm trying to write what amounts to an init/startup script for haproxy with
a patched version of 1.7.8 that includes the seamless reload patches that
are described on this blog post.
https://www.haproxy.com/blog/truly-seamless-reloads-with-
haproxy-no-more-hacks/
#1. If haproxy dies or was killed
20 matches
Mail list logo