[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Lack of update information

seth vidal wrote:
On Wed, 2009-01-28 at 05:31 +0100, Ralf Corsepius wrote:

On an i586, the times requires for yum updates are much higher (typically hours), times on old i686's are in the order of several 10 minutes.

Any idea how much of the i586 transaction time is swapping?
Likely much of it, however I have no idea on how to measure it ;)

Anyway, FWIW, here is a short protocol of a yum update session on this machine (performed in recent hours):

* System i586MMX/166MHz, 64MB RAM, 2GB IDE HD.
# cat /proc/cpuinfo
vendor_id	: GenuineIntel
cpu family	: 5
model		: 4
model name	: Pentium MMX
stepping	: 4
cpu MHz		: 166.653

# cat /proc/meminfo
MemTotal:        59264 kB
SwapTotal:      131064 kB

* SELinux is disabled[1]
* System is running Fedora 10 in runlevel 3, with "top" in a shell on vt1 and running "yum update" in an ssh-login from a remote machine.
* Active repos: fedora, updates.

Observations on swap and yum's memory usage:
* no swapping until yum reports "Setting up Update Process"
* During "Setting up Update Process", yum's "VIRT mem" gradually crawls up.
* At "Transaction Summary"/"Is this OK?", yum's "VIRT mem" has reached ca. 64MB/ca. 40MB swap is in use.
* No substantial changes to memory/swap during "Downloading Packages"
* During "Running rpm_check_debug", yum's "VIRT mem" increases to ca. 73MB, using ca. 44MB swap. * During "Running Transaction Test", yum's "VIRT mem" swings in the 70-76MB range. During all this, "swap in use" is gradually increases to ca. 54MB. * During "Running Transaction", yum's "VIRT mem" swings in the same range, "swap in use" increases to 56MB. * When the actual installation starts, yum's "VIRT mem" stays near 74MB, while "swap in use" swings at a +/-20MB applitude around ca. 65MB [3][4]. * During "cleanup" yum's "VIRT mem" reaches 78MB, while swap stays near 65MB.

Observations on times being required (wall-clock measured):
* Time until "Is this OK?" had been ca. 10-15 minutes.
* "Downloading Packages" took ca. 5 minutes (using a (fast) local mirror).
* The time from "Is this OK?" to "Finished Transaction Test" was
ca. 1 hour.
* The "Running Transaction" stage took ca. 1 hour.
* The actual "update/installation" stage took ca. 1/2 hour.
* The "cleanup" stage took ca. 1/4 hour.
Total time: ca. 3 hours.

People are working on both of the above issues.
Really? I doubt your claim. At least I am not aware of any activities in RH's rpm to change rpm's payload rsp. to perform measurements on the impact of using modern compressors on rpm-payloads.

well one of the memory intensive portions of the transaction is being
worked on.   The file fingerprinting.

What I actually would like to know is which impact switching to e.g. bzip2 or lzma compressed payloads would have on end-users.

I.e. answers/input related to
* disk-space requirements
Would such step shrink the isos rsp. give room on isos?
* end-user's throughput during downloads.
In the past, there have been claims, bzip2 compression would have negative impacts on network-throughput because it would defeat low-level compression on networks (e.g. modems, isdn). Is this claim true, can it be verified, how about lzma and friends? * rpm's installation times/memory requirement (time required for decompression, memory being used during decompression).
bzip2 has quite


[1] Kernel OOMs when SELinux is enabled.

[2] Different setup as in the netbook example. Also, the i586 had not been updated since early January.

[3] The maximum swap space usage seems to have occurred, when the kernel package was updated. depmod appeared to have caused the maximum of swap space usage.

[4] Visible as time-consuming tools in "top" (in decreasing order):
mkinitrd (several minutes), gconftool-2 (several seconds), ldconfig (frequently called; very few seconds per invocation).

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]