You are viewing illiterat

James Antill - Post a comment

May. 21st, 2008

07:02 am - Understanding why YUM seems "slow", and some instant solutions

The previous entry was more of a general explanation about YUM speed and that if used in it's normal environment how current YUM is often more than fast enough, this entry is going to be a companion to it but focus on specific things that might make YUM appear slow but would better be described as using it suboptimally.

Note that I'm still not going to directly compare to other tools as I'm not as familiar with them and, as I said in the previous article, the tools are designed so differently that they don't lend themselves to comparisons. Also, as I also said before, if something is fine if it takes less than 10 seconds if two tools take 6 seconds and 4 seconds it doesn't really matter if yum is the faster (again, see the previous post, this should not be the end goal IMO).

  • Benchmarking "makecache":

    If you are benchmarking the makecache command in yum, you have utterly failed. This command should be entirely a network test. If you have repos. that you care about which are shipping with only .xml data and not also .sqlite data (generated from: createrepo -d) then complain to whoever is generating the data. Nothing YUM can do will make this faster than 0 seconds (it also tends to be smaller, and so comes down the network sooner).

  • Metadata checks slowing you down:

    Yes, YUM will automatically check that your metadata is current every 90 minutes, you can alter this using the metadata_expire configuration variable but the better thing to do is run some non-interactive process which will do the check every hour (yum-updatesd can be configured to just do this, but "yum list updates" in a cron job will also work).

  • One big repo. hurts performance:

    As I've said YUM is mostly tested with Fedora/CentOS/etc. all of which use $basearch variables to have different architecture packages in different places, and also to have the set of three repositories "foo, foo-source and foo-debuginfo" instead of a single "foo" repository. This not only means that YUM doesn't have to inspect the metadata for the source packages in normal operations but that it doesn't even need to download the metadata for them over the network. The YUM related tools, like yumdownloader --source and debuginfo-install will enable the relevant repos. if you keep to the above naming convention.

  • Some exotic features are just painful:

    There are still some corner cases, for instance using the "includepkgs" configuration option still requires that YUM load all of the repo. data into memory whereas using "exclude" configuration option only requires inspecting the metadata for packages which match. This may get better over time, but is something to be aware of if performance is not what you'd hoped for.

  • Using a newer YUM in Fedora 7/8:

    If you want to try the latest YUM in Fedora 7 or 8, for the speed gains or for the extra features, you can do the following:

    % yum install pygpgme
    % yum install --enablerepo=development yum yum-utils python-urlgrabber
 should still review what the second command above wants to do, just to make sure it doesn't want to install 100s of packages in the later case, however I've used the above on multiple machines, on multiple architectures and on Fedora 7 and 8 ... without any problems.

Leave a comment:

No HTML allowed in subject


Notice! This user has turned on the option that logs your IP address when posting. 

(will be screened)