Bug 53134 - up2date very slow for big packages and low memory
up2date very slow for big packages and low memory
Product: Red Hat Public Beta
Classification: Retired
Component: up2date (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Adrian Likins
Jay Turner
Depends On:
  Show dependency treegraph
Reported: 2001-09-04 05:08 EDT by Michael Young
Modified: 2015-01-07 18:51 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-10-25 06:54:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michael Young 2001-09-04 05:08:10 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.75 [en] (X11; U; SunOS 5.6 sun4u)

Description of problem:
On a 32Mb machine up2date seems to slow down considerable when downloading
packages once it has downloaded about 8Mb of a large package for the
graphics version, and about 11Mb for the text version. It sounds as if the
machine is swapping a lot beyond this point even when up2date is the only
user level process. So far I haven't managed to update the XFree86 package
(which is the biggest on my system), it looks like my first two attempts
retrieved a truncated version, presumably due to the connection timing out
somewhere along the line. (Note it looks like it still tries to install the
package, even though it knows it has a truncated version).
 Incidentally, I personally don't need a fix to this problem, I expect this
machine to be replaced very soon, but I thought I would report it in case
it is likely to affect other users.

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

How reproducible:

Steps to Reproduce:
1. Attempt to up2date a big package on a 32Mb system.

Additional info:
Comment 1 Adrian Likins 2001-09-04 13:25:40 EDT
low memory situations are a bit hard to handle. For speed reasons,
up2date keeps a in memory cache of some headers. By default, this
in memory cache is limited to 40 headers, which depending on the
headers can be 10 or 20 megs worth. The current limit is really designed
to put a cap on the "huge upgrade" situration where memory caching
all the headers isnt pratical.

You might want to try changing the value of "headerCacheSize" in
the /etc/sysconfig/rhn/up2date config file to something less than
40. This will of course increase disk reads/writes, but should
take less memeory. 

The actual install of the packages is more difficult to control
though, as thats a rpm issue, and on big package sets can often
be pretty large.
Comment 2 Michael Young 2001-10-25 06:54:47 EDT
I set the header cache to 5, but it didn't seem to make much difference, nor did
upgrading the kernel.
Comment 3 Adrian Likins 2002-03-26 18:28:17 EST
Current versions of the client are much better about memory useage.
Anything 2.7.11 or higher should handle this much better. 

There were a couple of places where I was copying buffers around
where I really didnt need to and eating way too memory.

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