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?

  • I'd leave it on. Moderns SSD's should last the distance. See: storagesearch.com/ssdmyths-endurance.html.
    – hookenz
    Commented Dec 29, 2011 at 23:19
  • 1
    Also, providing your workload is appropriate to your server, you should hardly be paging to disk anyway (well, only paging where its beneficial). The last month alone my servers on average have only made about 100 page ins/outs for the whole month. Commented May 5, 2012 at 18:50

11 Answers 11


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.)

  • I think I'll revise my statement on using MLC SSDs: they seem to be good enough for enterprise use. I've heard that one major vendor with SLC SSDs are replacing their SLC range with MLC flash and smarter controllers. Commented May 27, 2010 at 22:26

In addition to the longevity probably not being an issue, as Daniel Lawson mentions, and feedback from the MS team itself (below), consider

  1. The pagefile will only be used when necessary anyway
  2. If the pagefile is being used, having it on the SSD vs a spinning hard drive will make an enormous difference

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.

Support and Q&A for Solid-State Drives (MSDN)


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.

  • 5
    That's great. Is there such a tweak for windows? Commented Jun 11, 2009 at 20:52
  • I'm not sure, but you might be able to emulate that by setting the page file size to the minimum (2MB) and allowing it to grow.
    – MikeyB
    Commented Jun 11, 2009 at 21:37

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.

  • I don't think apps can detect if they are using ram or swap. So how could that matter? Commented Jun 10, 2009 at 22:36
  • The OS was tuned to have virtual memory enabled, really. You have a point with SSD's, or I imagine you are right - I have read lots saying that there is a repetitive write problem with them, and virtual memory certainly does that. Can you not place the pagefile / swap on a proper disk? (seems counter-intuitive of course...)
    – Kyle
    Commented Jun 11, 2009 at 2:24
  • Why would an OS assume there's a page file? Linux certainly doesn't, and I've never seen any reason to believe that Windows does, either
    – Mikeage
    Commented Jun 15, 2009 at 7:29
  • 2
    Here is a reason to believe Windows does: blogs.msdn.com/ericlippert/archive/2009/06/08/…
    – dmo
    Commented Apr 9, 2010 at 21:17

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.


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.


Just use a second hard drive for virtual memory.

  • 1
    I think the point was to improve swap performance by using an SSD, if writing the pagefile to an SSD wouldn't burn through the drives available writes. Using a normal hard drive wouldn't offer the performance benefits that an SSD would.
    – jrista
    Commented Dec 6, 2010 at 4:42
  • Not possible on most laptops. Commented May 16, 2012 at 11:54

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.

  • The TRIM command won't do anything to extend the lifespan of an SSD - all it does is issue a block erase to clean up dirty blocks out of band. Normal behaviour is for an SSD to issue the erase as it goes to rewrite the block. Net result is that with TRIM, you potentially get better performance, but the SSD will still issue the same number of erase and write commands. Commented Jun 14, 2009 at 23:20
  • Very true, it will just make them perform better. Commented Jun 16, 2009 at 1:50
  • Daniel (and Ronald): If the SSD knows that a section of "disk" has been freed or zeroed, thanks to TRIM, it probably won't copy it around when doing write leveling or managing small writes. Which means fewer writes and a greater lifetime, no? Some sources that agree with me that seem solid: atpinc.com/Memory-insider/… superuser.com/questions/1063744/… wiki.archlinux.org/index.php/Solid_state_drive#TRIM - great resource for edge cases etc. Commented Oct 1, 2018 at 18:57

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.

  • 2
    I couldn't disagree with you more. Why not take a look at the accepted answer on the question this poster links to.
    – Chopper3
    Commented Jul 4, 2011 at 8:20
  • 2
    Windows will create a pagefile in memory? How's that?
    – Mark Sowul
    Commented May 5, 2012 at 18:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .