Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 150777 - RPM performance bad
RPM performance bad
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2005-03-10 09:31 EST by Thomas M Steenholdt
Modified: 2014-06-14 23:54 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-10 15:14:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Thomas M Steenholdt 2005-03-10 09:31:00 EST
+++ This bug was initially created as a clone of Bug #118187 +++

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040124

Description of problem:
I have noticed that rpm seems very slow and uses a lot of cpu.

# time rpm -qa |wc -l
real    0m10.765s
user    0m8.560s
sys     0m0.194s

Granted, this is on a 550MHz P-III machine, but a similarly sized machine
running a different rpm based distro does the same thing in less than 20% of
this time.

Version-Release number of selected component (if applicable):
rpm-4.3.2-21 (other versioner are affected too)

How reproducible:

Steps to Reproduce:
1.run time rpm -qa >/dev/null or something similar
2.notice cpu usage hits the roof and query takes longer than it should

Actual Results:  rpm slow to complete transaction

Expected Results:  better performance (comparable to other rpm based distros),
less CPU usage

Additional info:
Comment 1 Paul Nasrat 2005-03-10 09:46:38 EST
You can run rpm --stats -qa for a better breakdown.

If you are going to compare performance with another rpm version it's helpful to
have the version, vendor, stats, etc.  Also testing against the same rpmdb would
make sense.
Comment 2 Jeff Johnson 2005-03-10 13:40:25 EST
Bad compared to what?
Comment 3 Thomas M Steenholdt 2005-03-10 14:31:21 EST
Well, i guess i have to admit that I was a little eager on the trigger with this

investigating the performance a little further brings the followinf info.

The rpm version i'm comparing to is a version 3 from SuSE.
It seems like this version is a little lighter on the system because it either
lack the digest/signature functionality of later rpm versions or at least
doesn't exercise those functios quite as often.

My system spends most of the time doing signature work

# rpm --stats -qa >/dev/null
   total:             1      0.000000 MB      9.571010 secs
   digest:          970     14.196385 MB      0.564451 secs
   signature:       468      0.000000 MB      7.223979 secs
   dbget:           541     14.529588 MB      1.120793 secs

Guessing that this is just not done in the SuSE version, disabling the
functionality in my FC3 version, changes the picture completely

# rpm --stats --nosignature -qa >/dev/null
   total:             1      0.000000 MB      1.374332 secs
   digest:          970     14.194000 MB      0.562437 secs
   dbget:           490     14.455532 MB      0.278045 secs

This pretty much closes the entire discussion for me (should have done all this
before even filing the bug, sorry about that) and the only thing i would like to
know is, are there a valid reason for checking signature of each and every
package in a simple "list" operation like -qa?
Comment 4 Jeff Johnson 2005-03-10 15:14:33 EST
The Principle of Least Surprise says check header
signatures everywhere and always.

Meanwhile, signature checking on queries can be globally
disabled by adding to /etc/rpm/macros
    %_vsflags_query -1

Note You need to log in before you can comment on or make changes to this bug.