Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I've been reading this question, and it has a lot of great information.

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.

From my understand 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?

share|improve this question
    
I'd leave it on. Moderns SSD's should last the distance. See: storagesearch.com/ssdmyths-endurance.html. –  Matt Dec 29 '11 at 23:19
    
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. –  Matthew Ife May 5 '12 at 18:50

8 Answers 8

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 sf, 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 (200MB/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 pagefile. 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 5 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 100GB/day for 5 years, that's still fundamentally the same as 50GB/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 100GB 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 spec. 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)

share|improve this answer
    
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. –  Daniel Lawson May 27 '10 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)

share|improve this answer

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.

share|improve this answer
3  
That's great. Is there such a tweak for windows? –  Pyrolistical Jun 11 '09 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 Jun 11 '09 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.

share|improve this answer
    
I don't think apps can detect if they are using ram or swap. So how could that matter? –  Pyrolistical Jun 10 '09 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 Hodgson Jun 11 '09 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 Jun 15 '09 at 7:29
2  
Here is a reason to believe Windows does: blogs.msdn.com/ericlippert/archive/2009/06/08/… –  dmo Apr 9 '10 at 21:17

Just use a second hard drive for virtual memory.

share|improve this answer
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 Dec 6 '10 at 4:42
    
Not possible on most laptops. –  Brian Knoblauch May 16 '12 at 11:54

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.

share|improve this answer

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 max 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 50MB ram disk to swap to would be a win), but that was patch 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.

share|improve this answer
    
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. –  Daniel Lawson Jun 14 '09 at 23:20
    
Very true, it will just make them perform better. –  Ronald Pottol Jun 16 '09 at 1:50

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.

share|improve this answer
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 Jul 4 '11 at 8:20
1  
Windows will create a pagefile in memory? How's that? –  Mark Sowul May 5 '12 at 18:05

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.