Fedora – Extremely slow dnf

diskdnffedora

I got a strange issue with extremely slow dnf, to the point where computer freezes for a few seconds during installation of packages. Running Fedora 29, but this is happening for years. Otherwise the computer works fine, never crashes, obviously only dnf hits some weak spot. Not only can "dnf upgrade" take an hour for 100 packages, every year when I upgrade Fedora, I wait for Christmas holidays so I can live without computer over the weekend as 3000+ package update starts on Friday evening and finishes on Sunday.

Root directory is mounted to an old SSD disk, /home on a new classic disk (WD Caviar Black), there is another disk just for backups (just to tell there are multiple disks installed). I have suspected the old SSD to misbehave, moved the root partition to one of the classic disks and it did not improve the situation (was even slower).

Journalctl or dmesg or /var/log/messages do not show anything special. Sysbench says that disk performance of every installed disk is fine, just as fine as on another (older) computer that also runs Fedora 29 and where dnf is fine (upgrade in a few minutes, annual release upgrade during lunch).

Does anyone have an idea where to look for what is happening?

P.S.
top, iotop, iostat, dmesg, journalctl, such elementary things were checked a lot. iotop shows 99.99% activity on disk by python… (dnf) when it does the upgrade but I guess that's normal. Even sysbench (as stated above) shows the disks are a bit faster than at another computer that does dnf in a breeze.

For the make: i7-920 processor, 24 G RAM, no swap

Best Answer

Robert: It would be interesting to know what system call is taking the longest.

Can you install a simple (random) package using perf trace and then sort to find the longest calls?

For example: # perf trace -s -o /tmp/trace.out dnf install -y xorg-x11-apps-7.7-20.fc28.x86_64

And then post the contents of your /tmp/trace.out file. It's a summary file, so it shouldn't be too large, but it will help point you at what syscall(s) are taking the longest, and if they are way out of normal range.

Related Question