Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It only takes a minute to sign up.
Sign up to join this community
Occasionally I leave my openSUSE 13.1 64-bit system KDE-based up for a few days or even a week without a reboot. However, I notice after a night of idle standby the system gets very slow when I want to use it the next morning. So far I have been trying to free the page cache, dentries, inodes by running
echo 3 > /proc/sys/vm/drop_caches
This helps only partially. Can you recommend other ways to analyse and cure the cause of system slowness?
I have noticed this too, more so with systems I used over 6 years ago, and had forgotten about it until your question.
Upon returning to a system in the morning or worse still after a weekend, a key depression in a terminal or clicking on a tab in Firefox, would trigger an incredible amount of disk activity.
My theory for what was happening, is that the activity was due to processes being swapped in again, and the cause was due to the kernel's aggressive nature of swapping out idle processes to optimise the amount of "free" memory available, which which is probably a smart idea on an active system when a new process might be started, but has this one particular down-side.
One way to confirm this would be to have a terminal with vmstat 1 1 running, unfortunately having something running makes the system less idle, so this has some affect on the experiment, so you need to be carefull to start with a different terminal or another program when you start in the morning and ensure that that window is visible so you can see the stats.
You should see the SI Swap in column shoot up when you start.
How do I get around it? I let the computer shut down to suspend mode (on my laptop), or shut down completely on a desktop. I never use hibernate since I find it takes longer to wake up from hibernate, than simply booting from scratch and boot time has been so much improved compared to how it was, and disk drives are faster, memory is cheaper. (at the time my system had 1GB of memory whilst today it has 4GB or more) and I suspect that there is a memory usage factor as when the swapouts are triggered as well. So more memory helps.
There is a kernel tuning parameter that affects the swapiness
To see what your current setting is :
cat /proc/sys/vm/swappiness
The value can be between 0 and 100, 100 means most aggressive swap out from physical memory policy, zero least aggressive.
You can change it by simply echoing a value to that pseudo file.
eg
echo 20 > /proc/sys/vm/swappiness
There is a good article and some performance links related to swapiness here.
edit 1 to answer @Gilles
I too have had machines run for years, only to shut down because I've actually moved premises, I am not insinuating there is anything like software rot but only that I too also experienced exactly what I have described, it's not obvious with servers, when you login via ssh, but it is on say my asus eeepc 901, when it does not sleep, pressing shift there is noticeable disk activity, before the system responds. I do not make things up, and because you haven't noticed it doesn't mean to say that this behaviour it's not there. I'm not knocking linux or trying to be disparaging, at all.
edit 2 @mabalenk
You are confirming exactly the circumstances, 60 is the default swapiness, and SI count will be zero when nothing is happening. vmstat 1 prints statistics every second, so apart from the first line printed, each line is the delta for the last second, so when you see it rise, swap-ins are occurring. Having said this, your figures of 60 or so do not seem to be very high, maybe my system was particularly low on memory, I would see much higher figures 120-250 and lasting for between 20-50 seconds, (sometimes a couple of minutes) and then settling down to zero and I'd get a response from the original key depression in the terminal.
Yes, the kernel will tend to show a 90% memory usage, (it tries not to waste any. ;-) ). The 30% swap space used, doesn't mean much since it is the amount of reserved swap space used and depends on how much has been allocated. Your amount of RAM and swap space allocation would be usefull figures to add to your original post (which you can always edit.).
I don't understand why you surmise that there is something wrong with kde ? If I were you, I would change nothing but the swapiness and drop it down to the ridiculous, say 5 before you leave at night, and check again to see if you notice any difference in the stats, when you start again in the morning.
I don't know if you read any of the links I posted but there was an interesting comment from one of the long standing Kernel developers Andrew Morton. He suggests that anything other than using a swapiness less than 100 is not allowing the kernel to do it's job properly. Now this makes sense if one looks at the system as a whole, why not swap out inactive pages and allow more elbow room for the active part to function ? But this can have the detrimental affect, when the next bit of memory you will use has been swapped out, so when you start again in the morning, you have to wait for those pages to be swapped in again, before you get a response. There's no one size fits all.
Remember though, this is a tuning parameter, and if you are running with the usual 4 times swap size to actual RAM, then 30% SWAP used means you are using more than twice as much memory that you actually have, so your ultimate solution would be to get more RAM, since changing the swapiness will slow down swap-outs, but not change the behaviour entirely. you might find that after 16 hours idle time, you are swapped out anyway, due to cron jobs starting at night, changing entirely your active/passive memory page footprint.
vmstat 1 (this is the correct command if you want to see the live update of the stats). The si column is usually 0, but when I start the values fire up to 16, 32 and sometimes 64. Potentially, something is wrong with the KDE. But how do I check that?
I have the similar case. My box has 12GB RAM and over the nigth all desktop applications were swapped out for the cache and such. The main reason I think is that cache (dirty pages) can take up to 60% RAM by default and when this limit is reached, the kernel suddenly want to flash 6GB dirty pages to disk which effectively kills the performance.
I cured with the following parameters in /etc/sysctl.conf
# use only 10% of RAM for the cache (dirty pages).
vm.dirty_ratio=10
# start flashing with 1% dirty pages
vm.dirty_background_ratio=1
/var/log/messagesand/var/log/boot.log. There are no warnings or errors. Interesting is that/var/log/messagescontains the info for today only. There is no history for the past days. Should I check anything else?