Lack of update information

[Ralf Corsepius]

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.
OK.

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


Ralf

[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).