Hide Forgot
Description of problem: quering the rpm databse takes way to much time on some systems : [root@s120 rdt]# time rpm -qa 1>/dev/null real 1m26.664s user 0m5.533s sys 0m0.500s [root@s120 rdt]# rpm --rebuilddb; [root@s120 rdt]# time rpm -qa 1>/dev/null real 1m30.910s user 0m4.954s sys 0m0.480s even getting worse after the repair run. Where it takes just 2 seconds on another VM system with the same cpu,drives, os and patch level: [root@c1 rdt]# time rpm -qa > /dev/null real 0m1.833s user 0m1.689s sys 0m0.111s [root@c1 rdt]# Any ideas how to increase rpm speed again ? Version-Release number of selected component (if applicable): RPM-Version 4.13.0-rc1
To rule out the obvious... Have you looked at what else is going on in the system at that time? There are all sorts of IO-heavy cron etc activities going on occasionally that need can easily cause that sort of difference. Other possibilities include damaged disk limping on but at very much slower speed. Etc.
both servers are Vms on the same hostsystem, they share the same physical hd array, and i took several measurements at different times, before i opened the bugreport. C1: 1232 installed packages S120: 1065 installed packages On this specific server system, rpm takes unusual long to finish. If you run rpm -qa with output, you can see the lines comming out one by one. I have observed this behavior on several other systems, but over time and with the help of "--rebuilddb" it went away. This one stayed.
The rpmdb performance is sort of known to deteriorate over time (or rather, vast number of updates) and like you noted, --rebuilddb usually cures that. That it doesn't just makes me suspect its something entirely different. Have you tried benchmarking other things beside rpm on that system? If you look at the numbers from "time", system and user times do not add up at all. Usually sys + user roughly equals real time, but this case it spends some 1m 20s in la-la land. 'strace -tt -o rpmqa.log rpm -qa > /dev/null' output ought to provide some clues where the time is getting spent.
Created attachment 1213823 [details] logfile
while strace was running, rpm took 85-99% Diskio with 7 mb/s read rate afterwards: "python -tt /usr/libexec/yum-updatesd-helper --check --dbus" had the same issues and values than rpm had.
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.