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).
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
