29

For years I have been having the same problem with my small Ubuntu configurations: the used swap space increases with time. I get the impression that this is mainly because the allocated memory never returns to RAM even though there is enough space for it, except in the case of a user action like disabling the swap.

I made a short cron command to automate this, and I have good results:

#! /bin/sh

echo "* */1 * * * root swapoff -a && swapon -a" >> /etc/crontab

But because it's more of a trick than a real solution to this problem, I'm wondering about the potential reasons it might be a bad idea, or how could I improve this script to make it a little more clever?

  • 29
    Pardon my ignorance, but what exactly do you mean by saying the space SWAP grows with time and the emptying to the RAM of the memory allocated? Normally you allocate some space as swap to the system and never hear from it again. Who cares how much of the swap is actually taken? What's the problem? – dessert Nov 06 '17 at 14:54
  • 1
    Here is an example of a better version: https://askubuntu.com/a/90399/15811 – Rinzwind Nov 06 '17 at 14:58
  • 5
    Why do you even want to do this? Why do you think some swap usage is a bad thing? How much swap usage are we talking about? – marcelm Nov 06 '17 at 16:31
  • I rewrote a bit the first paragraph, my English was not clear at all ... – Yvan Sraka Nov 06 '17 at 16:38
  • You are asking a yes-or-no question, so don't be surprised if the answers reflect that. – user535733 Nov 06 '17 at 18:01
  • 25
    I'm kind of puzzled. You keep talking about a "problem" but don't actually describe any negative effects of any kind. Why do you consider this a problem? – David Schwartz Nov 06 '17 at 18:42
  • 17
    If something gets into swap and stays there, it's because nothing is using it. And if nothing is using it, it's better to let RAM be used for something that is accessed, like cache, than to swap the data back in. – hobbs Nov 06 '17 at 19:20
  • 12
    How is this better than just leaving swap off? – user253751 Nov 07 '17 at 00:55

6 Answers6

51

Using it like that: yes, bad. You really need to check if there is enough memory available before you turn swap off. See https://askubuntu.com/a/90399/15811 for a better version.

Also: are you sure about this? Swap being allocated does not mean swap being used. The command vmstat, columns si (swap in) and so (swap out). If those remain 0 you got another problem. In my experience swap is hardly used, and you might not be using it thinking it does not empty it but there is nothing to empty.

Rinzwind
  • 299,756
  • 3
    Wait what? If there's not enough memory for swapoff to succeed, swapoff get killed by the OOM killer first. Yes, they actually hardcoded that (it checks by system call). – Joshua Nov 07 '17 at 19:43
  • @Joshua sure but he wants it working automated. Not error out. – Rinzwind Nov 08 '17 at 10:52
  • 5
    To elaborate without going into writing my own answer, swap usage growing over time is not a bad thing at all. What it means is that the kernel is slowly finding out what junk that's consuming memory is never getting used and moving it out to swap so that the memory can get used for things that actually help you (like being able to keep more fs data cached so it doesn't have to keep discarding it and re-reading it from disk). – R.. GitHub STOP HELPING ICE Nov 08 '17 at 18:29
  • @Rinzwind cron works fine with jobs that error, and the linked script doesn't use vmstat, either. – jpaugh Nov 08 '17 at 21:02
42

I'd say it's a bad idea. If you think you have free memory and an active process isn't being moved from swap to RAM, then either you don't have as much free memory as you think you do, or the process isn't as active as you think it is.

If an active process continues to be swapped, you should be fixing whatever it is that's causing pressure on the memory. If it isn't an active process, what's the big deal?

muru
  • 197,895
  • 55
  • 485
  • 740
  • 1
    +1: What's the big deal? Never change a running system, I don't think one should mess with the system's core functions like that, especially not without any need. – dessert Nov 06 '17 at 14:55
  • 3
    I sometimes have issues where I kill a process with a memory leak (which forced everything else out into swap), leaving me with ~10% RAM used... but all the running programs are in swap until I access them again. So every time you touch something, there's a two second delay. I can see where OP is coming from, and it would be nice for it to be done automatically, but this is not the right way. – SomeoneSomewhereSupportsMonica Nov 07 '17 at 07:32
  • 1
    @SomeoneSomewhere But that's not how it works, anyway. If the process is leaking memory then, by definition, it's not actively using that memory (it's not reading and writing it); it just has it allocated, by accident. If there are other active processes around, the leaked memory will get swapped out and it'll be your swap that's full of garbage, not your physical RAM. – David Richerby Nov 09 '17 at 11:44
  • @DavidRicherby If you've got a program open in the background, then that program is still less active than the memory leak - and when you go to switch back to it, it has to come out of swap. – SomeoneSomewhereSupportsMonica Nov 10 '17 at 20:48
  • @SomeoneSomewhere You seem to have misunderstood how the memory system works. You don't have to have the whole of a process in physical RAM: swap is managed at the granularity of single pages. Any page that hasn't been used for a while is liable to be swapped out, and a page that consists entirely of leaked memory will never be used again, so will never get swapped back in after it's swapped out. – David Richerby Nov 10 '17 at 23:24
  • @DavidRicherby I don't know if it's strictly 'leaked' - it may have still been cycling through the allocated memory for some reason. But I had an application that would, under certain circumstances, use up all available RAM. Once that happened, alt-tabbing to practically any other program resulted in hard faults, and this persisted even after closing the offending program until emptying swap. – SomeoneSomewhereSupportsMonica Nov 11 '17 at 05:53
  • The point is, that if there is 1 of 16GB memory used, and 5GB in the pagefile (including userspace programs), I would prefer to see the OS pro-actively load the pagefile back into RAM. – SomeoneSomewhereSupportsMonica Nov 11 '17 at 05:54
35

It's a bad idea.

The kernel starts copying (not moving) data to swap long before physical memory is close to being full, because if some process ever requires a lot of memory, any page that already has a valid copy in swap can be reused immediately without requiring another write to disk.

Generally that happens mostly for pages that haven't been accessed in a long time, which is a good indicator that it is unlikely that they will be accessed soon.

If you explicitly discard the copies, that brings no benefit, because the data still exists in RAM, but may cost you speed when some process wants to allocate a lot of memory and swapping becomes necessary.

The kernel will also always use swap space as soon as physical memory is above 50% full, so these numbers will be non-zero even if you have enough memory installed.

  • 4
    always: I think you're assuming that /proc/sys/vm/swappiness is left at it's default value of 70, which is good for servers and fairly aggressively pages out dirty pages from processes that haven't touched them for a while to make room for more pagecache. This is often bad for desktops because alt-tab can get slow. – Peter Cordes Nov 06 '17 at 22:10
  • @PeterCordes, if the pages actually got evicted then the caches have seen more accesses than the application pages in question, so there has been a net benefit to using these as disk caches. I can see how Alt-Tab performance is more visible to the user than e.g. compile time for a large project, but find it difficult to formulate a policy that guarantees instant response without sacrificing too much performance. – Simon Richter Nov 06 '17 at 23:54
  • 1
    Put it another way: the kernel is tuned for throughput (swappiness=70), but latency is more important to user-experience on a desktop. It's a tradeoff. If you routinely compile stuff that's slightly too large to stay in the pagecache, then sure, leave swappiness a little higher, like 20 or 30 instead of 5 or 10. See also http://www.akitaonrails.com/2017/01/17/optimizing-linux-for-slow-computers. Seeing vm.vfs_cache_pressure lower than 100 also favours caching inode / directory metadata over data pages, which is nice for UI responsiveness too. – Peter Cordes Nov 07 '17 at 00:11
  • 1
    Other tunables: write-back thresholds https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/. These control how quickly Linux starts writing to disk after something writes to files, and how many dirty pages are allowed. (i.e. how much memory can be spend on write caching) – Peter Cordes Nov 07 '17 at 00:11
22

This is a bad idea. If this were useful, the Linux kernel would implement it this way. I do not believe there is a reason to change more than a few tuning parameters, as such a simple shell script most likely is not more clever than the algorithms of the kernel developers.

You basically have two cases:

  • The processes in swap space are not used anyway. Why do you want to pull them back into RAM?
  • There is little RAM, so they get swapped out and you pull them back into RAM. Then your system will put them into swap again as soon as possible.

So there are two main points:

  1. First, your system will be slow when there is too little RAM to run all your programs at once. Swap will help you to run more programs, but not to switch quickly to a rarely used one, which may be swapped out. No swap may get the rarely used one killed or send the currently used one an out-of-memory exception.
  2. Second, swap is a good thing and so is having stuff in swap, as you have free RAM at cost of programs you're currently not using anyway.

Despite not getting out-of-memory problems with too many programs, some programs may allocate memory based on the currently free RAM (maybe your browser will use more memcache and you can browse faster) and the kernel can use free RAM for disk caching and similiar optimizations. When you force your swap to be empty, the kernel will drop its read cache and e.g. starting a new Firefox instance will take longer than when Firefox is still in the disk cache.

If you want to tune the behaviour of the kernel, see the swappiness parameter.

Two additional ressources contributes by @peter-cordes:

If you really want to have empty swap, you can turn off swap permanently. I do not see why having it on for an hour and then emptying it has advantages over not having swap.

allo
  • 661
  • 1
    See also http://www.akitaonrails.com/2017/01/17/optimizing-linux-for-slow-computers and https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/ for more tuning suggestions / details. – Peter Cordes Nov 07 '17 at 00:13
5

You can achieve the same results by telling the kernel to free up the caches:

echo 3 > /proc/sys/vm/drop_caches

This way you avoid the brief moment of possible memory starvation and leave the kernel decide what is necessary and what can be discarded.

Alex C
  • 300
  • 1
  • 4
0

Contrary to the common idea SWAP in itself is not bad.
What actually slows your system down is the kernel activity that moves Data from the RAM to the SWAP and back into the RAM, the swappiness.
The System does this automatically as it is configured with the swappiness.
This makes that Memory from inactive processes is dumped to the Harddisk Swap Partition.
I myself worked for years with a Machine that did not have so much RAM Memory and I always had some SWAP Memory used. Still my machine worked fine untill you start to move the the memory back into RAM, perhaps by trying to close an open application. Then the Work Load started to increase.

  • So by cleaning out constantly you SWAP Memory the Work Load on your machine will considerably increase.
  • Running Applications that have their Memory on the SWAP Partition can corrupt in their execution.

Rather I would suggest you study closly which application uses your memory on the command line with the htop application and decide to close some Application. The gnome-system-monitor can give you good insight as well, in its Process-Tab.
If you have big applications that use a lot of RAM. Do not run them all at once.