7:23 a.m.
Hi,
I'd like to reduce the memory footprint of FC6. Are there already
webpages that describe how to make Fedora more manageable on those 3-4
year old "junk hardware"? (Some also have worried about the disk
space footprint, but let's leave that out of scope for now..)
I think we have a problem if FC6 can't run properly on IBM ThinkPad
X30 w/ P3/1200 and 256 MB of memory. I think the main bottlenecks are
the amount of memory, relatively slow disks, and swapping on those
relatively slow disks.
A couple of observations:
1) with RHL73 (w/ fvwm2), the battery lasted for 3.5-4.5 hours.
With FC5 or FC6 (with xfce), it lasts for 1.5 hours, even if the
computer is "idle". Either ACPI is a lot worse than APM, or
something is going on. Any ideas how to debug this?
2) yum upgrade from FC5 to FC6 (about 1100 packages) took 8 hours
(just the depsolving, upgrade and cleanup -- all packages and
headers already existed on local disk). Only yum and Xorg were
running at that time.
3) are there more light-weight desktops/WMs than xfce? Recently, it
seems it also has become bloated, e.g.,:
psavola 2644 0.0 3.3 72840 8292 ? Ss Nov21 0:07 xfce-mcs-manager
psavola 2650 0.0 3.7 76792 9140 ? S Nov21 0:31 /usr/bin/xfce4-panel
psavola 2654 0.0 3.1 68484 7844 ? S Nov21 0:02
/usr/libexec/xfce4/panel-plugins/xfce4-menu-plugin [...]
psavola 2745 0.2 3.2 82388 7964 ? S Nov21 1:49
/usr/libexec/xfce4/panel-plugins/xfce4-battery-plugin [...]
and:
$ ldd /usr/libexec/xfce4/panel-plugins/xfce4-battery-plugin
linux-gate.so.1 => (0x00117000)
libxfce4panel.so.1 => /usr/lib/libxfce4panel.so.1 (0x005c4000)
libxfcegui4.so.4 => /usr/lib/libxfcegui4.so.4 (0x003d4000)
libxfce4util.so.4 => /usr/lib/libxfce4util.so.4 (0x00435000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x006fc000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x00118000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x001a5000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x00368000)
libm.so.6 => /lib/libm.so.6 (0x0050f000)
libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x001c1000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x00f1e000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0x001ca000)
libgobject-2.0.so.0 => /lib/libgobject-2.0.so.0 (0x00236000)
libgmodule-2.0.so.0 => /lib/libgmodule-2.0.so.0 (0x00dbb000)
libdl.so.2 => /lib/libdl.so.2 (0x00110000)
libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x00275000)
libc.so.6 => /lib/libc.so.6 (0x00a94000)
libSM.so.6 => /usr/lib/libSM.so.6 (0x00313000)
libICE.so.6 => /usr/lib/libICE.so.6 (0x0031c000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x005da000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00336000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x0037f000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00eea000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00d04000)
libXi.so.6 => /usr/lib/libXi.so.6 (0x00e99000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00d55000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x0038f000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00da6000)
/lib/ld-linux.so.2 (0x006e1000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x00bdd000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00444000)
libz.so.1 => /usr/lib/libz.so.1 (0x00399000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x003ac000)
librt.so.1 => /lib/librt.so.1 (0x00423000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x00d4e000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00df0000)
libexpat.so.0 => /lib/libexpat.so.0 (0x004d3000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00c39000)
Something is wrong when when a simple battery plugin takes 80 MB of
memory..
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
7:36 a.m.
Pekka Savola <pekkas <at> netcore.fi> writes:
I'd like to reduce the memory footprint of FC6. Are there
already
webpages that describe how to make Fedora more manageable on those 3-4
year old "junk hardware"? (Some also have worried about the disk
space footprint, but let's leave that out of scope for now..)
In my experience, the biggest problem with Fedora on low-memory systems is
getting it installed. Anaconda tends to just lock up or reboot if it doesn't
have at least something like 256 MB RAM. As for actually running it, it just
works on my Pentium II 266 laptop with 160 MB RAM. Some apps like Synaptic
(command-line apt and aptitude are bearable) and the usual suspects (OO.o,
Eclipse) are just unusable or borderline unusable though. Synaptic used to
require a lot less memory with the old repository format, repomd is a big
memory eater (which might also explain why Anaconda needs so much memory).
Kevin Kofler
9:27 a.m.
On Wed, Nov 22, 2006 at 01:36:10PM +0000, Kevin Kofler wrote:
In my experience, the biggest problem with Fedora on low-memory
systems is
getting it installed. Anaconda tends to just lock up or reboot if it doesn't
have at least something like 256 MB RAM.
Indeed, a network install with 128MB just doesn't work; Something
called 'exe' gets hung trying to install glibc. :-(
I noticed that the RAM file systems in use are actually ramfs, not
tmpfs, so even after swap is enabled, swap can't be used as backing
store for the files we're downloading, some of which are quite large.
Doing a local CD-ROM install did succeed on this same system, which
leads me to think that the ramfs->tmpfs switch might be beneficial for
exactly this reason.
-Matt
--
Matt Domsch
Software Architect
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
10:08 a.m.
Matt Domsch wrote:
Indeed, a network install with 128MB just doesn't work;
Something
called 'exe' gets hung trying to install glibc. :-(
I noticed that the RAM file systems in use are actually ramfs, not
tmpfs, so even after swap is enabled, swap can't be used as backing
store for the files we're downloading, some of which are quite large.
Doesn't the installer's "stage2" filesystem get put into "swap
space"
on low-memory machines during a network install?
Doing a local CD-ROM install did succeed on this same system, which
leads me to think that the ramfs->tmpfs switch might be beneficial for
exactly this reason.
--
10:05 a.m.
In my experience, the biggest problem with Fedora on low-memory
systems is
getting it installed.
The RULE Project (Run Up2date Linux Everywhere) has an installer "slinky"
http://www.fzk.at/SLINKY/ that can install Fedora Core 5 in 32MB RAM.
I did it in 64MB on a PentiumMMX-166 in about 3.5 hours. Starting OpenOffice
took two minutes, but typing and mousing was fine.
On a network, then a "reverse NFS install" can be used. Boot the target
machine using a rescue CD or DVD, partition+format+mount the disk,
start NFS and export the target root filesystem. From another machine
on the network, run rpm using "--dbpath DIRECTORY" and "--root
DIRECTORY"
to re-direct those places to the target machine. You might also need
to use --ignorearch. After installing kernel, glibc, grub, and yum
(use "--aid" to fill in the dependencies), then you'll have enough to boot
the target machine by itself, and finish installation using yum and
system-config-*.
--
1:17 p.m.
John Reiser <jreiser <at> BitWagon.com> writes:
The RULE Project (Run Up2date Linux Everywhere) has an installer
"slinky"
http://www.fzk.at/SLINKY/ that can install Fedora Core 5 in 32MB RAM.
I did it in 64MB on a PentiumMMX-166 in about 3.5 hours. Starting OpenOffice
took two minutes, but typing and mousing was fine.
That's probably the best solution for fresh installs. For upgrades, apt-get
dist-upgrade will get you through. I guess yum or smart will also work. That's
also the way to get FC6 until Slinky is updated for it.
For my laptop (160 MB RAM), what I did was:
* install FC2 (back when it was current), an almost minimal install
(essentially minimal+KDE) over HTTP worked
* upgrade to FC5 using Anaconda when that was current - not a nice experience,
Anaconda just hung when reading in the metadata for the second ISO, requiring a
restart, and so on; at least, it didn't crash during a transaction and leave
duplicated packages around (i.e. I was lucky)
* upgrade to FC6 using apt-get dist-upgrade. No hickups other than that I had
to rpm --rebuilddb afterwards, it's probably the same "corrupted RPM
database"
bug there's already a thread about on one of the lists. (It also hits some yum
or Anaconda users.)
Kevin Kofler
8:23 a.m.
Pekka Savola wrote:
Hi,
I'd like to reduce the memory footprint of FC6. Are there already
webpages that describe how to make Fedora more manageable on those 3-4
year old "junk hardware"? (Some also have worried about the disk space
footprint, but let's leave that out of scope for now..)
Some ideas here:
http://www.redhat.com/archives/fedora-devel-list/2006-May/thread.html#00498
I think we have a problem if FC6 can't run properly on IBM
ThinkPad X30
w/ P3/1200 and 256 MB of memory. I think the main bottlenecks are the
amount of memory, relatively slow disks, and swapping on those
relatively slow disks.
Some good optimizations will fall out of the OLPC work.
Also independently people are starting to look at bloat:
http://primates.ximian.com/~federico/news.html
A couple of observations:
1) with RHL73 (w/ fvwm2), the battery lasted for 3.5-4.5 hours.
With FC5 or FC6 (with xfce), it lasts for 1.5 hours, even if the
computer is "idle". Either ACPI is a lot worse than APM, or
something is going on. Any ideas how to debug this?
When was the last time you tried 7.3? I.E. are you sure
you haven't lost cell(s) in your battery in the meantime?
2) yum upgrade from FC5 to FC6 (about 1100 packages) took 8 hours
(just the depsolving, upgrade and cleanup -- all packages and
headers already existed on local disk). Only yum and Xorg were
running at that time.
http://www.redhat.com/archives/fedora-devel-list/2006-October/thread.html...
Also anaconda need loads of memory any may be swapping with 256MB RAM?
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186067
3) are there more light-weight desktops/WMs than xfce?
http://xwinman.org/
Recently, it seems it also has become bloated, e.g.,:
psavola 2745 0.2 3.2 82388 7964 ? S Nov21 1:49
/usr/libexec/xfce4/panel-plugins/xfce4-battery-plugin [...]
I don't know what that is the output of exactly, but be careful
with mem reporting tools on linux as they are confusing at best.
Have a look at http://www.pixelbeat.org/scripts/ps_mem.py
Pádraig.
10:10 a.m.
On Wed, 22 Nov 2006, Pádraig Brady wrote:
> I'd like to reduce the memory footprint of FC6. Are there
already
> webpages that describe how to make Fedora more manageable on those 3-4
> year old "junk hardware"? (Some also have worried about the disk space
> footprint, but let's leave that out of scope for now..)
Some ideas here:
http://www.redhat.com/archives/fedora-devel-list/2006-May/thread.html#00498
Thanks.
> A couple of observations:
>
> 1) with RHL73 (w/ fvwm2), the battery lasted for 3.5-4.5 hours.
> With FC5 or FC6 (with xfce), it lasts for 1.5 hours, even if the
> computer is "idle". Either ACPI is a lot worse than APM, or
> something is going on. Any ideas how to debug this?
When was the last time you tried 7.3? I.E. are you sure
you haven't lost cell(s) in your battery in the meantime?
About a year ago, a bit more. Given that the laptop is ~4 years old
now, such a dramatic drop IMHO cannot be explained by battery aging
alone. However, the proc says:
# more /proc/acpi/battery/BAT0/info
present: yes
design capacity: 47520 mWh
last full capacity: 18260 mWh
...
The ratio of "last full" and "design" is similar to the 1.5h/4.0h
lifetime I'm now seeing. Unfortunately, I don't know what the numbers
might have been with RHL73, and whether ACPI/APM has any effect here.
> 2) yum upgrade from FC5 to FC6 (about 1100 packages) took 8
hours
> (just the depsolving, upgrade and cleanup -- all packages and
> headers already existed on local disk). Only yum and Xorg were
> running at that time.
http://www.redhat.com/archives/fedora-devel-list/2006-October/thread.html...
Also anaconda need loads of memory any may be swapping with 256MB RAM?
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186067
Interesting -- but in my case, I wasn't running anaconda. I did 'yum
upgrade' from command line.
In case a rough breakdown of time spent in each step would be useful,
depsolving took a while, but only in the order of dozens of minutes.
Running transaction check took something around 30-60 minutes. The
first stage of running transaction for real (i.e., before any progress
bards appeared) took a very long time, maybe 1-2 hours. The upgrade
itself took maybe 3 hours. The cleanup took maybe 2-3 hours.
> 3) are there more light-weight desktops/WMs than xfce?
http://xwinman.org/
Unfortunately, that doesn't answer the question of 'more light-weight'
as I fear that xfce is the most lightweight of the desktop bunch at
least...
> Recently, it seems it also has become bloated, e.g.,:
>
> psavola 2745 0.2 3.2 82388 7964 ? S Nov21 1:49
> /usr/libexec/xfce4/panel-plugins/xfce4-battery-plugin [...]
I don't know what that is the output of exactly, but be careful
with mem reporting tools on linux as they are confusing at best.
Have a look at http://www.pixelbeat.org/scripts/ps_mem.py
That shows total memory usage of 197 MB (including firefox taking
82MB), though top reports that 100+ MB of swap is being used:
Mem: 246632k total, 240024k used, 6608k free, 3096k buffers
Swap: 521632k total, 106408k used, 415224k free, 37504k cached
Not sure which is more accurate.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
1:21 p.m.
Pekka Savola <pekkas <at> netcore.fi> writes:
Unfortunately, that doesn't answer the question of 'more
light-weight'
as I fear that xfce is the most lightweight of the desktop bunch at
least...
It depends on what "desktop" features you want. IceWM provides a taskbar if
that's what you expect of a desktop. As for desktop icons, you can use ROX
Filer to display these with any WM (including IceWM).
Personally, I just run KDE on my 160 MB RAM laptop though. ;-)
Kevin Kofler
10:35 a.m.
At 2:23 PM +0000 11/22/06, Pádraig Brady wrote:
Pekka Savola wrote:
...
> 1) with RHL73 (w/ fvwm2), the battery lasted for 3.5-4.5 hours.
> With FC5 or FC6 (with xfce), it lasts for 1.5 hours, even if the
> computer is "idle". Either ACPI is a lot worse than APM, or
> something is going on. Any ideas how to debug this?
When was the last time you tried 7.3? I.E. are you sure
you haven't lost cell(s) in your battery in the meantime?
...
Also, back in 7.3 time the kernel probably had HZ=100, and now it is
usually 250 or 1000. Slow laptops may not get back to sleep at all between
ticks. The kernel can be recompiled for 100 Hz to give better battery
life. (AIUI a recompile is needed, I haven't done any such thing.)
--
____________________________________________________________________
TonyN.:' The Great Writ <mailto:tonynelson@georgeanelson.com>
' is no more. <http://www.georgeanelson.com/>
9:52 a.m.
>> 1) with RHL73 (w/ fvwm2), the battery lasted for 3.5-4.5
hours.
>> With FC5 or FC6 (with xfce), it lasts for 1.5 hours, even if the
>> computer is "idle". Either ACPI is a lot worse than APM, or
>> something is going on. Any ideas how to debug this?
Also, back in 7.3 time the kernel probably had HZ=100, and now it is
usually 250 or 1000. Slow laptops may not get back to sleep at all between
ticks.
'hald' polls all CD and DVD drives to detect when a disk is inserted.
I see about 9 interrupts per second per drive. For example on common
x86 clone boxes with CD as /dev/hdc or /dev/hdd (and no harddrives there):
grep ide1 /proc/interrupts; sleep 10; grep ide1 /proc/interrupts
hald ought to have a settable parameter to control this.
Until then: try putting a disk into the drive(s), or kill hald-addon-storage.
--
10:21 a.m.
...... Original Message .......
On Wed, 22 Nov 2006 15:23:21 +0200 (EET) "Pekka Savola"
<pekkas(a)netcore.fi>
wrote:
Hi,
I'd like to reduce the memory footprint of FC6. Are there already
webpages that describe how to make Fedora more manageable on those 3-4
year old "junk hardware"? (Some also have worried about the disk
space footprint, but let's leave that out of scope for now..)
I think we have a problem if FC6 can't run properly on IBM ThinkPad
X30 w/ P3/1200 and 256 MB of memory.
I agree.
The Playstion 3 only has 256MB of memory too. Once I'm eventually able to
locate one to buy (not Ebay), I plan on getting FC6/Rawhide running on it.
___
Dax Kelson
Sent with my Treo
(please pardon any brevity)
5:55 a.m.
On Wed, 2006-11-22 at 15:23 +0200, Pekka Savola wrote:
Hi,
I'd like to reduce the memory footprint of FC6. Are there already
webpages that describe how to make Fedora more manageable on those 3-4
year old "junk hardware"? (Some also have worried about the disk
space footprint, but let's leave that out of scope for now..)
I think we have a problem if FC6 can't run properly on IBM ThinkPad
X30 w/ P3/1200 and 256 MB of memory. I think the main bottlenecks are
the amount of memory, relatively slow disks, and swapping on those
relatively slow disks.
A couple of observations:
1) with RHL73 (w/ fvwm2), the battery lasted for 3.5-4.5 hours.
With FC5 or FC6 (with xfce), it lasts for 1.5 hours, even if the
computer is "idle". Either ACPI is a lot worse than APM, or
something is going on. Any ideas how to debug this?
I'd guess you're hitting the disk and draining the battery.
2) yum upgrade from FC5 to FC6 (about 1100 packages) took 8 hours
(just the depsolving, upgrade and cleanup -- all packages and
headers already existed on local disk). Only yum and Xorg were
running at that time.
yum is a python application and as such, will always be slower and more
memory intensive then c/cpp based applications (such as apt) -
especially when it comes to CPU/memory intensive tasks such as
dep-solving.
3) are there more light-weight desktops/WMs than xfce? Recently, it
seems it also has become bloated, e.g.,:
[snip]
Something is wrong when when a simple battery plugin takes 80 MB
of
memory..
XFCE 4.4 is a real memory hog - almost as much as KDE/GNOME do.
I'm using IceWM on my PII366/256MB laptop and it works like a champ.
I'll submit the RPM to extra when I'll have some free time.
- Gilboa
8 a.m.
On Thursday 23 November 2006 06:55, Gilboa Davara wrote:
especially when it comes to CPU/memory intensive tasks such as
dep-solving.
Except that the depsolving is done by rpm libraries which are C, so invalid
argument.
Also the "slow" process of loading metadata in from disk has an optional
(installed by default) c plugin to speed that part up.
--
Jesse Keating
Release Engineer: Fedora
8:33 a.m.
On Thu, 2006-11-23 at 09:00 -0500, Jesse Keating wrote:
On Thursday 23 November 2006 06:55, Gilboa Davara wrote:
> especially when it comes to CPU/memory intensive tasks such as
> dep-solving.
Except that the depsolving is done by rpm libraries which are C, so invalid
argument.
I stand corrected then. My mistake.
Also the "slow" process of loading metadata in from disk
has an optional
(installed by default) c plugin to speed that part up.
I know I'll be flogged for asking it... which one? (The only I'm aware
of [and using] is fastestmirror [1])
- Gilboa
[1] http://wiki.linux.duke.edu/YumPlugins
9:30 a.m.
On Thu, 2006-11-23 at 09:54 -0500, Jesse Keating wrote:
On Thursday 23 November 2006 09:33, Gilboa Davara wrote:
> I know I'll be flogged for asking it... which one? (The only I'm aware
> of [and using] is fastestmirror [1])
The metaparser. yum-metadata-parser
Oh... OK. Already have it installed.
yum/FC6 is indeed faster then FC4/5.
I apologize for stirring the hornet's nest, but on a low end machine
(P2/366, 256MB) even with metadata-parser -and- fastestmirror, yum is
slower by an order of magnitude than apt-get (both apt-rpm and Debian's
apt) and slapt-get (slackware) and requires twice as much memory.
I'm talking about "yum -y -C update" compared to "apt-get -y
dist-upgrade"
Am I the only one having this problem?
Did anyone try to instrument yum in-order to solve this problem?
- Gilboa
11:04 a.m.
Dnia 23-11-2006, czw o godzinie 17:30 +0200, Gilboa Davara napisał(a):
yum is slower by an order of magnitude than apt-get
Am I the only one having this problem?
Well, on this machine,
yum -C update takes 14-18 seconds and apt-get
dist-upgrade takes 9-11 seconds to resolve everything and ask me if I
want to download. At this point, yum takes 7 MiB of memory (ps's SZ),
while apt-get takes 30 MiB (more precisely, apt-shell takes 6,8 to
resolve dependencies, but 30 when you tell it to commit). I still prefer
apt for lots of other reasons, but nowadays it's not so much faster and
doesn't look lighter at all.
Lam
11:49 a.m.
On Thu, 2006-11-23 at 18:04 +0100, Leszek Matok wrote:
Dnia 23-11-2006, czw o godzinie 17:30 +0200, Gilboa Davara
napisał(a):
> yum is slower by an order of magnitude than apt-get
> Am I the only one having this problem?
Well, on this machine, yum -C update takes 14-18 seconds and apt-get
dist-upgrade takes 9-11 seconds to resolve everything and ask me if I
want to download. At this point, yum takes 7 MiB of memory (ps's SZ),
while apt-get takes 30 MiB (more precisely, apt-shell takes 6,8 to
resolve dependencies, but 30 when you tell it to commit). I still prefer
apt for lots of other reasons, but nowadays it's not so much faster and
doesn't look lighter at all.
Lam
I'll be the first one to admit that my information is subjective and
lacking.
But here's a small test [1] I just conducted on my workstation (2Sx2Cx4G
machine) which has Debian guest running under vmware-server. (Be aware
that the guest is limited to 512MB and uses two VCPUs)
Step0:
Get all the recent updates for both OS. (yum -C -y update [FC6 host];
apt-get -y update && apt-get -y dist-upgade [Debian guest])
Test1:
Measure the time it takes to run a clean update cycle (Read: no
downloads required, minimal network interaction).
Test2:
Measure the time it takes to search one package. (Again from cache)
Look at the numbers below:
Test1:
Network enabled "apt-get update; apt-get -y dist-upgrade" is twice as
fast as cache based "yum -C update".
Test2:
Cache bases "apt-cache search" is >20 times faster then cache based
"yum -c search".
Again, be aware that the host machine is considerably (?) faster then
the guest machine.
As I said before, I'm not trying to start a flame war - I trying to
raise a point. God knows I won't switch to Debian just because I find
yum to be slower and resources intensive.
- Gilboa
[1] Actual test result.
--------------------------------------------------------------------------------------
FC6/x86_64 Host:
--------------------------------------------------------------------------------------
[root@gilboa-work-dev gilboa]# time yum -C -y update
Loading "installonlyn" plugin
Loading "fastestmirror" plugin
Loading "fedorakmod" plugin
Loading "kernel-module" plugin
Loading "skip-broken" plugin
Setting up Update Process
Setting up repositories
Loading mirror speeds from cached hostfile
Reading repository metadata in from local files
No Packages marked for Update/Obsoletion
real 0m6.072s
user 0m1.408s
sys 0m0.232s
[root@gilboa-work-dev gilboa]# yum -C search kdeartwork
Loading "installonlyn" plugin
Loading "fastestmirror" plugin
Loading "fedorakmod" plugin
Loading "kernel-module" plugin
Loading "skip-broken" plugin
Setting up repositories
Loading mirror speeds from cached hostfile
Reading repository metadata in from local files
[SNIP]
real 0m12.829s
user 0m7.364s
sys 0m1.104s
--------------------------------------------------------------------------------------
Debian guest:
--------------------------------------------------------------------------------------
root@gilboa-vmw-probe ~# time (apt-get update && apt-get -y
dist-upgrade)
Get:1 http://mirror.hamakor.org.il etch Release.gpg [378B]
Hit http://mirror.hamakor.org.il etch Release
Hit http://mirror.hamakor.org.il etch/main Packages/DiffIndex
Hit http://mirror.hamakor.org.il etch/main Sources/DiffIndex
Get:2 http://security.debian.org etch/updates Release.gpg [189B]
Hit http://security.debian.org etch/updates Release
Ign http://security.debian.org etch/updates/main Packages/DiffIndex
Ign http://security.debian.org etch/updates/main Sources/DiffIndex
Hit http://security.debian.org etch/updates/main Packages
Hit http://security.debian.org etch/updates/main Sources
Fetched 2B in 2s (1B/s)
Reading package lists... Done
Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
real 0m3.078s
user 0m0.556s
sys 0m0.512s
root@gilboa-vmw-probe ~# time apt-cache search kdeartwork
kdeartwork - themes, styles and more from the official KDE release
kdeartwork-dbg - debugging symbols for kdeartwork
kdeartwork-emoticons - emoticon collections for KDE chat clients
kdeartwork-misc - various multimedia goodies released with KDE
kdeartwork-style - widget styles released with KDE
kdeartwork-theme-icon - icon themes released with KDE
kdeartwork-theme-window - window decoration themes released with KDE
kdewallpapers - wallpapers released with KDE
kscreensaver - additional screen savers released with KDE
kscreensaver-xsavers - KDE hooks for standard xscreensavers
kworldclock - earth watcher for KDE
real 0m0.314s
user 0m0.292s
sys 0m0.020s
12:27 p.m.
Now you're comparing apples and oranges. I was talking about apt from
Extras, using repomd repositories. You're comparing yum with Debian's
apt with their repos (different number of files and packages; should be
greater, but I don't know if "main" contains all their packages, or is
it something like our "Core").
apt-rpm also has its own repo format which is much faster to download
and parse than repomd. You should check it out :)
Lam
12:42 a.m.
On Thu, 2006-11-23 at 19:27 +0100, Leszek Matok wrote:
Now you're comparing apples and oranges. I was talking about apt
from
Extras, using repomd repositories. You're comparing yum with Debian's
apt with their repos (different number of files and packages; should be
greater, but I don't know if "main" contains all their packages, or is
it something like our "Core").
apt-rpm also has its own repo format which is much faster to download
and parse than repomd. You should check it out :)
Lam
I would have conducted an apt-rpm vs yum test, but I'm on x86_64, and
last time I checked, apt has lousy bi-arch support. (Did it improve)
FYI I'm using Debian unstable which has comparable number of packages.
- Gilboa
2:06 a.m.
On Fri, 2006-11-24 at 08:42 +0200, Gilboa Davara wrote:
On Thu, 2006-11-23 at 19:27 +0100, Leszek Matok wrote:
> Now you're comparing apples and oranges. I was talking about apt from
> Extras, using repomd repositories. You're comparing yum with Debian's
> apt with their repos (different number of files and packages; should be
> greater, but I don't know if "main" contains all their packages, or
is
> it something like our "Core").
>
> apt-rpm also has its own repo format which is much faster to download
> and parse than repomd. You should check it out :)
That's true. Accessing
metadata repos (aka yum repos) with apt, causes
apt to regress quite significantly "memory-footprint" wise in comparison
to accessing apt-native repos.
If you want to try it, set up yum and apt-repos containing rpms and try
to access them with FE's apt (Or find an external repo which supports
both apt and yum-repos.) This apt is supposed to support both styles of
repos.
From what I have tested (on an i586/166MHz with 64MB RAM and FC6
installed) both, yum and apt using yum-repos, both end up with using
comparable amounts of memory, with slight advantages for yum.
I would have conducted an apt-rpm vs yum test, but I'm on x86_64,
and
last time I checked, apt has lousy bi-arch support. (Did it improve)
The
apt-version in FE should be able to handle bi-arched Fedora.
FYI I'm using Debian unstable which has comparable number of
packages.
Which doesn't mean much, because handling rpms and debs in apt are
completely different code bases.
Ralf
2:32 a.m.
Gilboa Davara wrote:
On Thu, 2006-11-23 at 19:27 +0100, Leszek Matok wrote:
> Now you're comparing apples and oranges. I was talking about apt from
> Extras, using repomd repositories. You're comparing yum with Debian's
> apt with their repos (different number of files and packages; should be
> greater, but I don't know if "main" contains all their packages, or is
> it something like our "Core").
>
> apt-rpm also has its own repo format which is much faster to download
> and parse than repomd. You should check it out :)
>
> Lam
I would have conducted an apt-rpm vs yum test, but I'm on x86_64, and
last time I checked, apt has lousy bi-arch support. (Did it improve)
FYI I'm using Debian unstable which has comparable number of packages.
- Gilboa
To get comparable results for apt-rpm and yum try to create
your own Rawhide-mirror ! So you can update using apt and/or yum.
My local mirror for my home network is a rpm-apt-server for at least
1 year, because yum/kyum... are definitely not usable on older machines
(<1Ghz, <256MB) whereas apt-get/synaptic are still usable.
The repository creation on the server using the yum-repo-tools after
rsyncing with one of the Rawhide-Servers consumed also too much time.
best regards
--
------------------------------------------------------------
Jochen Schlick
3:12 a.m.
On Fri, 2006-11-24 at 09:32 +0100, Jochen Schlick wrote:
My local mirror for my home network is a rpm-apt-server for at least
1 year, because yum/kyum... are definitely not usable on older machines
(<1Ghz, <256MB) whereas apt-get/synaptic are still usable.
Hmm, what am I running on my old i586/166MHz/64MB RAM notebook?
# time yum update -y
...
[d/l'ing and installing 2 average sized packages]
...
real 6m49.293s
user 1m56.081s
sys 0m33.872s
slow .. yes, but still usable ;)
Running anaconda (Upgrading or installing fedora on this machine is fun)
or kyum (I've never used it) probably is a different matter.
Ralf
4:05 a.m.
On Fri, 24 Nov 2006, Gilboa Davara wrote:
On Thu, 2006-11-23 at 19:27 +0100, Leszek Matok wrote:
> Now you're comparing apples and oranges. I was talking about apt from
> Extras, using repomd repositories. You're comparing yum with Debian's
> apt with their repos (different number of files and packages; should be
> greater, but I don't know if "main" contains all their packages, or is
> it something like our "Core").
>
> apt-rpm also has its own repo format which is much faster to download
> and parse than repomd. You should check it out :)
>
> Lam
I would have conducted an apt-rpm vs yum test, but I'm on x86_64, and
last time I checked, apt has lousy bi-arch support. (Did it improve)
Apt works on x86_64 nowadays but can't handle some cross-arch cases
like upgrading from 32bit to 64bit version (eg OOo changed from 32bit to
64bit between fc5 to fc6). Yum's bi-arch support is lightyears ahead
anyway :)
FYI I'm using Debian unstable which has comparable number of
packages.
Debian apt is not comparable at all due to differences in package and
repository metadata differences; Debian uses flat text files whereas we
have rather heavyweight XML to wrestle with.
- Panu -
4:37 a.m.
On Fri, 2006-11-24 at 12:05 +0200, Panu Matilainen wrote:
On Fri, 24 Nov 2006, Gilboa Davara wrote:
> On Thu, 2006-11-23 at 19:27 +0100, Leszek Matok wrote:
>> Now you're comparing apples and oranges. I was talking about apt from
>> Extras, using repomd repositories. You're comparing yum with Debian's
>> apt with their repos (different number of files and packages; should be
>> greater, but I don't know if "main" contains all their packages,
or is
>> it something like our "Core").
>>
>> apt-rpm also has its own repo format which is much faster to download
>> and parse than repomd. You should check it out :)
>>
>> Lam
>
> I would have conducted an apt-rpm vs yum test, but I'm on x86_64, and
> last time I checked, apt has lousy bi-arch support. (Did it improve)
Apt works on x86_64 nowadays but can't handle some cross-arch cases
like upgrading from 32bit to 64bit version (eg OOo changed from 32bit to
64bit between fc5 to fc6). Yum's bi-arch support is lightyears ahead
anyway :)
> FYI I'm using Debian unstable which has comparable number of packages.
Debian apt is not comparable at all due to differences in package and
repository metadata differences; Debian uses flat text files whereas we
have rather heavyweight XML to wrestle with.
- Panu -
Solution wise - yes, yum and apt are different - but target-wise, they
both designed to serve the same purpose.
Question is - can yum be optimized (E.g. by replacing the XML parser to
a faster/leaner one) - bringing it to a point where the performance
difference between Debian's apt and Fedora's yum is less staggering?
(Especially in query tasks)
- Gilboa
6:52 a.m.
On Fri, 24 Nov 2006, Gilboa Davara wrote:
Solution wise - yes, yum and apt are different - but target-wise, they
both designed to serve the same purpose.
Question is - can yum be optimized (E.g. by replacing the XML parser to
a faster/leaner one) - bringing it to a point where the performance
difference between Debian's apt and Fedora's yum is less staggering?
(Especially in query tasks)
The XML is already parsed by a module written in C and is fast enough not
to be a bottleneck I think. The XML files are only read during importing
the data into sqlite database, which is then used for all operations
(depsolving, querying etc).
FWIW, I don't think 'yum search foo' and such are slow at all these days,
only the depsolve stage remains a bit of a sore point speedwise. Where
exactly the time is spent and how to improve things .. profiling needed :)
BTW, Debian packages have far less dependency data in them than an average
rpm package does because automatic dependencies and provides are not used
there. Just an example:
$ dpkg -f libc6_2.3.6.ds1-8_amd64.deb |grep Provides
Provides: glibc-2.3.6.ds1-1, glibc-2.3.6-2
Contras that with FC6 glibc:
$ rpm -qp --provides glibc-2.5-3.x86_64.rpm |wc -l
300
Looking through 300 provides for matches is more expensive than going
through 2 provides :) glibc is a bit of an extreme case of course, not
every package is *that* bloated with soname-provides but it adds up pretty
fast and doesn't help speeding things. OTOH Debian has a larger
repository... my point is that there are lots of differences between deb
and rpm systems, comparing them in any sane way is not trivial.
- Panu -
3:43 a.m.
On Thu, 23 Nov 2006, Leszek Matok wrote:
Dnia 23-11-2006, czw o godzinie 17:30 +0200, Gilboa Davara
napisaÿÿ(a):
> yum is slower by an order of magnitude than apt-get
> Am I the only one having this problem?
Well, on this machine, yum -C update takes 14-18 seconds and apt-get
dist-upgrade takes 9-11 seconds to resolve everything and ask me if I
want to download.
You'll see a LOT bigger gap in times as the amount of depsolving
increases, for example fc5 -> fc6 upgrade set. Apt will resolve that in a
few additional seconds (obviously depending on installed package set,
computer speed etc) compared to "empty upgrade" whereas yum is going to
take minutes, even with all metadata and headers locally cached.
Just try timing 'apt-cache unmet' vs 'repoclosure' (from yum-utils) :)
On small sets yum can actually be faster than apt, largely due to the fact
that apt calculates a full dependency tree of the available package
universe, whereas yum deals with them in "solve them when needed" basis.
At this point, yum takes 7 MiB of memory (ps's SZ),
while apt-get takes 30 MiB (more precisely, apt-shell takes 6,8 to
resolve dependencies, but 30 when you tell it to commit). I still prefer
apt for lots of other reasons, but nowadays it's not so much faster and
doesn't look lighter at all.
Yup, apt isn't *that* light on memory use, due to various reasons:
- when using repomd, it holds the whole primary.xml file in memory for
a repository at a time, that can consume boatloads of memory (this is
something I have plans to fix eventually)
- as mentioned earlier, it keeps a precalculated dependency tree of all
packages in memory at all times
- Panu -
8:38 a.m.
Jesse Keating wrote:
On Thursday 23 November 2006 06:55, Gilboa Davara wrote:
> especially when it comes to CPU/memory intensive tasks such as
> dep-solving.
Except that the depsolving is done by rpm libraries which are C, so invalid
argument.
I was told by JBJ that the cause of the memory bloat is rpmlib
maintaining in memory two lists of filepaths from every package
involved. One is apparently trying to detect symlinks by holding device
and inode information along with the filepath, and the other is a btree
type representation of each path level that is rapidly searchable. He
had ideas for fixing both if anyone wants to reach out. I took a look
at the sources and crept away with my tail between my legs.
-Andy
2:32 a.m.
On Thu, 23 Nov 2006, Jesse Keating wrote:
On Thursday 23 November 2006 06:55, Gilboa Davara wrote:
> especially when it comes to CPU/memory intensive tasks such as
> dep-solving.
Except that the depsolving is done by rpm libraries which are C, so invalid
argument.
Except that's not quite true either. Part of the depsolving is done with
rpmlib calls: yum loads rpm headers into a transaction and gets lists of
missing dependencies, looking for packages providing those dependencies
is done by yum itself.
In FC6 the hideous yum slowdown comes largely from reopening the rpmdb
literally hundreds of times. Check out
https://lists.dulug.duke.edu/pipermail/yum-devel/2006-November/002870.html
for some metrics. Yum 3.0.1 isn't *that* bad, but 3.0 is dog slow whereas
2.9.6 was lightning fast.
- Panu -
6:01 a.m.
Pekka Savola wrote:
3) are there more light-weight desktops/WMs than xfce?
WindowMaker
It's in extras with even a few dockapps.
--
==================================================
David Kovalsky dkovalsk(a)redhat.com
Quality Engineer
IRC: #brno, #errata, #qa, #urt
==================================================
8:37 a.m.
3) are there more light-weight desktops/WMs than xfce? Recently, it
seems it also has become bloated, e.g.,:
There is also fluxbox and openbox. Currently they lack some features
available in xfce (automounting of removable devices, pager, working battery
dockapp...) but that's not inherent to these apps, and has more to do with
the fact that they have less users and packagers in fedora. Lately there
was more interest, but it seems to have fallen down.
--
Pat
6365
days inactive
6367
days old
31 comments
16 participants
participants (16)
-
Andy Green -
David Kovalsky -
Dax Kelson -
Gilboa Davara -
Jesse Keating -
Jochen Schlick -
John Reiser -
Kevin Kofler -
Leszek Matok -
Matt Domsch -
Panu Matilainen -
Patrice Dumas -
Pekka Savola -
Pádraig Brady -
Ralf Corsepius -
Tony Nelson