Hi everyone, On Mon, Mar 23, 2020 at 11:11 AM Martin Grigorov <[email protected]> wrote:
> Hi Илья, > > On Mon, Mar 23, 2020 at 10:52 AM Илья Шипицин <[email protected]> > 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. >> > > <snip/> > 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 :-) > Here is a PR for Varnish Cache project where I use Docker + QEMU to build and package for several Linux distros and two architectures: https://github.com/varnishcache/varnish-cache/pull/3263 They use CircleCI but I guess the same approach can be applied on GitHub Actions. If you are interested in this approach I could give it a try. Regards, Martin > > >> >> пн, 23 мар. 2020 г. в 13:43, Willy Tarreau <[email protected]>: >> >>> 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 >>> >>
