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 >> >
