Hi again Pieter,
On Tue, Jun 11, 2019 at 04:24:47AM +0200, Willy Tarreau wrote:
> I'm
> going to have a look at this this morning. I now see how to make things
> worse to observe the changes, I suspect that forcing a high nbthread and
> binding all of them to a single CPU should reveal the issue m
Hit enter too fast, with the patch now.
On Tue, Jun 11, 2019 at 09:06:46AM +0200, Willy Tarreau wrote:
> Hi again Pieter,
>
> On Tue, Jun 11, 2019 at 04:24:47AM +0200, Willy Tarreau wrote:
> > I'm
> > going to have a look at this this morning. I now see how to make things
> > worse to observe the
Hello!
It did not happen for weeks, but today I found again haproxy using a
full CPU core.
Haproxy v1.9.8 on Ubuntu 18.04.
Actually there was a misalignment in a "peer" stick table configuration
between the two peers, but I do not know if this can cause the
behaviour.
If anyone is interest
Hi,
I think we could take this one, however I'm having some comments :
On Mon, Jun 10, 2019 at 04:13:19PM -0500, linuxdaemon wrote:
> --- a/src/checks.c
> +++ b/src/checks.c
> @@ -1891,8 +1891,23 @@ static int prepare_external_check(struct check *check)
> goto err;
> }
>
> -
On Mon, 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 netstat | grep 'TIME_WAIT' | wc -
Hi Bob,
On Mon, Jun 10, 2019 at 09:54:29PM +, Zakharychev, Bob wrote:
> FWIW: after a bit of experimentation and a quick dumb behavior comparison
> program I found that FD_SET is compiled incorrectly by GCC 8.3.0 under Cygwin
> with optimization level of -O2 and up. I compared native FD_SET/FD
Hi Marco,
On Tue, Jun 11, 2019 at 09:10:19AM +0200, Marco Corte wrote:
> Hello!
>
> It did not happen for weeks, but today I found again haproxy using a full
> CPU core.
> Haproxy v1.9.8 on Ubuntu 18.04.
Ah, bad :-(
> Actually there was a misalignment in a "peer" stick table configuration
> bet
Hi
I'm using multiple processes haproxy, how can I get overall stats in haproxy?
I have to access every process's stats page, and get the stats of that process
and count.
Is there any convenient way to get overall stats?
Thanks
On Tue, Jun 11, 2019 at 09:06:46AM +0200, Willy Tarreau wrote:
> I'd like you to give it a try in your environment to confirm whether or
> not it does improve things. If so, I'll clean it up and merge it. I'm
> also interested in any reproducer you could have, given that the made up
> test case I d
Hi Maksim,
On Wed, Jun 05, 2019 at 09:59:29AM +0200, Willy Tarreau wrote:
> I'm still trying to fix this mess, it's not trivial at all and may
> even require an extra -dev. So expect some updates later.
Just a quick note to let you know that Olivier just fixed a directly
related issue in 2.0-dev
Hello Willy,
Apologies for the delay.
Thank you for taking the time to review.
> On Jun 2, 2019, at 10:11 PM, Willy Tarreau wrote:
>
> Hi Daniel,
>
> On Thu, May 30, 2019 at 12:57:10AM -0400, Daniel Corbett wrote:
>> Hello,
>>
>>
>> When communicating over SPOP the AGENT-HELLO, AGENT-DISC
On Tue, 11 Jun 2019 at 10:03, wrote:
>
> Hi
>
> I'm using multiple processes haproxy, how can I get overall stats in haproxy?
>
> I have to access every process's stats page, and get the stats of that
> process and count.
>
> Is there any convenient way to get overall stats?
>
> Thanks
>
>
>From
Hi Daniel,
On Tue, Jun 11, 2019 at 08:49:17AM -0700, Daniel Corbett wrote:
> Hello Willy,
>
>
> Apologies for the delay.
>
> Thank you for taking the time to review.
(...)
Thanks for the updated patch set, that was just in time! I had already
tagged 2.0-dev7. I just deleted the tag, merged you
Hi,
HAProxy 2.0-dev7 was released on 2019/06/11. It added 34 new commits
after version 2.0-dev6.
We're getting pretty good! I really was hesitating about marking it
final already or not, but given that we've addressed a few last minute
non-trivial issues and that there are still enough code clean
Willy,
Am 11.06.19 um 20:02 schrieb Willy Tarreau:
> I noticed that no regtest failed on Travis since commit 7b3a79f6 which
The abns_socket.vtc one is incredibly flaky though. I've noticed two
"failed" tests for Travis in in the list of commits today where a single
configuration failed to succeed
Hi Tim,
On Tue, Jun 11, 2019 at 08:14:41PM +0200, Tim Düsterhus wrote:
> Willy,
>
> Am 11.06.19 um 20:02 schrieb Willy Tarreau:
> > I noticed that no regtest failed on Travis since commit 7b3a79f6 which
>
> The abns_socket.vtc one is incredibly flaky though. I've noticed two
> "failed" tests for
Willy,
Am 11.06.19 um 20:53 schrieb Willy Tarreau:
> Hi Tim,
>
> On Tue, Jun 11, 2019 at 08:14:41PM +0200, Tim Düsterhus wrote:
>> Willy,
>>
>> Am 11.06.19 um 20:02 schrieb Willy Tarreau:
>>> I noticed that no regtest failed on Travis since commit 7b3a79f6 which
>>
>> The abns_socket.vtc one is i
Am 11.06.2019 um 20:02 schrieb Willy Tarreau:
> Hi,
>
> HAProxy 2.0-dev7 was released on 2019/06/11. It added 34 new commits
> after version 2.0-dev6.
[snipp]
> Please find the usual URLs below :
>Site index : http://www.haproxy.org/
>Discourse: http://discourse.haproxy.org
On Tue, Jun 11, 2019 at 09:27:37PM +0200, Tim Düsterhus wrote:
> Reading the log I believe this might actually be a real problem within
> HAProxy. Note the log lines starting at 370 in the attached file:
>
> line 370: The old worker starts stopping its proxies (due to having
> received the SIGUSR1
On Tue, Jun 11, 2019 at 09:42:13PM +0200, Aleksandar Lazic wrote:
> Sorry to say that but there is no dev7 and in
> http://www.haproxy.org/download/2.0/src/devel/
> also not.
Ah silly me! And who forgot to run "pubish-release" in your opinion ? :-)
It's OK now. Thanks for reporting this!
Willy
Willy,
Am 11.06.19 um 21:58 schrieb Willy Tarreau:
>> So clearly there is no *seamless* reload happening here which is the
>> very thing the test is testing. The question is: Is the issue with the
>> 'abns' socket or is the issue with the 'fd@${testme}' socket? Can
>> fd-sockets be seamlessly pass
On Tue, Jun 11, 2019 at 10:02:48PM +0200, Tim Düsterhus wrote:
> Should I file an issue (referring to this thread) to keep track of the
> whole issue and possible solutions?
Oh yes please!
> In Travis we have a clearly defined environment, so that kind of test
> should work there as well.
Good p
Am 11.06.2019 um 22:01 schrieb Willy Tarreau:
> On Tue, Jun 11, 2019 at 09:42:13PM +0200, Aleksandar Lazic wrote:
>> Sorry to say that but there is no dev7 and in
>> http://www.haproxy.org/download/2.0/src/devel/
>> also not.
>
> Ah silly me! And who forgot to run "pubish-release" in your opinion
Hi Willy,
Op 11-6-2019 om 11:37 schreef Willy Tarreau:
On Tue, Jun 11, 2019 at 09:06:46AM +0200, Willy Tarreau wrote:
I'd like you to give it a try in your environment to confirm whether or
not it does improve things. If so, I'll clean it up and merge it. I'm
also interested in any reproducer y
Hi Pieter,
On Tue, Jun 11, 2019 at 10:46:50PM +0200, PiBa-NL wrote:
> Seems i kept you busy for another day.. But the result is there, it looks
> 100% fixed to me :).
Excellent, thanks for the fast feedback! We're getting there :-)
I'm starting to really like our new development model, as for th
Hi all,
I'm currently re-reading my notes for the upcoming release and found
something I noted not that long ago regarding the TARGET variable of
the makefile. The list of operating systems hasn't changed in a while
and in parallel we've added a bunch of build options that do not solely
depend on
26 matches
Mail list logo