Hi Илья,

On Mon, Mar 23, 2020 at 10:52 AM Илья Шипицин <chipits...@gmail.com> wrote:

> well, I tried to repro abns failures on x86_64
> I chose MS Azure VM of completely different size, both number of CPU and
> RAM.
> it was never reproduced, say on 1000 execution in loop.
> so, I decided "it looks like something with memory aligning".
> also, I tried to run arm64 emulation on virtualbox. no luck yet.

Have you tried with multiarch Docker ?

1) execute
docker run --rm --privileged multiarch/qemu-user-static:register --reset
to register QEMU

2) create Dockerfile
for Centos use: FROM multiarch/centos:7-aarch64-clean
for Ubuntu use: FROM multiarch/ubuntu-core:arm64-bionic

3) enjoy :-)

> пн, 23 мар. 2020 г. в 13:43, Willy Tarreau <w...@1wt.eu>:
>> Hi Ilya,
>> I think this time I managed to fix the ABNS test. To make a long story
>> short, it was by design extremely sensitive to the new process's startup
>> time, which is increased with larger FD counts and/or less powerful VMs
>> and/or noisy neighbors. This explains why it started to misbehave with
>> the commit which relaxed the maxconn limitations. A starting process
>> stealing a few ms of CPU from the old one could make its keep-alive
>> timeout expire before it got a new request on a reused connection,
>> resulting in an empty response as reported by the client.
>> I'm going to issue dev5 now. s390x is currently down but all x86 ones
>> build and run fine for now.
>> Cheers,
>> Willy

Reply via email to