This is about Windows, but I'm sure it applies to other OS as well.
I've heard people say that if you want better performance, you should avoid swap file fragmentation. To do this, you can either manually specify a constant size for the swap file, or even move it to a dedicated partition/disk.
Will this really give any performance benefits? After all - the swap file is accessed in a randomized manner anyway, what's a bit more randomization? And if you're considering a separate disk for the swap file, then you would be far better off investing your money in more RAM instead. Unless you happen to get a free disk of course.
So - is there a point in fighting swap file fragmentation or not?
Pagefile fragmentation will only be a significant factor in extreme cases. Fragmentation is a factor when large files are read serially, but this almost never happens with the pagefile. Pagefile access is in small blocks of no more than 64K, and this will be usually mixed with access to other files. It matters little if the pagefile is fragmented or not, the disk heads will be moving around in any case.
None of this really matters unless pagefile performance is a limiting factor. And it usually isn't. Most paging doesn't use the pagefile at all. By design the pagefile is used to store data that is not accessed frequently. In most cases the pagefile isn't accessed often enough for it's performance to matter.
In most cases this is just much adu about nothing. The misquided attempts to solve the problem can, and often do, cause serious problems.
This certainly isn't an issue on Linux systems where swap is always a partition with a special file system for swap files. It's obviously a possible issue on Windows, and I think it's a possible issue on Mac OS X too since it seems to use files for swap.
TBH, I don't have any hard-facts to back up my view, but, I have anecdotal evidence that suggest it's better to have your swap not changing size because a change in swap size seems to really slow windows down while it's happening. The size of a disk you'll want for swap will always be smaller than what's currently considered an average disk, so, old disk will generally be more than big enough for swap. So, it's possibly a good use for an older disk when you upgrade to the latest 1TB disk.
When I ran Windows machines, I always either created a swap partition or used a separate disk, and then told Windows to use only that disk for swap, and set it not to change size. I would set it to use 2.5 times the amount of RAM as both the min and the max and leave it at that. I have no way of knowing for sure whether it really helped, but it certainly didn't have any negative side effects.
In short: Yes
Swap file fragmentation is a real issue, its more likely to happen the more less free space you have on your harddrive, there are also other files this can happen to like the registry db files. Microsoft is very clear in their advice on letting windows control the size of the swap file, and doing it manualy is considered bad and should only be done in very few cases. This problem has a easy solution from systeminternals called pagedefrag its a free download that can defrag the locked files ( including your paging file ) on system reboot. It will also show you current status on these files.
Also be aware that file fragmentation is only a issue on spinning harddrives, its my understanding that if a file is fragmented on a SSD its not a preformance issue ( A defrager on a SSD will only make it last shorter). The actual preformance loose greatly depends on how badly its fragmented and your system hardware ( seek time on the harddrive and how often the system has to hit the page file), but considering how easy it is to remove this problem it should be a none issue.
Links: MSDN on pagefile Mark Talking about Virtual memory ( Pagefile )
Your HD would need to be badly fragmented for any really observable perf loss here, but the theory is still sound nonetheless. The rationale is that you put your swap file on your fastest disk (for obvious reasons) and keep it all in a contiguous physical location so that seek times don't come into play so much. For a server or an enthusiast workstation this makes perfect sense; for a typical office PC with a single disk/single partition setup, you don't have the "fastest disk" option and you'll always have seek times as the heads move between actual files and the swap file, so it's more of a myth there.
You have to discriminate between internal and external fragmentation:
External fragmentation occurs when doing swapping (this means putting a whole processes onto disk), because each process has a different size. Since neither Linux nor Windows really do swapping any more, but do paging (putting a memory frame of fixed size onto disk), there is not really the problem of external fragmentation.
Internal fragmentation occurs when doing paging, because the size of each frame is equal, but not every page is full, some pages are not used to its limit (=internal fragmentation). This problem will always exist when using paging.
But I think you mean the occurrence of internal fragmentation in the file system (the blocks of the file system are not fully used) which holds the page frames. This may be avoided by choosing the block size on the file system to be equal to the size of a page frame.
I know that having your swap file on a separate physical disk improves performance by virtue of the fact that when you're swapping, you're probably also doing IO from your data disk, and thus reducing the performance of both operations. So that's the best option all around.
As for "free disks" well, what do you think we do with all those old 8 GB hard drives lying around the office? ;) Otherwise yes, RAM is cheap (for desktops) these days anyway, and is the best possible option.
No, there is no point in fighting swap file fragmentation, unless it doesn't involve time , money or effort.
I came up with a few long winded analogies, but decided to spare you - unless I change my mind :)
I believe swap file fragmentation although it is real and it happens, it doesn't make as much difference in real life as the defrag tool companies would have you believe.
I have often told windows to create the swap file on a different drive, that was just defragmented, (so a new file will get created ) and I can't tell I noticed any difference in day to day operations.
For the responder that recomenned that "users will just have to" close some applications: Bzzzzzt!! Wrong answer in any context.
If a machine has "enough" RAM it will run a lot faster with "millions" of windows open than a machine that is RAM starved whether swap file is fragmented, monolithic, decafeinated or bleached.
Any money spent on a defragmenter that can handle swap files is better spent on RAM. it's amazing how irrelevant the swap file becomes when you upgrade a machine from 256MB of RAM to 2 GB !
Swap file fragmentation only really gets much chance to occur if you allow the swap file to change size. Setting it to a fixed size will stop fragmentation appearing over time as the file grows and shrinks...
However, I would suggest that swap files are no longer useful. You are better off doing without the "extra memory" that the swap files provides and having the user accept that they need to close down some applications instead. You will no longer get that 10-30 second pause when an application has to load in from swap, and write another applications memory to swap...