Linux Performance: Why You Should Almost Always Add Swap Space

If you must use swap (you probably don't need to), then at least set zswap.enabled=1 in the kernel boot options, typically in grub. This will enable lzo compression of swap in memory so there is less writing to disk. Some newer kernels use lz4.

Either way, what most folks are actually missing is the correct kernel settings for the amount of memory they have. Sadly, the kernel does not dynamically adjust these based on your total amount of memory. Below is based loosely on Redhat suggestions. Please note, that if you fall below the min free, the kernel will decide what to do next, based on your oom and panic settings. The settings below will have the kernel free cache and other memory earlier so that you do not hit those stalling conditions and can even prevent some OOM race conditions. Some might suggest tuned, but use tuned with caution or at least read up on everything it does.

    MEM=`grep ^MemTotal /proc/meminfo | awk {'print $2'}`
    if   [ ${MEM} -gt 1129241478 ] ; then
        sysctl -q -w vm.min_free_kbytes=16384000
    elif [ ${MEM} -gt 564620739 ] ; then
        sysctl -q -w vm.min_free_kbytes=8192000
    elif [ ${MEM} -gt 352887962 ] ; then
        sysctl -q -w vm.min_free_kbytes=4096000
    elif [ ${MEM} -gt 176443981 ] ; then
        sysctl -q -w vm.min_free_kbytes=1024000
    elif [ ${MEM} -gt 88221990 ] ; then
        sysctl -q -w vm.min_free_kbytes=524288
    else
        sysctl -q -w vm.min_free_kbytes=262144
    fi

If you have small VM's, then perhaps set the default above to something a little smaller. You can of course free up about 128MB on default installations by removing "crashkernel" from your grub config and rebooting.

Then do this regardless, because overcommit set to 0 does not mean off, so we set the ration to 0 as well. Overcommit is good for developers testing code and finding the correct ways to manage memory in their applications during development.

    sysctl -q -w vm.overcommit_ratio=0

And of course, cache pressure plays into early evacuation of the right cache based on your usage:

    ## default is 100 (optimal for file servers).  4000+ for in memory databases.
    ## 10000 means always prefer page cache.
        sysctl -q -w vm.vfs_cache_pressure=1000

And if you have people oversubscribing a lot: (adjust based on your memory capacity)

    sysctl -q -w vm.admin_reserve_kbytes=131072
    sysctl -q -w vm.user_reserve_kbytes=262144

Please do read up on all of these before testing on your test machines. [1]

[1] https://www.kernel.org/doc/Documentation/sysctl/

Then finally, make sure you have Transparent Huge Pages disabled unless you know for sure you need it. THP can leak a lot of memory and it is nearly impossible to see without extensive kernel debugging.

In grub, set this and reboot:

    transparent_hugepage=madvise

Or to manually disable THP during run-time,

    echo -n "madvise" > /sys/kernel/mm/transparent_hugepage/enabled
    echo -n "never" > /sys/kernel/mm/transparent_hugepage/defrag

Then restart your applications. THP defrag can also cause stalling and lag spikes, especially in large memory java deployments (it will look like FGC's) and in MongoDB, Cassandra, others.

If you did this manually, stop your apps, flush cache, compact memory, then start your apps.

    sync;sync;sync
    echo 3 > /proc/sys/vm/drop_caches
    echo 1 > /proc/sys/vm/compact_memory

Some will say 3 sync's is not required. This is mostly true, but some old raid controllers treat this differently.

This is dangerous advice. At least on Ubuntu 16.04 with stock kernel running due to memory pressure into swap kills the systems. Basically everything times out and you can only hard-reboot. Without swap you have an OOM at least something you can recover from. If you need swap just add a little like 1-4gb - because if you have spinning disks 64gb swap won't help you at all because every request to swap is magnitudes more slower. Might be different with NVMe but it's still noticable.

indeed on ubuntu 16.04 64bit, when my chrome has 20+ tabs, some new tab could trigger a memory thrashing, that uses up all the memory and eats up a few GB disk, cpu load jumps up to 10x, the computer basically becomes unusable.

i would rather a OOM kill the chrome process in this case, it wastes less time on me, a re-open of chrome will keep all the histories anyways.

also on embedded system where the RAM is fairly limited, and no hard drive attached, and its storage is measured by MB instead of GB, you simply can not have the swap partition.

I want to run the system without swap actually.

Cargo cult system administration.

No, you should not 'almost always add swap space'. What you should do instead is tune your system for its intended use.

If you need swap as an 'early warning system' that you're about to run out of memory you're already doing it wrong and the OOM killer is a piece of code that has default settings that can be tuned, ditto for the virtual memory manager in the kernel.

http://www.oracle.com/technetwork/articles/servers-storage-d...

https://access.redhat.com/documentation/en-us/red_hat_enterp...

Select appropriate equivalent for your kernel where applicable, and don't forget about the per-process limits in ulimit.

This sort of 'almost useless' advice is pretty annoying, it shows that the writer has an interest in the matter but didn't bother to dig in deep enough to make the advice truly useful.

Also, the comment on that article that implies that swap will allow you to update a running process because it is backing the image is wrong, the backing is simply done through the filesystem and swap space has nothing to do with it. The practical upshot of which is that you're not going to be able to reclaim the space held by the binary if you should remove it because the 'file is busy' until the last instance of that process exits. In the meantime, if you really want to run the newer version under the old name or path then you're free to unlink it or 'mv' it to a different location and to start the new binary from the default location. On some Unixes you can even overwrite the binary using an mv command making it look like the old one has disappeared but again, under the hood it will still be held open, you can check this using lsof or whatever is your local equivalent to see that the file is indeed still present. In a pinch (and you really really have messed up if you ever need this trick) you can re-link the running image by hard linking to the inode.

Not just ubuntu. We tell our engineers to remove their swap partitions because sometimes the test suite will consume all remaining memory and push into swap. If that happens, pretty much the only thing you can do is a hard poweroff. If you're fast, you can Ctrl+C and only lose a minute or two, but often you're just completely stuck.

Much better to OOM and have the test suite killed early.