swap partition vs file for performance?

Question

What is better for performance? A partition closer to the inside of the disk will have slower access times, and we must wait for the drive to switch between the OS and swap partitions.

On the other hand, a swap partition bypasses all of the filesystem allowing writes to the disk directly, which can be faster than a file.

What is the performance trade off?

How much does having a fixed size swapfile make a difference?

Is it a case that it will be longer to change to the swap partition, but performance will be better while it is on the swap partition that if it had been a swap file?

Solution 1

1. On hard disks, throughput and seeking is often faster towards the beginning of the disk, because that data is stored closer to the outer area of the disk, which has more sectors per cylinder. Thus, creating the swap at the beginning of the disk might improve performance.

2. For a 2.6 Linux kernel, there is no performance difference between a swap partition and an unfragmented swap file. When a swap partition/file is enabled by swapon, the 2.6 kernel finds which disk blocks the swapfile is stored on, so that when it comes time to swap, it doesn't have to deal with the filesystem at all.

Thus, if the swapfile isn't fragmented, it's exactly as if there were a swap partition at its same location. Or put another way, you'd get identical performance if you used a swap partition raw, or formatted it with a filesystem and then created a swapfile that filled all space, since either way on that disk there is a contiguous region used for swapping, which the kernel uses directly.

So if one creates the swapfile when the filesystem is fresh (thus ensuring it's not fragmented and at the beginning of the volume), performance should be identical to having a swap partition just before the volume. Further, if one created the swapfile say in the middle of the volume, with files on either side, one might get better performance, since there's less seeking to swap.

On Linux, if the swapfile is created unfragmented, and never expanded, it cannot become fragmented, at least with normal filesystems like ext3/4. It will always use the same disk blocks, which are contiguous.

I conclude that about the only benefit of a dedicated swap partition is guaranteed unfragmentation when you need to expand it; if your swap will never be expanded, a file created on a fresh filesystem doesn't require an extra partition.

Solution 2

Actually it doesn't make a lot of difference as long as you don't use sparse files.

Creating a "normal" file with dd will allocate the file (if at all possible) in a single run, while creating a sparse file will tell you that you have a 10GB file lying around but not actually using up all the space. I'm not quite sure wether mkswap won't allocate the space anyway but typically a swap file will grow in time and thus won't allocate a continous sector (as in part of the disk) but rather allocate blocks as needed which lead to fragmentation over time (of course depending on your usage of the disk)

Internally the Linux kernel will access the underlying blocks of a swap file more or less directly - I can't find the link right now what happens under the hood, you have to trust me on this one unless someone will find something more official. All I can come up with right now is:

• a discussion on slashdot
• the wikipedia paging article
• some FAQ on ubuntu

this all applies to the 2.6 line of Linux kernels only.

If you want optimal performance (and what is that, really?... swapping is slow, period. Increase RAM so that you don't swap for best performance), you would want to use a partition.

Solution 3

This is an interesting question and have been reading a lot about the same. Generally a swap partition is better than a file due to the underlying filesystem. But if you are always in need to increase the size of your swap then file is a better option. Untill kernel 2.4 it was considered that a swap partition is faster than a file, but now with the improvements of kernel 2.6 , the performances are almost the same.

Something I found on internet as well.

http://www.go2linux.org/swap-file-vs-swap-partition

and

http://www.sunmanagers.org/pipermail/summaries/2005-November/006913.html

Solution 4

The thinking at our work is that since a Swap file can become fragmented, and fragmentation slows swap access, a partition is a better approach. Of course, defining a staticly sized swapfile does much the same thing but this just seems subjectively neater.

Is this approach the one true way? Probably not, as the practice was established close to 10 years ago. The only major change in drive technology in the intervening years is the complexity of the RAID controllers we use (we're not rich enough for SSD's yet). The increase in drive sizes means that the swap partition we create is closer to the start of the drive than it was back when 18GB drives were shipping standard, so swap speeds are even faster than they were in olden days.

Of course, on our ESX-based Windows systems, position of the swap file is completely, completely moot. There are so many layers of virtualization between the swap file and the physical disk platters that it just doesn't matter. But we keep it on a separate partition because that's just the standard.

Solution 5

I think at the stage we're at now, unless you're running a laptop with a configuration that writes the data to the swap when it suspends/sleeps, swap should really be considered "last resort". Your best bet is to put enough RAM in a box so that it never pages to disk.

That being said, a partition is probably the better way, performance wise, though a file is more flexible. Just make sure that it's on a 7200+ RPM spindle.

View more solutions

Comments

[Viky]

Just out of curiosity. Can you provide system details like kernel version, RAM, partition and filesystem scheme?

[Mathieu Chateau]

On what OS are you looking for ?

[Adam Monsen]

For Linux info, see lkml.org/lkml/2005/7/7/326

[kokbira]

Any update for the question answers?

[Sane]

Why would a partition be better performance wise, when access times can be more of a factor for delay?

[Sane]

Neither of those links really explain the reasons behind their decisions however.

[Viky]

The reasoning is that the file will have its underlying filesystem overload. If you create a file it could be fragmenged. and depending on the file which is being cached on swap, the reads could be slow as compared to an entire partition which is a swap file system in its own.

[Viky]

Tried to dig further and found relative article on wiki. Just to assist you there are few swap tuning parameters which you can check. Also check the explanation under implementation for linux. Might help. en.wikipedia.org/wiki/Paging

[Viky]

Followed one of the citations on the above mentioned wiki link and found an interesting thread about same issue. Might want to check that out. lkml.org/lkml/2005/6/28/427

[Sane]

I mentioned the filesystem overload in my question, but it is not as much a performance block as having a partition near the inner disk is. That delay would be great than the filesystem overhead.

[Axel]

Because using a file may require more head movements, because when finding the page to read/write the data could be anywhere on the filesystem so fs structures may need to be searched whereas with a swap partition each page will be in a known location within the partition. This makes access time (as apposed to bulk throughput) a differentiating factor.

[Tim Post]

Modern versions of swapon will outright refuse to work with sparse files formatted as swap, citing that the file has holes.

[Ash Stirland]

A swap file does not become fragmented, as the kernel uses a direct mmap approach and will never grow or shrink the file. +1 though for your comment on virtualization: it often does not matter.

[austinian]

Can you provide any sort of justification for your claims? This seems rather anecdotal.

[Nathan S. Watson-Haigh]

The only thing to add here is that if you machine is configured to "suspend to disk" what is actually happening is that stuff in memory is written to swap. For this to work, the swap must be on it's own partition as the swap can't be on an active filesystem for this to happen. Therefore, if you have a server, you probably don't use this feature and could happily use a swap file. If you have a laptop, you probably do want a swap partition so you are able to "suspend to file" for hibernation.

[XTF]

@NathanS.Watson-Haigh What happens with the data that's already in swap? It can't be thrown away.

[Matthias Weiler]

@NathanS.Watson-Haigh Can you link a source? Ubuntu 17.04 uses a swap file by default. It would be surprising if it couldn't "suspend to disk".

[Anon]

"Don't configure swap unless you need to hibernate" is a controversial view. Sometimes when the system is low on real memory swap can allow the system to recover. Not having swap can limit you from running programs that make huge memory allocations but don't actually touch most of it (e.g. certain debugging tools). Sometimes an occupied but idle region of memory is better used as disk cache and that can that tradeoff can only be done if there's swap available. See unix.stackexchange.com/questions/2658/… for discussion.

[Dan Dascalescu]

What @Anon said. Chrome is a notorious memory hog, and even with <100 tabs, my 16GB laptop becomes unresponsive for several minutes when memory utilization is around 90% and there's no swap file. Surprisingly, Ubuntu has no built-in mechanism to warn the user that the OS is running out of memory.

[marcelm]

@MatthiasWeiler For what it's worth, I tested this on Debian 10 (Linux 4.19), and it didn't work; boot.log contains resume: invalid resume device: /swap. It could be an initrd limitation instead of a kernel limitation, but I didn't dig further.