Bug 118335 - poor CPU performance, especially dependency checks
poor CPU performance, especially dependency checks
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: up2date (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bret McMillan
Fanny Augustin
:
Depends On:
Blocks: up2date-fc2 120092
  Show dependency treegraph
 
Reported: 2004-03-15 12:24 EST by John Reiser
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-29 08:53:10 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
package list that was updated (341 packages) (7.08 KB, text/plain)
2004-03-15 12:28 EST, John Reiser
no flags Details

  None (edit)
Description John Reiser 2004-03-15 12:24:46 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1)
Gecko/20030225

Description of problem:
up2date took 25 minutes of CPU time [as reported by 'top'] to update
341 packages.  This is too much CPU time by a factor of 3 or 4.  A
fresh install of all 729 packages from CD-ROM (Sofware Development
Workstation, plus a few packages) takes only 18 elapsed wall-clock
minutes, and much of that is waiting for I/O.  [Machine is 1.1GHz,
784MB, UDMA100.]  Just by watching, the update was consuming 98%+ CPU
during long pauses (multiple minutes) between "phases" of I/O, and
some of these pauses included announced dependency checking.

Could there be a quadratic algorithm involved?  Topological sort is
linear in the number of relationships, and there aren't too many
packages (such as glibc) that are predecessors of almost everything,
so I don't see where the time explosion might occur.


Version-Release number of selected component (if applicable):
up2date-4.3.11-2.1.1

How reproducible:
Didn't try

Steps to Reproduce:
1. up2date 300 or more packages at a time.
2. 
3.
    

Actual Results:  'top' reports 25 minutes of CPU time for up2date.

Expected Results:  6 to 8 minutes of CPU time for up2date of 300
packages at once.

Additional info:
Comment 1 John Reiser 2004-03-15 12:28:05 EST
Created attachment 98543 [details]
package list that was updated (341 packages)

up2date was run from rhn-applet on GNOME panel of Fedora Core 2 Test 1 system,
ending at 20:25 PST Thu Mar 11.
Comment 2 Adrian Likins 2004-03-22 16:23:47 EST
rpm itself has some bits that are n^3, so yeah, it kind
of sucks some times. Though I havent seen it eat that
much cpu (the n^3 bit is a simple string compare). 

I'll take a look. 
Comment 3 John Thacker 2006-10-29 08:53:10 EST
Note that FC2 is no longer supported even by Fedora Legacy.  Also, up2date has
been replaced by pirut and pup since FC5.  FC3 and FC4 are supported by Fedora
Legacy for security issues only.  If this still occurs on FC3 or FC4 and is a
security issue, please reopen and assign to that version and Fedora Legacy.  If
it occurs on RHEL 3 or 4, please reassign or refile against that product.

The codebase for pirut and pup is quite different, so existing bugs do not
apply, but please continue testing them on the still supported versions of
Fedora Core and file bugs as necessary.

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