Yum performance review

Florian Festi ffesti at redhat.com
Tue May 15 09:53:49 UTC 2007


Yum traditionally used the rpmlib to resolve the dependecies of the packages
being installed/removed/updated. This has always restricted yum to very
simple algorithms as the interface of the rpmlib doesn't allow much control.

The current yum - that will be shipped with F7 - has now replaced the rpmlib
by a Python only resolver. I did some test runs to find out the current
state of development and to see if the new resolver is an improvement over
the rpmlib.

The candidates:

* yum-3.0.3 as used in FC6
* yum from CVS head (2007/05/07), which is very similar to the yum in F7
* pyrpmyum CVS head (2007/05/07) - a pure Python implementation developed
     for testing purposed [1].

The test cases:

Tests are based in FC-5 run on FC-6.x86_64. All operations are aborted by
"pressing n".

Try to install into an empty build root. There is a big number of excluded
pkgs to make the install '*' work.
    * Normal install: several groups, 856 Pkgs
    * Full install: "*", 6057 Pkgs
    * Install "[a-k]*", 3052 Pkgs - needs to drag in a lot of
                                    pkgs to satisfy dependencies

Before the Updates the "Normal Install" is run and the Pkgs are installed
into the build root.
    * Empty update
    * Update libgnome: 1 Pkg
    * Big update:  346u+12i Pkgs
    * Dist upgrade: Enable FC6 repos and do an upgrade; fails for both yum
      versions,so don't take results too serious

    * glibc: 828 Pkgs

Warm ups:
Do a install '*'/upgrade to build the caches. Each program has different
issues with that. yum-3.0.3 needs to download the rpm headers (Test was run
with repos in a NFS mount). All need to build the sqlite databases. pyrpmyum
currently uses a Python only implementation that uses a lot of time. Warm up
operations fail for all programs.
This all make the results of the warm ups a bit unreliable and questionable.
They are included for completeness.

Measured Values:

All data is from just one test run - so don't expect too high precision. I
put 3 different test results into tables:

    * Real time passed during the test
    * Heap peak - maximum of Memory used
    * Heap total - amount of heap memory allocated

The last one gives an idea of how much data has been moved around.


Please read the data tables first to get your own impression.

Memory usage:

The new yum saves a lot of memory for big operations (about 50%). The
comparison to pyrpmyum shows that it is possible to save even more memory
and to drop memory usage below 100MB for all cases. In pyrpmyum this is
achieved with dynamic loading of rpm tags. Some are not even kept in the
pkgs but just cached in a least recently used list.

For really small updates the old 3.0.3 yum wins. I guess this is because it
does not do any obsolete handling.


Although the new yum save the very costly rpm header downloads (which take
nearly 3 minutes for the whole repository) it is still significantly slower
for big operations. Things may look a bit different in real world scenarios
where downloading the headers is even more expensive.

Nevertheless the performance of the current yum is poor. Runtime behavior
has dropped from O(#prco * #rpmlib_calls) to O(#prco^2) (prco = Provides,
Requires, Conflicts, Obsoletes). The results of pyrpmyum show that is it
possible to do the depsolving in O(#prco) (Probably just O(#prco * log
#prco) but that doesn't matter much).

There are already plans how to get rid of the quadratic behavior and I hope
we can fix these issues before Fedora 8.

Have fun

Florian Festi

[1] https://hosted.fedoraproject.org/projects/pyrpm

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: heap.txt
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070515/13dc3b4b/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: heaptotal.txt
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070515/13dc3b4b/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: real.txt
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070515/13dc3b4b/attachment-0002.txt>

More information about the fedora-devel-list mailing list