Red Hat Bugzilla – Bug 32297
up2date too slow to be of use on a 486
Last modified: 2015-01-07 18:44:35 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.
what package set did you have chosen?
Can you give me some memory statistics from top?
Seeing as I can't run up2date -u any more, and rhn_register is broken, I give
[root@rushton /root]# rhn_register
Traceback (innermost last):
File "/usr/share/rhn/register/tui.py", line 1080, in ?
File "/usr/share/rhn/register/tui.py", line 1076, in main
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__
File "/usr/share/rhn/register/hardware.py", line 106, in read_cpuinfo
hwdict['speed'] = int(round(float(mhz_speed)))
ValueError: empty string for float()
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.
FWIW, as another datapoint, I ran it on a 486 here; it upgraded
vixie-cron, db3, popt, rpm, and rpm-python. Time was:
Certainly not fast, but not too bad. 486-50, 24MB memory, 42MB swap.
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.