Author |
Message |
smoo
|
|
|
Post subject: Crazy new disk-swapping? [main mystery solved]
Posted: 16.05.2011, 16:21
|
|

Joined: 2010-10-20
Posts: 10
Status: Offline
|
|
Has there been a recent change to any of the swapping mechanisms? I noticed on my aptosid laptop at home this weekend that despite less than 1/3 of the ~ 3 GiB RAM being used, a lot of data (several hundred MiB, at least) was being moved to the swap partition, for no reason I could discern.
Similarly, on my work desktop after the latest DU, there is tremendous swapping going on.
A
Code:
ps -ef | grep swap
finds only
Code:
root 318 2 0 May13 ? 00:07:00 [kswapd0]
root 1747 2 0 May13 ? 00:00:00 [ttm_swap]
and less than a third of my RAM is being used.
Any clues? |
Last edited by smoo on 18.05.2011, 13:35; edited 1 time in total
|
|
|
|
 |
smoo
|
|
|
Post subject: Tentatively solved?
Posted: 16.05.2011, 17:03
|
|

Joined: 2010-10-20
Posts: 10
Status: Offline
|
|
Hmm. I note that /proc/sys/vm/swappiness, at least on my desktop, is back to 60, whereas I had set it to a much lower number before.
I think that the setting had persisted through several DUs, including kernel updates, but has now reverted to its previous default of 60. I'm going to change it back to 10 (or even 5); if it solves this swappiness problem, I'll post back here. |
|
|
|
|
 |
dibl
|
|
Post subject:
Posted: 16.05.2011, 17:11
|
|

Joined: 2010-09-12
Posts: 302
Location: Dayton, Ohio, USA
Status: Offline
|
|
I have a hard time believing that anything from d-u has changed your swappiness value, if you set it in /etc/sysctl.conf. On a system I built and configured last November, it remains exactly as I originally set it:
Code:
don@aptosidbox:~$ cat /proc/sys/vm/swappiness
1
This system has received d-u weekly and is current:
Code:
don@aptosidbox:~$ infobash -v3
Host/Kernel/OS "aptosidbox" running Linux 2.6.38-6.slh.2-aptosid-amd64 x86_64 [ aptosid 2010-03 Ἀπάτη - kde-lite - (201012262151) ]
CPU Info 8x Intel Core i7 950 @ 8192 KB cache flags( sse3 ht nx lm vmx ) clocked at [ 1600.000 MHz ]
Videocard nVidia GF100 [GeForce GTX 480] X.Org 1.10.1 [ 1920x1200@50.0hz ]
Network cards Marvell 88E8056 PCI-E Gigabit
Processes 253 | Uptime 15:52 | Memory 2579.9/5978.9MB | HDD KINGSTON SS100S2,OCZ-REVODRIVE,OCZ-REVODRIVE,WDC WD1002FAEX-0,WDC WD1002FAEX-0 Size 2136GB (2%used) | GLX Renderer GeForce GTX 480/PCI/SSE2 | GLX Version 4.1.0 NVIDIA 270.41.06 | Client Shell | Infobash v3.36
|
|
|
|
|
 |
slh
|
|
Post subject: RE: Tentatively solved?
Posted: 16.05.2011, 17:14
|
|

Joined: 2010-08-25
Posts: 954
Status: Offline
|
|
procfs is a virtual filesystem, an interface to your running kernel, nothing you do there survives a reboot. |
|
|
|
|
 |
smoo
|
|
Post subject:
Posted: 16.05.2011, 17:23
|
|

Joined: 2010-10-20
Posts: 10
Status: Offline
|
|
Yeah, I of course change the swappiness value in a "permanent" way through /etc/sysctl.conf, and thought it would persist across dist-upgrades. That's why I was (and am) confused as to why the swappiness is back at the old value of 60!
I'll keep an eye on this. Thanks for the suggestions. |
|
|
|
|
 |
lab
|
|
Post subject:
Posted: 17.05.2011, 05:52
|
|

Joined: 2010-09-18
Posts: 17
Status: Offline
|
|
smoo wrote:
Yeah, I of course change the swappiness value in a "permanent" way through /etc/sysctl.conf, and thought it would persist across dist-upgrades. That's why I was (and am) confused as to why the swappiness is back at the old value of 60!
I'll keep an eye on this. Thanks for the suggestions.
Did something perhaps upgrade /etc/sysctl.conf and you answered yes a bit too quickly? Is there a /etc/sysctl.conf.old or some such lying around? I did latest D-U a couple of days ago, and my value of 10 is still persisted just fine. |
|
|
|
|
 |
smoo
|
|
Post subject:
Posted: 18.05.2011, 13:35
|
|

Joined: 2010-10-20
Posts: 10
Status: Offline
|
|
Quote:
Did something perhaps upgrade /etc/sysctl.conf and you answered yes a bit too quickly? Is there a /etc/sysctl.conf.old or some such lying around?
The former is possible, I guess. I can never rule out my own mistakes!
The latter isn't, or at least there is no backup version of /etc/sysctl anywhere that I can find.
At this point, despite being told that very few things other than operator error are ever going to change the swappiness value, it's my only option, as I certainly didn't leave it dat 60, and these two computers have been dist-upgraded often (~ once a day at work, when there aren't showstopper problems and perhaps once a week at home), and the problem hit them both within a few days or a week.
Anyway, I've changed those values to much lower values, and the problem is apparently gone for me now. |
|
|
|
|
 |
|