Hello I have updated 3 boxes from FC5->FC6 (x86_64) using anaconda (booted from a DVD). All three of them is nothing that can be called a slow machine: 1) AMD64 3000+ @ 4100+ (2.61ghz) 1024MB RAM 7200 RPM 2MB Cache IDE Seagate HDD 120GB 2) Laptop: Core 2 Duo T7400 2x2.17Ghz 4MB shared L3 Cache 2048MB RAM 7200 RPM 8MB Cache SATA Hitatchi HDD 80GB 3) AMD Opteron 170 @ 2x2.7Ghz 2048MB RAM 2x120GB Hitatchi SATAII HDD 8MB Cache MD RAID0
Update time was ~90-120min depending on the sys. Why does the update take that long? A reinstall is much faster.. I think that improving this should be a goal for FC7 Also why isn't it possible to install from a md raid partition? Should I fill a RFE?
I have updated 3 boxes from FC5->FC6 (x86_64) using anaconda (booted from a DVD).
Update time was ~90-120min depending on the sys.
It feels like there is a quadratic algorithm somewhere, plus slow database operation (non-cached, or poor transactions): http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208725 http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208717 http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209323 http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=208726
Also, mere package install itself can speedup by a factor of 5: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=71184
On Friday 27 October 2006 13:17, dragoran wrote:
Update time was ~90-120min depending on the sys. Why does the update take that long? A reinstall is much faster.. I think that improving this should be a goal for FC7 Also why isn't it possible to install from a md raid partition? Should I fill a RFE?
How many packages did you have on each box? An upgrade is always going to be slower than an install. Twice the actions.
On Fri, 2006-10-27 at 11:13 -0700, John Reiser wrote:
It feels like there is a quadratic algorithm somewhere,
As usual, I ride the edge and am yum updating all my machines. First I tried my laptop which is a 700mhz PIII. I installed the new fedora-release package, did a "yum update glibc*" then "yum update yum * rpm*", so that its running the FC6 yum/rpm, before going for a full "yum update". It pegs the CPU for a long long time after "Reading repository metadata in from local files". Its not noticeably accessing the disk, or using a large amount of RAM. The system time is at 30%, yum takes the rest. The fan in my laptop is horribly worn out, something pegging the CPU for more than a minute or so causes it to overheat and turn off. I have been unable to complete a "yum update". I one sat and kept smacking the fan so it would keep spinning, yum went for a good 20 minutes before I got bored and distracted and let it overheat. (Sudden power failures during an RPM transaction is GREAT for your package database...) Updating a subset of packages at a time is much faster, "yum update xorg*", "yum update lib*", but it still takes 10sec-1min in the CPU crunching state depending on how many packages are involved.
I'm trying it right now on my Athlon 64 3000+ desktop. I installed the release file, did a "yum update glibc*", then went for a "yum update", so this time its with the FC5 yum. It didn't spend more than a few seconds after reading the metadata before it went to "Resolving Dependencies", spewing out lines of "Package xxxxxx set to be updated". (and eventually failing due to some weird dependency problem)
So now I just did a "yum update rpm* yum*", "yum clean all", then tried "yum update". Its doing the same thing, pegging the CPU, 20% system time, yum eating the rest. It took almost exactly 5 minutes to get from "Reading repository metadata in from local files" to "Resolving Dependencies".
I'd say yes, there's something going horribly wrong in the FC6 yum.
On Saturday 28 October 2006 02:35, dragoran wrote:
slower than an install. Twice the actions.
~1400-1600 Its seems not be 2 times slower its 3 or 4 times.
I didn't say it would be twice as slow, I said there are 2x the actions, plus a lot more processing in the actual LOOKING for updates.
Dnia 27-10-2006, pią o godzinie 14:15 -0500, Callum Lerwick napisał(a):
I installed the new fedora-release package, did a "yum update glibc*" then "yum update yum * rpm*", so that its running the FC6 yum/rpm, before going for a full "yum update". It pegs the CPU for a long long time after "Reading repository metadata in from local files".
I did the same thing, only I was smarter - besides of glibc, rpm and yum, I upgraded apt at the same time :) My old Pentium 4 1,8 GHz couldn't do the yum calculations for 15 or 20 minutes, when I just killed yum and did apt-get dist-upgrade. Guess what, it takes about 10 seconds to read everything from disk and calculate dependencies of my ~1300 packages.
So, simply stick to apt and never look back, even if they tell you yum is the supported dependency resolver. My (apt-driven) upgrade of FC5 to FC6 on Wednesday is a complete success story.
Of course, after downloading everything, it took rpm over 1,5 hour to upgrade, so the main thread about Anaconda is an effect of the two (yum and rpm) joining forces.
Lam
dragoran wrote:
Update time was ~90-120min depending on the sys. Why does the update take that long? A reinstall is much faster..
(This is an old thread but my reply seems pertinent here.)
I can confirm that upgrading takes really a long time, even on powerful hardware and by using local nfs instead of optical discs.
I'm trying to upgrade a ppc machine (2x1.8GHz G5, 512MiB RAM, SATA disk) from FC4 to FC6 by DVD and the first estimated remaining time was more than 1600 minutes.
Reports from top, vmstat, ps pointed me to one big bottleneck: every package involving libs runs ldconfig, which takes a lot of time.
So I renamed /mnt/sysconfig/sbin/ldconfig away and replaced with a copy of /bin/true. The installation speed went up a lot, I'd say it's 10 times faster now.
I suppose that running ldconfig continously is not useful, it could be done just once at the end of the upgrade.
The upgrade is still in progress so I don't know if the system will have problems caused by this trick.
Comments?
Best regards.
On Tue, 2007-02-20 at 13:50 +0100, Roberto Ragusa wrote:
So I renamed /mnt/sysconfig/sbin/ldconfig away and replaced with a copy of /bin/true. The installation speed went up a lot, I'd say it's 10 times faster now.
I suppose that running ldconfig continously is not useful, it could be done just once at the end of the upgrade.
Not quite I think. Other (later-run) scripts might use those libraries so ldconfig has to be be run before them so they can work. Perhaps those calls could be clustered into one, but I don't know whether this can be done without changes to RPM.
Nils
On Tue, Feb 20, 2007 at 03:09:12PM +0100, Nils Philippsen wrote:
I suppose that running ldconfig continously is not useful, it could be done just once at the end of the upgrade.
Not quite I think. Other (later-run) scripts might use those libraries so ldconfig has to be be run before them so they can work. Perhaps those calls could be clustered into one, but I don't know whether this can be done without changes to RPM.
I wonder if ld.so could be changed to run the cache update as needed, on-the-fly?
Chuck Anderson wrote:
On Tue, Feb 20, 2007 at 03:09:12PM +0100, Nils Philippsen wrote:
I suppose that running ldconfig continously is not useful, it could be done just once at the end of the upgrade.
Not quite I think. Other (later-run) scripts might use those libraries so ldconfig has to be be run before them so they can work. Perhaps those calls could be clustered into one, but I don't know whether this can be done without changes to RPM.
I wonder if ld.so could be changed to run the cache update as needed, on-the-fly?
should be possible (using inotify and only add the new created files to the cache) but for this we need a ld daemon (dunno if its possible to update only a part of the cache) /sbin/ldconfig can check if the daemon is running and if yes just do nothing, else work as it used to be (like it did before). (still works when daemon is not running). this would also speed up yum updates too.
about yum: afaik currently yum works like this get metadata for repo A get metadata for repo B ... parse metadata for repo A parse metadata fro repo B ... why waiting so long until parsing metadata of repo B ? why not do it after download while downloading b? so yum can just create a thread for each repo to do the download + parse for each repo in a thread and do this for many repos in parrallel. this should speed up yum init (dunno by how much and dunno if it benifits from smp systems or not but it should) but why only doing this for repo parsing? why not for getting package headers (there are not that big so bandwith should not be the bottleneck, but waiting for nothing is it)
I don't have any code (and so no benchmarks) but I think this ideas could speed up the install/update of packages alot (not only a few %).
Nils Philippsen wrote:
On Tue, 2007-02-20 at 13:50 +0100, Roberto Ragusa wrote:
So I renamed /mnt/sysconfig/sbin/ldconfig away and replaced with a copy of /bin/true. The installation speed went up a lot, I'd say it's 10 times faster now.
I suppose that running ldconfig continously is not useful, it could be done just once at the end of the upgrade.
Not quite I think. Other (later-run) scripts might use those libraries so ldconfig has to be be run before them so they can work. Perhaps those calls could be clustered into one, but I don't know whether this can be done without changes to RPM.
Good point. Anyway, the installation completed and I don't see evident problems.
The complete process was quite interesting:
1) launched update from FC4 to FC6; after a few hours anaconda apparently locked: from what I saw, the system was out of memory (512MiB, the swap partition already present on the disk was not autoactivated)
2) started the update process again (from FC6 to FC6, according to anaconda), activated the swap partition manually
3) at about 25% of (slow) progress, renamed the ldconfig exe away
4) at the end of the upgrade, renamed ldconfig back and, maybe, chrooted and ran ldconfig (I don't remember if I did that or not)
5) rebooted the system
At that point the system appeared perfectly working, but any attempt to start X or reconfigure X (including using system-config-display) failed, even if the xorg.conf file was apparently ok.
I investigated around and discovered "rpm -qa" was giving many duplicate entries; I was going to blame the first aborted update, but soon realized it was all good, just ppc+ppc64 versions.
Assuming the problems with X could have been related to failed upgrading scripts (according to your hint), I just launched a full "yum update", hoping that the missing scripts would be run successfully somewhere in those 1.1GB of updates.
The X problem persisted, but the issue was really trivial: no xorg-x11-drv* package had been installed! After the installation of xorg-x11-drivers everything appears ok on the system, the KDE desktop runs perfectly.
So, at the end of all this, I can say that the ldconfig trick, while certainly dirty, didn't result as dangerous as you thought. Maybe the first aborted installation (with normal ldconfig) did help, by correctly upgrading the fundamental parts of the system (glibc,...) and so avoiding script failures later (when ldconfig was off).
I still hope some way to speedup the FC update process will come out, as it is becoming more and more annoying with new versions. (and the FC6->FC7 upgrade will include extras...)
Best regards.
On Tue, Feb 20, 2007 at 08:16:21PM +0100, dragoran wrote:
I wonder if ld.so could be changed to run the cache update as needed, on-the-fly?
should be possible (using inotify and only add the new created files to the cache) but for this we need a ld daemon (dunno if its possible to update only a part of the cache) /sbin/ldconfig can check if the daemon is running and if yes just do nothing, else work as it used to be (like it did before). (still works when daemon is not running). this would also speed up yum updates too.
I was thinking more like this:
When ld.so loads the ELF binary to run, it resolves library requirements. Instead of printing error messages and exiting when it can't find the required libs, just do what ldconfig would do instead, then retry loading the program again.
devel@lists.stg.fedoraproject.org
-
Callum Lerwick -
Chuck Anderson -
drago01 -
dragoran -
Jesse Keating -
John Reiser -
Leszek Matok -
Nils Philippsen -
Roberto Ragusa