Created attachment 1857711 [details] Flamegraph of `rpm --reinstall breeze-icon-theme-*.noarch.rpm` with rpm-4.17.0-3.fc35 Description of problem: rpm-4.17.0-3 introduced a performance regression that causes a long delay when updating/removing some packages. Version-Release number of selected component (if applicable): rpm-4.17.0-3.fc35 How reproducible: Reliably. Steps to Reproduce: 1. Grab an F35 VM. 2. # dnf install -y breeze-icon-theme 3. # dnf download breeze-icon-theme 4. Update rpm to rpm-4.17.0-3.fc35 5. # time rpm --reinstall breeze-icon-theme-*.noarch.rpm Actual results: 2m49.142s Expected results: 0m4.731s as with rpm-4.17.0-1.fc35 Additional info: Not to be confused with BZ 2029709, which is filesystem-related. This one is almost definitely a bug in rpm itself, as most of the time is spent in the rpmtriggersPrepPostUnTransFileTrigs() function (see attached flamegraph), which is modified by a patch introduced in rpm-4.17.0-3.fc35: https://src.fedoraproject.org/rpms/rpm/c/b3ac7d69fd307e87f35c5db8288d5743e011aff5?branch=f35 Found by following this hint from Vitaly Zaitsev: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WMSGBUWLQPETC32QPUUJRB7QJU5QQOUR/
Ack, easily reproduced. Thanks for the report.
Note that the old version was fast because it failed to do a lot of necessary work. Presumably some/much of the lost time can be gained back by optimizing, but this isn't some random bug/regression making things slower, it's caused by doing previously missing calculations proper file trigger execution.
> Note that the old version was fast because it failed to do a lot of necessary work. It was always fast.
I know that it probably won't be equally as fast as before. The thing is, even if it took 3x longer with that patch, it would be still ok. But it takes ~30x longer :) # strace -f --summary-only rpm --reinstall breeze-icon-theme-*.noarch.rpm % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 97.51 70.382951 1 55545184 pread64 [...] I mean surely it has to be possible to compute the triggers with less than 55 million DB page reads... The whole database is just ~21MB, so with that many calls you can read the whole DB more than 10 000 times.
Yes like I said, it's probably possible to optimize it quite a bit. Just don't expect us to revert the patch because of a slowdown on some packages.
It appears that this effect is triggered by kernel packages as well (unsurprising since they include a large number of files). That will probably make it more noticeable to most users.
> Yes like I said, it's probably possible to optimize it quite a bit. Just don't expect us to revert the patch because of a slowdown on some packages. Hangs for 5 (five) minutes with 100% usage of 1 CPU core is not good. Users are already complaining about this: https://bugzilla.redhat.com/show_bug.cgi?id=2032498
Nobody's saying it's good, but please understand that executing wrong filetriggers is worse.
...however being 30x slower AND still executing wrong stuff is pretty bad, lol. Seems like a bit of a Monday-morning patch (by yours truly) this one.
FEDORA-2022-a9a84f2456 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-a9a84f2456
FEDORA-2022-a9a84f2456 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-a9a84f2456` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-a9a84f2456 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
*** Bug 2047477 has been marked as a duplicate of this bug. ***
FEDORA-2022-a9a84f2456 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.