From: Alex Schuster <wonko@wonkology.org>
To: gentoo-user@lists.gentoo.org
Subject: [gentoo-user] Swap performance
Date: Wed, 25 May 2011 16:20:58 +0200 [thread overview]
Message-ID: <201105251621.00659.wonko@wonkology.org> (raw)
Hi there!
I still wonder why my KDE4 system starts swapping so early. Until a week
ago, I had 6G of RAM, but after a day of being logged in, I usually had some
swap usage. Sometimes this goes up to 1.5G, this is when the system becomes
way too slow and I log out.
Normally I don't mind having swap, I always had. But to me it looks like
this is worse than it should be. From the point when swapping starts, it's
nearly permanent, like, when switching applications and desktops. As if
important stuff were swapped out that will be needed again soon. While
unimportant stuff stays in memory.
This was even worse when using the ati-drivers/fglrx, but at the moment
I'm using xf86-video-ati with xorg-server-1.10.1.901 and KMS.
echo 1 > /proc/sys/vm/drop_caches helps a little, but not much. And not
for long.
Sometimes I quit memory-hungry applications like Kontact, Amarok and TV
Browser and restart them immediately afterwards. Memory usage has
dropped, and desktop switching is fast again, once I went to every desktop
so that stuff will be swapped in. BTW, vm.swappiness is set to 20.
Or I do a 'swapoff -a && swapon -a', this empties the swap and also
frees memory. But this takes _quite_ _a_ _while_. Once I measured 37 minutes
to clear 1G of swap.
But I do not remember how much memory was being used then, so I tried
again, after closing memory-intensive applications:
weird ~ # free -m
total used free shared buffers cached
Mem: 5721 4184 1536 0 34 111
-/+ buffers/cache: 4039 1682
Swap: 4093 885 3208
weird ~ # time swapoff -a
real 27m8.757s
user 2m12.284s
sys 21m37.089s
weird ~ # free -m
total used free shared buffers cached
Mem: 5721 4785 936 0 53 409
-/+ buffers/cache: 4322 1398
Swap: 0 0 0
So, 27 minutes to put 885MB of swap back into RAM, with the double amount of
that being free RAM. I monitored with iotop, and the transfer rate started
around 60-100 K/s, later it went higher. But the average transfer rate is
550K/s. Shouldn't swap be, like, a little faster?
My swap is on an LUKS-encrypted LVM volume, but I tried with a fresh new
LVM volume, and it was a little better only. The SATA drive gives 80-100
MB/s according to hdparm -t. dd'ing /dev/zero directly to the swap volume
gives around 100 MB/s.
I'm running ck-sources 2.6.38, but I experience this for a long time
now, and changed from tuxonice-sources (another thing that just doesn't
work well for me) to ck-sources, to try if this would improve things. I
even cloned a .config from some live cd, in case I had some stupid option
activated that slowed things down.
Lowering swappiness helped, as did more memory. With 3.7G of RAM, KDE4
was barely usable. But two years ago, when this PC was new, I ran KDE 4.2 on
x86, compiled all except OpenOffice in tmpfs, often had a virtual
machine running in VMplayer, and it was fine.
I sure run lots of applications (Kontact, Amarok, TV Browser which uses an
incredible amount of RAM), some Dolphins, some Konsoles, a few Konquerors,
about 15-26 Chromium tabs, KMyMoney, some editors, sometimes Qt Creator, and
some Okulars. When I file some photos from my camera with Digikam, I
normally do not close it afterwards, hoping that it gets swapped out if
needed, and unless I start using it again this should not cost too much of
my RAM. This has always been my style of working, I don't like to close an
applications just after working with it. And it was fine in the past, with
much less memory, and with a virtual machine running all of the time.
Now I got another 2G of RAM, and things are better. But still, I have 800M
of swap right now, without using special applications or VMs. At this
moment, it's not problem, there is no paging going on. A little while ago,
it was quite noticeable. I was running rdiff-backup stuff at that moment,
but so I am doing now. Weird.
Oh, even weirder: The phone just rang, and five minutes later, swap has gone
to 860M. I was running rdiff-backup --list-increment-sizes, maybe this uses
much memory, and caches the stuff. Now the command has finished, and paging
has stopped. The rdiff-backup process itself does not use much memory.
BTW, does anyone else's kwin use 750M? That's pretty high, I think it used
to be more like 300M.
Wonko
next reply other threads:[~2011-05-25 14:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-25 14:20 Alex Schuster [this message]
2011-05-25 15:31 ` [gentoo-user] Swap performance Paul Hartman
2011-05-25 16:58 ` Volker Armin Hemmann
2011-05-25 19:34 ` Paul Hartman
2011-05-25 20:03 ` Alan McKinnon
2011-05-25 20:38 ` Alex Schuster
2011-05-25 22:40 ` Alex Schuster
2011-05-26 16:30 ` Volker Armin Hemmann
2011-05-25 16:49 ` Alan McKinnon
2011-05-26 20:49 ` Mick
2011-05-25 16:53 ` Volker Armin Hemmann
2011-05-25 20:07 ` Alan McKinnon
2011-05-26 13:32 ` Sebastian Beßler
2011-05-25 22:18 ` Alex Schuster
-- strict thread matches above, loose matches on Subject: below --
2011-05-26 17:26 Alex Schuster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201105251621.00659.wonko@wonkology.org \
--to=wonko@wonkology.org \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox