On Wednesday, January 1, 2025 11:27:38 AM MST Aurélien COUDERC wrote: > Le mardi 31 décembre 2024, 18:32:09 UTC+1 Soren Stoutner a écrit : > > On Tuesday, December 31, 2024 10:16:32 AM MST Michael Stone wrote: > > > On Tue, Dec 31, 2024 at 05:31:36PM +0100, Sven Mueller wrote: > > > >It feels wrong to me to justify such a heavy performance penalty this way > > > > if > > > > > Well, I guess we'd have to agree on the definition of "heavy performance > > > penalty". I have not one debian system where dpkg install time is a > > > bottleneck. > > > > So far, nobody has > > produced any numbers showing that those penalties exist or how significant > > they are. As I don’t experience anything I could describe as a performance > > problem on any of my systems, I think the burden of proof is on those who > > are experiencing those problems to demonstrate them concretely before we > > need to spend effort trying to figure out what changes should be made to > > address them. > Here’s a quick « benchmark » in a sid Plasma desktop qemu VM where I had a > snapshot of up-to-date sid from Nov 24th, upgrading to today’s sid : > > Summary: > Upgrading: 658, Installing: 304, Removing: 58, Not Upgrading: 2 > Download size: 0 B / 1 032 MB > Space needed: 573 MB / 9 051 MB available > > # time apt -y full-upgrade > > real 9m49,143s > user 2m16,581s > sys 1m17,361s > > # time eatmydata apt -y full-upgrade > > real 3m25,268s > user 2m26,820s > sys 1m16,784s > > That’s close to a *3 times faster* wall clock time when run with eatmydata. > > The measurements are done after first running apt --download-only and taking > the VM snapshot to avoid network impact. The VM installation is running plain > ext4 with 4 vCPU / 4 GiB RAM. > The host was otherwise idle. It runs sid on btrfs with default mount options > on top of LUKS with the discard flag set. The VM’s qcow2 file is flagged with > the C / No_COW xattr. It’s a recent Ryzen system with plenty of free RAM / > disk space. > > While I don’t have a setup to quickly reproduce an upgrade on the bare metal > host in my experience I see comparable impacts. And I’ve experienced similar > behaviours on other machines. > > > I won’t pretend I know what I’m doing, so I’m probably doing it wrong and my > installs are probably broken in some obvious way. You were asking for data so > here you go with a shiny data point. :)
That is an interesting data point. Could you also run with --force-unsafe-io instead of eatmydata? I don’t know if there would be much of a difference (hence the reason for the need of a good benchmark), but as the proposal here is to enable --force-unsafe-io by default instead of eatmydata it would be interesting to see what the results of that option would be. -- Soren Stoutner so...@debian.org
signature.asc
Description: This is a digitally signed message part.
