You are viewing illiterat

James Antill - Understanding why YUM seems "slow", and some instant solutions

May. 21st, 2008

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

Previous Entry Share Next Entry

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).

Comments:

From:(Anonymous)
Date:June 23rd, 2008 03:00 pm (UTC)

Updated But...

(Link)
I updated to the newer version and tried to install a package, but its been 45 minutes and I'm still waiting for retrieving software information to complete....
Yum is very very slow...
(Reply) (Thread)
[User Picture]
From:illiterat
Date:July 7th, 2008 02:59 pm (UTC)

Re: Updated But...

(Link)

It's fair to say something is not working then, my guess from the little information you posted is that something is holding the rpm lock and so yum is waiting for it.


(Reply) (Parent) (Thread)
[User Picture]
From:mihmo
Date:July 3rd, 2008 09:49 pm (UTC)
(Link)
There is a big difference between 10 and 4 seconds. Just saying, from a UI designer POV. :)
(Reply) (Thread)
[User Picture]
From:illiterat
Date:July 7th, 2008 02:56 pm (UTC)

Difference between 10 and 4 seconds, in context

(Link)

Kind of, if you are talking about a complete operation that you run "often" then absolutely (and if you run it very often, then even 4 seconds might be "too long"). However at the other end of the spectrum if it's one of many operations, and the others take 10-30 seconds combined and the user only runs this type of thing "rarely" then I'd have to disagree very strongly.

But let me just argue this way instead, do you have a usecase where you think the performance of yum matters from a UI point of view. You don't even need a comparison to apt/zypper/whatever, just a case where you think it's so slow it's hindering the UI. I'm not saying we can 100% "fix" it, but we'll certainly look at it.

(Reply) (Parent) (Thread)
From:(Anonymous)
Date:July 4th, 2008 09:45 am (UTC)

filelists.sqlite.bz2

(Link)
The filelists metadata are loaded too often. This is the real pain. They are big. Bigger than many updates. They are required for only few dependencies and just to make exotic packagers happy.
(Reply) (Thread)
[User Picture]
From:illiterat
Date:July 7th, 2008 02:58 pm (UTC)

Re: filelists.sqlite.bz2

(Link)

If you wish to argue that file dependencies should be removed from Fedora, then you'll have to bring that up with Fedora ... all yum can do is load the data it requires, when it requires it. Although, note that you can change metadata_expire to control how often yum will try and refresh any of it's metadata.

(Reply) (Parent) (Thread)
From:(Anonymous)
Date:October 16th, 2008 10:32 pm (UTC)

Re: filelists.sqlite.bz2

(Link)
Downloading the meta data files every time there is an update in the repository (possibly as little as one rpm among thousands) is inefficient. Over my dial-up connection (there are still many of us out here) it takes almost two hours to download all the meta data.

What is needed is a new organization of the meta data on the server so that smaller downloads suffice for installation of a package and its dependencies. Even a full update shouldn't require downloading all the meta data because most systems have only a small subset of all available packages installed.

Ideally, this new data organization would be a joint effort between the createrepo, apt-rpm, smartpm, red carpet and yum projects (the projects using the current format according to the createrepo project page).

None the less, I prefer yum to rpm and I am looking forward to the improvements in the new release, whenever RHEL/CentOS catch up with it.

(Reply) (Parent) (Thread)
[User Picture]
From:illiterat
Date:October 17th, 2008 04:45 am (UTC)

Re: filelists.sqlite.bz2

(Link)

Well yum is almost certainly the best for constrained metadata download bandwidth, due to the fact it will (by default) only download the file or changelog data when yum needs it to do some operation (most of the other options want to download everything at once). So in the simple case of installing a single package, it's very likely that you can just download the "primary" metadata file.

But, yeh, even so that can still be relatively large if you want to install a small package over a modem. yum-presto will be available/integrated in Fedora 10, which I think is a step in the direction that'll help (it provides/uses delta information).

I don't think we want to standardise anything right now, because I don't think anyone knows what the final solution is going to look like (repo. metadata was only standardised after a few different people had tried different things, and the problem was fairly well understood -- and it's still far from "perfect"). But saying that, we do keep in touch with the SuSE/zypp developers.

(Reply) (Parent) (Thread)