I've been reading this question, and it has a lot of great information.
But assuming you have more than enough RAM, I think the page file should be disabled on SSD to extend the life time. I know you would lose the core dump on crash, but not many people need that information.
From my understanding, without a page file, as you reach the limit of your RAM, that might trigger thrashing on disk. But for SSDs there is no concept of thrashing, reads are fast.
What do you guys think?
But assuming you have more than enough RAM, I think page file should be disabled on SSD to extend the life time. I know you would lose the core dump on crash, but not many people need that information
This sounds rather like premature optimisation. You haven't discussed which SSDs you plan on using, and without actually looking at your server workload and your planned SSD datasheet, you cannot have any idea about what effect a page file will have on the lifespan of your SSD.
There is also a large volume of misinformation, both on the greater Internet and here on Server Fault, about SSDs suffering from poor lifespans. Early model SSDs may well have had issues, and USB flash drives definitely start to degrade, but enterprise-class SSDs have much better wear leveling algorithms and some make use of spare flash to improve performance and wear.
Intel X25-E drives, for example, claim a write duration of 1 petabyte of random writes for the 32 GB drive. If you're saturating the write interface (200 MB/sec) nonstop, with overwrite, my estimate is that will last you about 58 days. But that's writing something like 17 TB of data per day to that drive.
Typical server workload on the OS drive is going to be far, far less, even if you have a page file. Call it 50 GB per day. If the 1 PB figure is accurate (and I know it may be considered an average figure, more discussion later), that's still somewhere north of 50 years.
Those figures seem preposterously high, of course, so let's look at actual figures cited by Intel for expected longevity of drives. Intel were happy to qualify the MLC (non-enterprise) drives to write 100 GB of data, every day, for five years. Standard understanding of SLC vs. MLC flash says that SLC flash lasts about 10x longer than MLC (the above link shows this on a graph as well).
The truth will be borne out by time, of course - we'll either start seeing drives fail early or we won't. But the numbers behind the drives add up to drive longevity not being a problem with decent quality SSDs at all.
If you're using an MLC SSD, then you're perhaps right to be worried. But bear in mind that if Intel is happy to rate the drive at 100 GB/day for five years, that's still fundamentally the same as 50 GB/day for 10 years. And, back to my original point, you still need to know what kind of actual workload you're going to do on the drive.
Personally, I'd strongly say not to use an MLC SSD in a production server environment. If a decent SLC SSD is too expensive, stick to spinning disks for now.
(As an aside, if you do the numbers on, say 100 GB per day for 50 years, which is the "SLC lasts 10x longer than MLC" rating, it looks like Intel is saying their 32 GB drive actually has a total write lifetime of closer to 2 PB of data, not the 1 PB cited on the product specification. Even if I only trust the smaller of those two values to be happy that my X25-E drives should last well north of 10 years.)
In addition to the longevity probably not being an issue, as Daniel Lawson mentions, and feedback from the MS team itself (below), consider
Should the pagefile be placed on SSDs?
Yes. Most pagefile operations are small random reads or larger sequential writes, both of which are types of operations that SSDs handle well.
In looking at telemetry data from thousands of traces and focusing on pagefile reads and writes, we find that
- Pagefile.sys reads outnumber pagefile.sys writes by about 40 to 1
- Pagefile.sys read sizes are typically quite small, with 67% less than or equal to 4 KB, and 88% less than 16 KB.
- Pagefile.sys writes are relatively large, with 62% greater than or equal to 128 KB and 45% being exactly 1 MB in size. In fact, given typical pagefile reference patterns and the favorable performance characteristics SSDs have on those patterns, there are few files better than the pagefile to place on an SSD.
Rather than disable the pagefile altogether, it may be useful to tell the OS not to use it (for instance, sysctl vm.swappiness=0).
The OS will avoid using it unless necessary, saving the SSD unnecessary writes.
I'd leave the page file enabled always; certain parts of your OS or apps might be written to expect one to be there, and as such may misbehave if there isn't one.
Having said that, I have run Windows (XP) without a page file in the past, and it's been perfectly happy with everything I threw at it. There was always the niggling doubt though that something will come along that wouldn't like it.
An option might be to set it really small.
This is not directly responsive to the OP, but I wanted to correct a mistaken impression in the answer/comments above by Ronald and Daniel. (I'm new, so don't have enough points to comment.)
TRIM is in fact the biggest thing you can do to extend the life of an SSD. Here's why: SSDs periodically "garbage collect" - copy the (fragmented) data from partially empty erase blocks, and write it contiguously in a newly erased block.
The addresses are remapped so that the host need not be aware of this. This extra write activity, not directly associated with host writes, is called "write amplification". In the worst case of a completely full SSD with a small amount of overprovisioned (hidden spare) space, write amplification can easily be in the range of 500% - 700% of the host write rate!
During garbage collection, the SSD doesn't bother to copy and rewrite pages that have been invalidated (overwritten or TRIMmed), saving a potentially great deal of work and write activity. If the filesystem erases a large file, but it doesn't inform the drive via TRIM, the drive will continue to copy that erased data around, wasting writes, indefinitely (or until those block addresses happen to get assigned to some other file, which could be a long time).
In summary, TRIM is really important to both longevity and performance.
Just use a second hard drive for virtual memory.
I have stated this on the other post you linked but we run a very main-line server without a pagefile and everything here seems fine. In fact it seems faster without it. We have 8GB of RAM and I would say you should make your decision based on whether you have a lot of RAM, not whether your hard drive is a SSD or not. Although I can understand the wanting to save the life of it by not making unnecessary writes.
I have been running a laptop with 8 GB RAM, SSD single drive, and no page file, for more than a year now, no problems. I ran into one game that required the page file, went to software website and got the run command to disable it, problem solved.
My laptop is four years. Old, but it runs faster than some desktops that are newer. Memory leaks, aka SWAP file, has been the problem with Windows OS since the creation of the technique. Unfortunately, Linux developers followed in its footstep. The less software you're running in the background, the better (especially if it's Microsoft's).
I'd say don't use swap, if you can get away with it. Or perhaps turn swappiness way down. While it is hard to wear one out (how long would it take to write to the whole drive 100,000 times, at the maximum bandwidth you have?), if you don't need it.
Then again, hibernate (suspend to disk) doesn't work without some sort of swap.
There used to be some odd behavior with no swap (as in a 50 MB RAM disk to swap to would be a win), but that was patched last summer (or was it 2007?), so a current OS should be fine.
Now all we need is hardware that supports the erase command (Linux has supported it for months), and life on SSD will be just dandy.
I've had two enterprise-class SSDs burn out on me very prematurely (that is, well within the warranty period). I think the reason was heavy swapping due to thrashing. I often realized I had unneeded processes running/buggy daemons with memory leaks, such that there was heavy swap activity almost continuously. I run iostat -n9 -w 10 in the background from time to time and notice that often there is continuous heavy disk activity. Also the kernel process' (swap) activity was logged as the source of most I/O. I recall one daemon that had a memory leak for months and needed periodic killing. I often don't troubleshoot unless the system is annoyingly slow, so often the thrashing went on for a long time before I took the time to restart the daemon. And longer for the leak to be fixed.
While disabling swapping would draw my attention to the thrashing, so the problem would be addressed before major wear on the SSD had occurred, it's far from the best way to prevent such damage; any decent monitoring/alert tool would be better.
A caveat that many of the answers fail to acknowledge is that if a server IS thrashing an SSD continuously, it will burn out pretty quickly-burnouts within a year in this situation are common. Classic thrashing typically occurs when virtual memory swapping is heavy enough to keep the (swap) drive mostly busy - well within an order of magnitude of its maximum I/O bandwidth, and there is at least one process waiting for a swap-related I/O to complete most of the time that the system is in that state. The other answers assume that the system isn't thrashing, at least not in the classic manner; or rely on a misunderstanding of what thrashing is. And that false assumption, despite other accurate data, lead to incorrect answers as to WHY paging, even when an SSD is the only possible location for the swapfile, is best left enabled.
Disable the pagefile on disk when you have a lot of unused memory. Some old programs demand a pagefile functionality and for those Windows will create a small pagefile functionality in memory.
