On Fri, 23 Feb 2024, Andreas B. Mundt wrote:
Hi Tim,
thanks for the provided patch! We see the same issue here, so I
included it in a locally built package to give it a try on our
infrastructure.
So far it looks quite promising, no errors up to now .
That's great! I've been running it for a few weeks now and also seen no
errors since I started using it.
I believe it's possibly fixed a second "buggette" too although I never
confirmed that this really existed and I haven't confirmed that it's
definitely gone away either.
If you simultaneously install a big package on multiple machines at the
same time (e.g. a kernel upgrade) then I believe that apt-cacher-ng used
to download it from upstream multiple times. Only once it had a copy did
it serve that up.
This was noticable to me in the past because I was on a relatively slow
download (c 2MB/s) so kernels would take a noticable amount of time to
download and 10 in parallel could take a lot longer than a single
download should have taken.
I used to work around this by triggering the download on a single
machine and then only triggering the rest once that one had completed
downloading.
Since applying this fix I've done another mass kernel upgrade. I'm on a
much faster connection now so I didn't really think about triggering the
download in advance but it only downloaded the kernel once.
zgrep linux-image-5.10.0-28 *
access.log.2.gz:1708183270.671 17321 <apt-cacher-ng address> TCP_MISS/200
55667185 GET
http://ftp.debian.org/debian/pool/main/l/linux-signed-amd64/linux-image-5.10.0-28-amd64_5.10.209-2_amd64.deb
- HIER_DIRECT/2a04:4e42:4b::644 application/vnd.debian.binary-package
Next time I'll try and take more care to watch what really happens here
(although with my much faster connection a kernel downloads in a few
seconds anyway)
Tim.
