Bug 32297 - up2date too slow to be of use on a 486
Summary: up2date too slow to be of use on a 486
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: up2date
Version: 7.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Adrian Likins
QA Contact: Jay Turner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-03-19 20:06 UTC by Ben LaHaise
Modified: 2015-01-07 23:44 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2001-07-05 20:09:45 UTC
Embargoed:


Attachments (Terms of Use)

Description Ben LaHaise 2001-03-19 20:06:32 UTC
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 20:30:33 UTC
what package set did you have chosen?

Can you give me some memory statistics from top?




Comment 2 Ben LaHaise 2001-03-19 20:38:34 UTC
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-20 01:03:18 UTC
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-20 03:06:27 UTC
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 16:48:39 UTC
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.