Bug 32297 - up2date too slow to be of use on a 486
up2date too slow to be of use on a 486
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: up2date (Show other bugs)
7.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Jay Turner
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-19 15:06 EST by Ben LaHaise
Modified: 2015-01-07 18:44 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-07-05 16:09:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ben LaHaise 2001-03-19 15:06:32 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.1-ac20 i686)


Up2date takes more than half an hour (I didn't wait for it to finish) while
running on a 486 with 32MB of RAM over a cablemodem.  Running with the same
connection on a Celeron box with 128MB is fine.

Reproducible: Always
Comment 1 Preston Brown 2001-03-19 15:30:33 EST
what package set did you have chosen?

Can you give me some memory statistics from top?


Comment 2 Ben LaHaise 2001-03-19 15:38:34 EST
Seeing as I can't run up2date -u any more, and rhn_register is broken, I give
up.
[root@rushton /root]# rhn_register 
Traceback (innermost last):
  File "/usr/share/rhn/register/tui.py", line 1080, in ?
    main()
  File "/usr/share/rhn/register/tui.py", line 1076, in main
    tui.run()
  File "/usr/share/rhn/register/tui.py", line 1033, in run
    win = self.windows[index](self.screen, self)
  File "/usr/share/rhn/register/tui.py", line 627, in __init__
    hardware.read_cpuinfo()
  File "/usr/share/rhn/register/hardware.py", line 106, in read_cpuinfo
    hwdict['speed']         = int(round(float(mhz_speed)))
ValueError: empty string for float()
[root@rushton /root]# 
Comment 3 Adrian Likins 2001-03-19 20:03:18 EST
There is a config option for "headerCacheSize" that controls how many
headers to cache in ram. The default is 40. Try lowering this to
something like 10. Of course, this just trades swapping for lots
of reading headers from disk, but on low mem machines, the later
is probabaly faster.
Comment 4 Bill Nottingham 2001-03-19 22:06:27 EST
FWIW, as another datapoint, I ran it on a 486 here; it upgraded
vixie-cron, db3, popt, rpm, and rpm-python. Time was:

real    5m9.777s
user    4m5.990s
sys     0m26.130s

Certainly not fast, but not too bad. 486-50, 24MB memory, 42MB swap.

Comment 5 Jay Turner 2001-03-20 11:48:39 EST
The issue about CPU speed on a 486 has been resolved and the fix is in CVS as
well as the built package in the tree.

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