Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 118335 - poor CPU performance, especially dependency checks
Summary: poor CPU performance, especially dependency checks
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: up2date
Version: rawhide
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bret McMillan
QA Contact: Fanny Augustin
URL:
Whiteboard:
Depends On:
Blocks: up2date-fc2 120092
TreeView+ depends on / blocked
 
Reported: 2004-03-15 17:24 UTC by John Reiser
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-10-29 13:53:10 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)
package list that was updated (341 packages) (deleted)
2004-03-15 17:28 UTC, John Reiser 		no flags Details
View All

Description John Reiser 2004-03-15 17:24:46 UTC 
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 17:28:05 UTC 
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 21:23:47 UTC 
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 13:53:10 UTC 
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.