Won't new Auto-Vaccum feature in RPM be seen as a major performance regression by some users?

[AnonymousCoward128746]

Moving this here to as a place for discussion. @ffesti @pmatilai

#3452 introduced an Auto-VACCUM threshold into rpm. (#3309 and related rpm-software-management/dnf5#2002)

I'm concerned about this change introducing a non-deterministic of latency into everyday package management operations. In my experience users hate non-deterministic response times and may perceive it as a significant regression.

LLM says that

The SQLite VACUUM operation is not incremental; it is a complete operation that rebuilds the entire database file.

so vacuuming a recently vacuumed database takes just as much time (ignoring effects of a possibly hot page cache), For spinning rust, this actually matters, while for 2000MB/s SSDs (where the rebuild may be quite quick) the bloat isn't noticeable to begin with.

Scenarios:

1. Imagine for example that some automated flow puts the db just at the tipping point. This might be a CI docker image build for example. Now the first install command for 10 million users who use CI actions on github takes 10 times as long. Everytime CI runs.
2. Can the user activate this cleanup multiple times, depending on the order they issue install/remove commands?
   Can "rpm -i ABC; rpm -i XYZ" cause two cleanups while "rpm -i ABCXYZ" incurs the overhead only once? might users have to pay the cost of a rebuild multiple times in one session?
3. Can some automated testing loops incur the rebuild on every iteration, with enough I/O in the meantime to evict the database data from the page cache?

Doesn't this make more sense as a cron job by distros? how do major distros usually handle periodic cleanup jobs like this? perhaps all they need is a hook to call. So that RPM can report if it needs to rebuild but the distro decides when: "mechanism, not policy".

[pmatilai]

Nah. On SSD's this is a mere blink of an eye, totally lost in the time packages spend running scriptlets and whatnot. On a spinning media everything is slow.

If you're building images, it's always a good idea to do a rpmdb --rebuilddb as the last step to compact the db.

Finally, as with any such heuristics: it's of course possible we need to further fine-tune the mechanism. Only time and real-world usage will tell.

[ffesti]

Vacuuming can also only be triggered by new free space to the database. This can only happen on erase or update operations. So many CI applications won't run into that.

I expect the auto vacuum to primarily kick in after updates - which are typically longer running operations. So most users will probably not even notice.

So I am happy to just wait until some users complain with real use cases.

[AnonymousCoward128746]

I agree that --rebuilddb would be good practice for image recipes, I just don't think it's common practice or widely known.

As for "HDs are slow and that's just the way it is", I raised this issue because I was already suffering. and the delay of an intermittent rebuild is actually much worse.

My suspicion is that few if any users (of the shrinking population that still uses HDDs) will be sufficiently observant to notice a sporadic slowdown, which may only appear days after they automatically upgrade the rpm package in a particular setting. It's very easy to just rationalize this kind of intermittent slowness away. It may indeed hurt UX without you hearing about it for a long time.

Do you have anything in place to collect telemetry about how frequently this triggers for end users, if only from some volunteer beta testers? or your fine selves?

Note: rpm --rebuilddb takes 57 seconds on my beloved yet decrepit yet quad-core machine, every time.

[pmatilai]

SQL internal vacuum is not the same as --rebuilddb, only similar.

Speculating on such matters is waste of time. If you're concerned, then by all means test and report back. None of us even have spinning disks, so it's impossible for us to test.

[AnonymousCoward128746]

SQL internal vacuum is not the same as --rebuilddb, only similar.

# sudo sqlite3 rpmdb.sqlite       
SQLite version 3.46.1 2024-08-13 09:16:08
Enter ".help" for usage hints.
sqlite> .timer on
sqlite> VACUUM; # with whatever's in the page cache during normal use
Run Time: real 35.188 user 2.156049 sys 4.612098
sqlite> VACUUM; # now warm
Run Time: real 18.979 user 1.747309 sys 2.954235
sqlite> VACUUM; # after clearing page cache completely (i.e. boot or image spinning up state)
Run Time: real 55.344 user 2.315559 sys 10.610508

[pmatilai]

The auto-vacuum will only ever occur on a warm db, after update/erase transactions of allegedly non-trivial size.

[AnonymousCoward128746]

a VACCUM is unusual in warming up every page of the DB, I don't think regular transactions would do quite that.
But I see there's no point discussing further until and if you get complaints down the line. Dropping it for now.

[pmatilai]

Like said, it's entirely possible the initial cut-off size may need fine-tuning to only occur on larger transactions, time will tell.
Doing the vacuum is a win anyhow because the db slows down as it grows even if its half-empty, besides wasting diskspace. This was particularly bad with BDB but IIRC plenty visible with sqlite too, at least on spinning disks (seek-times and all that).

[pmatilai]

Also just FWIW: upgrading to an SSD is one of the bigger quality-of-life improvements you'll find in the 40-100€ range.
This coming from somebody whose home desktop - a quad-core from 2010 - was on a spinning disk until about a year ago. After the upgrade it boots so fast that on the first reboot I thought it simply didn't reboot at all 😆 Moving to SSD is literally a whole new life-cycle for a computer. The only regret is that I didn't do it years ago.

[AnonymousCoward128746]

I tried several years ago but connecting a SATA SSD drive to old unused ports just killed them. It was either getting a new motherboard+CPU+memory, or risk final damage to my remaining SATS ports, and having to replace everything anyway so I didn't push it. But, you're right I'm way overdue for an upgrade.