Page file on SSD, shorter life - but does that matter now?

[dbcch3]

Traditionally, many have said no page file on an SSD because you want to minimize R/W activity, as FLASH chips have a limited lifespan. Wear leveling helps considerably, but SSDs will eventually die and we don't want them to die sooner.

However, I think the situation here might be changing. Look, SSDs have relatively long lifespans and are getting cheaper. Sure, we all still need hard drives for data storage, but I think if you expected to (reasonably) replace an SSD every could years, then you could readily use it even for a page file. After all, most of us end up replacing more than that every couple years just to 'keep up'. We'd probably want the latest SSD at that time anyway.

If we were to think of hard drives as wanting them to live as long as possible, would we be as obsessed about doing things that keep it alive (e.g. less spin downs)?

What do you think?

 

[nikorr]

Dont be worry about wear on system drive ....U can rewrite 20-50GB(depends on the size of an SSD) on your drive every day (u dont write all that much every day do u?) and it will be years before the end. Isn't the idea of having SSD to to have super fast PC?


Here read on The Page File

The Page File

1. The average user is best served by LEAVING THE PAGE FILE ALONE. Windows 7 does an excellent job of managing the page file settings for most people.

2. For 99.999% of the configurations on the planet you need a page file. Windows 7 itself wants one and a number of programs out there do too. If you think you can run your machine optimally without a page file you do not understand how Windows 7 (or any NT based OS works).
(Please don't email me to argue this, I won't respond. Find a forum to argue about it.)

3. The recommendations below are not designed to give you the highest scores on a synthetic benchmark but to give you the best overall performance for your system (including stability). The size of hard drives today are huge and making the page file a little larger than it "needs" to be hurts nothing and you're covered if you're ever doing something that requires more.

From Microsoft:
"Page file size equal to RAM: Prior to Windows 7 the default paging file size was determined differently on different versions of Windows. But in general terms, when the paging file size was configured as “system-managed” its size would typically be calculated as RAM x (some number greater than 1) or RAM + (some number).
In Windows 7 and Server 2008 R2 the default size is equal to the amount of memory installed in the machine. Your gut reaction to this is probably the same as mine was – to get a successful complete memory dump the paging file needs to be a little larger than RAM. How much larger probably goes back to what version of Windows you are running and other factors, but 300 MB is generally considered plenty of padding for the purposes of getting a complete dump.
Not to worry. A default installation of Windows 7 or Server 2008 R2 is configured to generate a kernel memory dump and also with a system-managed paging file size. So a paging file equal to RAM is plenty. If you decide that you want to capture a complete memory dump, simply change the dump option to “Complete memory dump” and restart (be sure to leave the paging file size as system-managed). After the restart the paging file should be RAM + 300 MB. This applies to both client and server SKUs."
ASKPERF - Windows 7 / Windows Server 2008 R2: Upgrade Paths, Registry Enhancements, Crash Dumps and Page File Sizing

One hard drive:
If you only have one hard drive or your other drives are significantly slower than your OS drive. Leave it alone.

Two hard drives:
The second drive should be near as fast or faster than the OS drive or there is no reason to do this.
Make 2 page files, one on the OS drive, one on the first partition of the second drive. The page file on the OS drive should be at least 300MB. The second page file should be equal to the amount of RAM (physical memory) or System managed size (preferred).

***Author's note - Based on emails I've received I do not seem to be making myself clear. If you have one hard drive DO NOT MOVE OR MAKE A SECOND PAGE FILE. If you have 2 drives and you make a second page file you should leave at least a small page file on the OS partition. The second page file should be on the FIRST PARTITION of the second drive.

http://www.tweakhound.com/windows7/tweaking/7.html

 

[dbcch3]

Right on all points, though way and far out from my original postulate .

I am glad that someone agrees the cost AND longevity of SSDs has gotten to the point where people can quit whining about this or that reducing the lifetime.

BTW, the people who think they don't need a page file do not understand that seldom referenced virtual memory is best paged out, to make room for disk cache (or other apps if they are that close to the margin). After all, no good keeping virtual memory in RAM if it is never accessed, it is a waste. Also, many people do not understand that what Windows sometimes calls 'free' memory is actually the portion used for disk cache, so it is utilized. The new Resource Monitor differentiates between unused and truly free.

Thanks for the second

 

[nikorr]

Can only agree with that.

 

[Mikey2]

I am a .net developer - does anyone have any information on how the managed .net framework works in conjunction with the pagefile etc? I understand from college how the pagefile works and even simulated the design (I have an BS in Computer Engineering from University of Illinois and a MA in Software Architecture from Carnegie Mellon...so I have had extensive training on this.)

However, in the "real world" we simply write C# applications (with a SqlServer database,) optimize it as best we can from the higher level, but let the .net framework handle all the dirty stuff underneath.

I am curious how optimal the compiler and runtime actually handle the pagefile/virtual memory etc(?) How efficient is it? (LOL I don't think any of us wants to go back to Assembly and manually do it, and if memory recalls even MFC/ATL C++ abstracts most of this out...)

 

[Dark Lord of Tech]

This topic has been moved from the section Windows 7 to section Storage by Area51reopened

 

[dbcch3]

I am a .net developer - does anyone have any information on how the managed .net framework works in conjunction with the pagefile etc? I understand from college how the pagefile works and even simulated the design (I have an BS in Computer Engineering from University of Illinois and a MA in Software Architecture from Carnegie Mellon...so I have had extensive training on this.)

However, in the "real world" we simply write C# applications (with a SqlServer database,) optimize it as best we can from the higher level, but let the .net framework handle all the dirty stuff underneath.

I am curious how optimal the compiler and runtime actually handle the pagefile/virtual memory etc(?) How efficient is it? (LOL I don't think any of us wants to go back to Assembly and manually do it, and if memory recalls even MFC/ATL C++ abstracts most of this out...)

The compiler and runtime (CLR) don't deal with paging at all - true for manged or unmanaged code.

That is for the virtual memory manager/subsystem. When a page of virtual memory is accessed, if it is not already in RAM, it generates a page fault the virtual memory manager of the OS handles. Then it is paged in real quick, and execution continues. Similarly, pages of virtual memory with low reference counts are 'paged out' to free up RAM for cache or use by other processes.

The only way in which the CLR and compiler affect virtual memory is in how optimally they make use of it. They have absolutely no control of the paging. While there are APIs that allow you limited control over what gets paged in or or out, it is generally best to leave them the heck alone, as the OS's virtual memory manager knows best.

As a side note, I do hope they at least still teach native code in the universities. I've been hearing more and more C#, and while it is a fine language, it is limited to managed code (unlike C++).

 

[beermatt]

Dont be worry about wear on system drive ....U can rewrite 20-50GB(depends on the size of an SSD) on your drive every day (u dont write all that much every day do u?) and it will be years before the end. Isn't the idea of having SSD to to have super fast PC?


Here read on The Page File

The Page File

1. The average user is best served by LEAVING THE PAGE FILE ALONE. Windows 7 does an excellent job of managing the page file settings for most people.

2. For 99.999% of the configurations on the planet you need a page file. Windows 7 itself wants one and a number of programs out there do too. If you think you can run your machine optimally without a page file you do not understand how Windows 7 (or any NT based OS works).
(Please don't email me to argue this, I won't respond. Find a forum to argue about it.)

3. The recommendations below are not designed to give you the highest scores on a synthetic benchmark but to give you the best overall performance for your system (including stability). The size of hard drives today are huge and making the page file a little larger than it "needs" to be hurts nothing and you're covered if you're ever doing something that requires more.

From Microsoft:
"Page file size equal to RAM: Prior to Windows 7 the default paging file size was determined differently on different versions of Windows. But in general terms, when the paging file size was configured as “system-managed” its size would typically be calculated as RAM x (some number greater than 1) or RAM + (some number).
In Windows 7 and Server 2008 R2 the default size is equal to the amount of memory installed in the machine. Your gut reaction to this is probably the same as mine was – to get a successful complete memory dump the paging file needs to be a little larger than RAM. How much larger probably goes back to what version of Windows you are running and other factors, but 300 MB is generally considered plenty of padding for the purposes of getting a complete dump.
Not to worry. A default installation of Windows 7 or Server 2008 R2 is configured to generate a kernel memory dump and also with a system-managed paging file size. So a paging file equal to RAM is plenty. If you decide that you want to capture a complete memory dump, simply change the dump option to “Complete memory dump” and restart (be sure to leave the paging file size as system-managed). After the restart the paging file should be RAM + 300 MB. This applies to both client and server SKUs."
ASKPERF - Windows 7 / Windows Server 2008 R2: Upgrade Paths, Registry Enhancements, Crash Dumps and Page File Sizing

One hard drive:
If you only have one hard drive or your other drives are significantly slower than your OS drive. Leave it alone.

Two hard drives:
The second drive should be near as fast or faster than the OS drive or there is no reason to do this.
Make 2 page files, one on the OS drive, one on the first partition of the second drive. The page file on the OS drive should be at least 300MB. The second page file should be equal to the amount of RAM (physical memory) or System managed size (preferred).

***Author's note - Based on emails I've received I do not seem to be making myself clear. If you have one hard drive DO NOT MOVE OR MAKE A SECOND PAGE FILE. If you have 2 drives and you make a second page file you should leave at least a small page file on the OS partition. The second page file should be on the FIRST PARTITION of the second drive.

http://www.tweakhound.com/windows7/tweaking/7.html

Point 2: As requested I won't email u to argue about it but this is a forum so I'll argue about it on here! Stop misleading people, if you have lots of RAM you don't necessarily need a page file and performance may be increased by getting rid of it (or at least making it much smaller). Quote from Microsoft themselves: "When lots of memory is added to a computer, a paging file may not be required." http://support.microsoft.com/kb/889654

Also the bit at the bottom about Kernel memory dumps, I'm not sure about this but isn't that only useful if ur computer's crashing? If you're not encountering blue screens / reboots I dont think you don't need kernal memory dumps at all.

 

[WyomingKnott]

In my humble opinion the original question was answered in the first response, and acknowledged by the OP.

Mikey2, if you want to address this further, please start a new post. However, I think that dbcch3 was correct.

As to whether or not you need a pagefile if you have "enough" memory, there are correct arguments on both sides.

I hereby declare this thread closed.

 

[WyomingKnott]

Best answer selected by WyomingKnott.