Linux Performance – SSD and Swap Configuration

performancessdswap

This article suggests not to create a swap space on an SSD drive in order to reduce its wear. On the other hand, it suggested here that swap space positively affects performance.

Would it be a better option to drop swap? Or maybe some swappiness tweaks could let us have the cake and eat it. The device is ASUS T200TA, the only sure drive is a 32GB eMMC (the HDD is detachable) and has only 2GB RAM.

Best Answer

If performance is good - you're not having to wait while switching between apps, with the disk thrashing and the activity LED solid on - then there isn't going to be a lot of wear to worry about either.

You could allocate a 2G space for swap at install time, and later tune the partition/swap size down e.g with GNOME Disks. Personally I would try 512M or 1G to start with. I assume you're not thinking about hibernation (which would usually want 2G+ swap).

Then I could see how much swap I used, and if I hit problems with out-of-memory or slowdowns with full swap. I confess I'm not sure how I'd distinguish thrashing the swap (too much active apps, enabled by too much swap) v.s. the cache (not enough swap to page out inactive app memory). In both cases you'd see the disk light on and pretty full swap. Maybe vmstat 1 and watch the swap column, if I could test a problem case reliably.

I would be cautious about 2GB swap on an eMMC (lower performance than expensive SSDs). Linux desktop memory management has a somewhat checkered history, and the swapping won't have been designed for eMMC.

If you use all that swap you may find the machine's become literally unusable anyway. Running out of memory can be better because you get the machine back without rebooting. Though it may kill programs you wanted & expected to survive.

My GNOME shell with a few apps has about 1G "used" (swapable) plus 1G+ "cached" (read-only data/code, can just be re-read from filesystem).

If you had punted 1G to swap, how long would it take to swap all that back, given your eMMC? (GNOME Disks can benchmark partitions for you :). E.g. 10 seconds to read it? Then if you're swapping the previous working set out at the same time, the (slower) writes on the eMMC are going to take even longer. Doesn't sound great to me.

One small reason for swap is tmpfs. My /run accumulates a meg or so, I doubt all needs to be in ram.

Related Solutions

Poor random read SSD performance on Linux

See discussion at Can I configure my Linux system for more aggressive file system caching?

In short, you probably need to have to tune some device queue settings. I'd guess scheduler or queue setting is incorrectly guessed by kernel or manually set.

Try

grep . /sys/block/sd*/{queue/{nr_requests,nomerges,rotational,scheduler},device/queue_depth}

and

lsblk

to debug the issue. You should have queue_depth and nr_requests set to at least 31 if you can tolerate the latency for a single read caused by NCQ, nomerges should be zero and rotational should be zero for SSD. Selecting the correct scheduler will be harder but for raw IOPS noop should be good enough. I find correctly tuned cfq to handle real world requirements a bit better.

And make sure the disk is connected with SATA + AHCI and you have NCQ enabled. Otherwise, there is little hope for getting everything out from your disk.

Is Swap Space Still Relevant? – Understanding Modern Memory Management

Don't confuse (the) swap (as a disk area) and (to) swap (as a method to move memory pages from RAM to disk and reciprocally).

Excessive swapping is something to be avoided for performance reasons but having a swap area isn't necessarily a problem.

On systems, like Linux, that overcommit memory, i.e. that allow processes to allocate more memory than available, running out of RAM with not enough swap to handle the situation will trigger the OOM killer. You have to trust the algorithm used to select the "right" process to kill, and accept one or more of your processes to be killed without being given a chance to shut down properly. Here is a famous analogy that explain why the OOM killer might not be a good idea at all.

On systems like Solaris, that do not overcommit memory, i.e that make sure a memory reservation is always backed by virtual memory, whether in RAM or on disk, having a sufficient swap area is absolutely necessary otherwise a potentially significant part of the RAM will be wasted.

Best Answer

Related Solutions

Poor random read SSD performance on Linux

Is Swap Space Still Relevant? – Understanding Modern Memory Management

Related Question