SSD Page File min max settings, what are yours and why?

[jnewegger23]

Hello,

I'm not here to debate whether to have page file for ssd on or off. Let's assume those posting to this thread want it on. The matter then lies in how do you have it on?

Currently, for lack of better reasoning other than majority rules I have page file on my 120GB SanDisk SSD with min and max both set at 1024MB. The SSD has 85GB free (71%) and is 1 month shy of being 1year old. I had done all the ssd tweaks in the book prior to my recent reinstall of windows 8. WEI is 7.4. I'm happy.

That said, I want to know for those of you who DO have page file on (again let's not hijack this thread by theorizing why you should have it off; I respect that choice and see the logic, no need to derail here please!) what min and max settings do you have for example Lat (anandtech forum participant I found in another thread) has his/her min at 200mb and max at 2000mb. I don't know the reason why.

In theory, to me at least, it would make more sense to set it like Lat does with a range, otherwise why would it be there and most data doesn't come at exactly 1024mb sizes right? I don't know, I'm a Neuroscience grad not a computer science one. So for those who know in theory why to have a range or not I definitely want to hear from you. For anyone else who simply wants to share their min/max settings I and I believe many others would find that useful as well. I've googled this topic and I find I have to read endlessly through hypothetical discussions as to whether to have page file on or off or not and little to nothing as to what min/max settings they have and if they do they only list one number leaving me to wonder if that's just the max or did they set both and why that number? I'm not losing sleep over it (I just sleep late no matter what! ha!), it would just be nice to know what's out there and any good reasoning as to why. Thanks for participating!

 

[ViRGE]

Honestly, Windows knows what an SSD is and how to use it. Leave it on automatic and stop worrying about it. That's how I've used it for nearly 4 years now across numerous machines with nary a problem had.

 

[mfenn]

Honestly, Windows knows what an SSD is and how to use it. Leave it on automatic and stop worrying about it. That's how I've used it for nearly 4 years now across numerous machines with nary a problem had.

The default Windows automatically managed page file size starts at the size of your memory and can grow to double. That's pretty significant if you have a 120GB or smaller drive.

I agree that you pretty much must have a page file enabled in Windows. Not for any OS-level technical reason, but because some programs attempt to be too clever about detecting page file size and simply crash if one isn't present.

My opinion is that if you're paging, then your performance has already gone to hell anyway, so you might as well limit the page file size so that programs will run out of memory and exit. If it happens frequently, then your problem is that you don't have enough memory, not that you need a bigger page file. I also don't like having a dynamically sized page file because Windows can only grow it while the system is on, it only gets reset to the initial size upon reboot.

To that end, I have a nominal page file of 2GB sitting on my SSD. Why 2GB? Cause it was a number that I picked out of the air. 1GB would have been totally fine as well, the important point is that it is some small, fixed size.

 

[jnewegger23]

So what do you have it set at? min = ? max = ?. Is it min = 2GB and max = 2GB I presume? Why not a range? Why does nobody do a range if it's there?

@virge. I'm not too worried. Just thinking about it and there are those out there who are very worried about it but don't participate. Regardless of worry, can someone respect what I'm asking in more detail. Please leave min and max values.

But I do appreciate both of your responses regardless but can you make sure others follow suit and leave a min and max value even if they are the same please! There are thousands of threads out there with people's theories (which I like to hear as well) but no data. More min/max data values please everyone! Thanks!

 

[Carson Dyle]

My current PC has 16GB of RAM, running Windows 7 Pro with a 128GB SSD as the system drive. When I built it, just for grins I eliminated the paging file completely. A year and half later and I haven't had a single issue.

 

[ShintaiDK]

My pagefile is zero, ever since 2006.

 

[Bateluer]

My page file has been Zero since I first moved to 8GB of RAM, through 16 and now to 32GBs. I didn't get my SSDs until well after I'd had 16GBs for a couple years. A page file on a modern machine is unnecessary and should simply be turned off entirely.

 

[jnewegger23]

na

 

[Cerb]

Off. The only BSOD I've had in the last 3 years has been from a Forceware update, so I'll worry about dumps if a quick Google doesn't put it all together for me; I'm used to it being off; while my SSDs (M500, Q) are surely much faster at it than older ones, I have experienced long page thrashing w/ a SSD, and would still prefer the offending programs to go ahead and crash, instead . If I ever use of one of those programs needing a page file just because, I'll turn it back on, but to date, I haven't, since the Windows 7 betas.

http://support.microsoft.com/kb/2860880
Most of what you'll want to know is right there.

If you're trying to save space for when not using much memory, setting the page file to a minimum that is smaller than RAM can help you do that. However, setting a small maximum gives you the same total virtual memory capacity as your RAM+PF, leaving you in potentially the same boat as no PF, if you were to happen to have wanted it to increase in size to get something done one day. Something to keep in mind, in you're going to limit it to a small value. The page file's needs are mostly based on your committed memory (it is displayed as current / peak in task manager), and if the peak reaches near your RAM+PF total size, you should increase your PF max size, if it's not set to managed.

Generally, if on, system managed is perfectly fine. Otherwise, it's a matter of trying to manage your space v. the usefulness of the PF, typically done for small SSDs, where a growing PF is a real concern, since it removes a lot of your free space. Trying to keep some free space, without giving up a safety net, is where the various min/max values come from.

 

[mfenn]

So what do you have it set at? min = ? max = ?. Is it min = 2GB and max = 2GB I presume? Why not a range? Why does nobody do a range if it's there?

Yes, min = 2GB, max = 2GB. That's how you say a fixed size. As for why not a range:

I also don't like having a dynamically sized page file because Windows can only grow it while the system is on, it only gets reset to the initial size upon reboot.

 

[masteryoda34]

Honestly, Windows knows what an SSD is and how to use it. Leave it on automatic and stop worrying about it. That's how I've used it for nearly 4 years now across numerous machines with nary a problem had.

With 24GB of RAM in my system, Windows defaults to creating a 36GB pagefile on my C: drive (SSD). I don't find that reasonable.

 

[jnewegger23]

Yes, min = 2GB, max = 2GB. That's how you say a fixed size. As for why not a range:

Thanks for the clarification. So, I currently have my C Drive (120GB SSD w OS)set at min = 1024 and max = 1024 pretty arbitrarily.

Is there any downside to setting my data drive D (4TB HDD) to having a page file about the size of my ram? I'm assuming the hierarchy in terms of windows protocols for data use would be
1) RAM (16GB: of course I'm not taking into the cpu cache but assuming after that)
2) Pagefile on SSD (1024mb)
3) Pagefile on HDD (~16GB)

if I were to go with this additional setup. For those who have it off I know this may be driving you mad but I'm trying to experience my own stability and performance standards on my new build before just agreeing to turning page file off as I'm okay with replacing parts and tend to upgrade somewhat frequently.

I know I'll probably never need or use even the smallest portion of it but some forums site that for crash reports for example a page file of just larger than your ram is recommended. I never have my desktop hibernate so it probably would be really a waste but with a 4TB drive you can see that I wouldn't be missing it much. I still have over 3.5TB available.

Conversely what would be any upside? I don't really see any. I'm throwing all this out there at the risk of looking ignorant because I actually agree with turning it off. I don't see the advantage to having it on much at all so atm I have it set small; that's my compromised response. I'm sure some others are obsessing over this greatly even more than I have for this thread but it's just plain curiosity at this point. I'm pretty happy with how it's all going but I wanted to take this argument to the extreme side of perhaps why one would have it on and even perhaps on two different drives and what would you have those settings exactly be and why. Any takers to defend this stance rather than have a thousandth person concur why it should be off?

 

[jnewegger23]

Off. The only BSOD I've had in the last 3 years has been from a Forceware update, so I'll worry about dumps if a quick Google doesn't put it all together for me; I'm used to it being off; while my SSDs (M500, Q) are surely much faster at it than older ones, I have experienced long page thrashing w/ a SSD, and would still prefer the offending programs to go ahead and crash, instead . If I ever use of one of those programs needing a page file just because, I'll turn it back on, but to date, I haven't, since the Windows 7 betas.

http://support.microsoft.com/kb/2860880
Most of what you'll want to know is right there.

If you're trying to save space for when not using much memory, setting the page file to a minimum that is smaller than RAM can help you do that. However, setting a small maximum gives you the same total virtual memory capacity as your RAM+PF, leaving you in potentially the same boat as no PF, if you were to happen to have wanted it to increase in size to get something done one day. Something to keep in mind, in you're going to limit it to a small value. The page file's needs are mostly based on your committed memory (it is displayed as current / peak in task manager), and if the peak reaches near your RAM+PF total size, you should increase your PF max size, if it's not set to managed.

Generally, if on, system managed is perfectly fine. Otherwise, it's a matter of trying to manage your space v. the usefulness of the PF, typically done for small SSDs, where a growing PF is a real concern, since it removes a lot of your free space. Trying to keep some free space, without giving up a safety net, is where the various min/max values come from.

Wow, very well said. This provides a lot of conceptual clarity and I greatly appreciate it! It sounds like I'm well setup but I'm very intrigued why even have it as a feature as you can see by my recent response above.

 

[Cerb]

1) RAM (16GB: of course I'm not taking into the cpu cache but assuming after that)

A bit of a nitpick, but there effectively isn't a before or after CPU cache. CPU cache is an overlay of RAM, and changes made to the cache must be visible everywhere, so the latest updates to the CPU's cache are effectively, on x86, identical to if they had been committed to RAM immediately upon making their way to being retired stores.

2) Pagefile on SSD (1024mb)
3) Pagefile on HDD (~16GB)

I wouldn't trust Windows to know that one is faster than the other. If you don't expect to need near 16GB, not counting file caches, just the one on the SSD will be fine, and will be big enough to make a kernel dump with.

 

[mfenn]

I wouldn't trust Windows to know that one is faster than the other. If you don't expect to need near 16GB, not counting file caches, just the one on the SSD will be fine, and will be big enough to make a kernel dump with.

I agree with not putting page files on different drive types. There's no way to tell Windows which one to use first. Your performance is going to tank if you swap onto the HDD at all.

Also agree that dumping core is not a good reason to have a big swap file. AFAIK, core dumps write into the filesystem itself at C:\Windows\Minidump.

 

[ViRGE]

I wouldn't trust Windows to know that one is faster than the other. If you don't expect to need near 16GB, not counting file caches, just the one on the SSD will be fine, and will be big enough to make a kernel dump with.

Actually Windows does know. That's one of the things the Windows Assessment Tool determines (along with IDing drives as HDDs or SSDs, etc).

 

[Carson Dyle]

What's the difference, as far as overall capacity is concerned, between having, say, 8GB of RAM and a fixed 8GB swap file and having 16GB of RAM and no swap file? Do they both give you exactly the same amount of virtual memory?

If so, then I don't see the value in designating a very small swap file relative to RAM size. Having a 1GB swap file over 16GB of RAM gives you a scant 6.25% more virtual memory.

 

[mfenn]

Actually Windows does know. That's one of the things the Windows Assessment Tool determines (along with IDing drives as HDDs or SSDs, etc).

That doesn't mean that WinSAT is plumped all the way through to something as fundamental as the VM subsystem.

What's the difference, as far as overall capacity is concerned, between having, say, 8GB of RAM and a fixed 8GB swap file and having 16GB of RAM and no swap file? Do they both give you exactly the same amount of virtual memory?

If so, then I don't see the value in designating a very small swap file relative to RAM size. Having a 1GB swap file over 16GB of RAM gives you a scant 6.25% more virtual memory.

There is no difference in the amount of pages that be written to in either case (8+8 and 16+0). In a perfect world, programs would not try to inspect the virtual memory subsystem too deeply and would just use it as it was intended to be used. But like I said before, not all programs are like that.

I agree that you pretty much must have a page file enabled in Windows. Not for any OS-level technical reason, but because some programs attempt to be too clever about detecting page file size and simply crash if one isn't present.

If the API call to detect the page file characteristics comes back with a null instead of the expected struct, and the programmer doesn't test for null, the program will just unceremoniously crash due to trying to deference a null pointer. There is usually no obvious indication of this error, leading to potentially baffling failures. I've run into this enough times to just put in a page file in order to appease poorly-coded programs.

Sure, you can make a truth & beauty argument that such a thing should not be needed, and I would agree with you. But I still want to reduce the incidence of annoying random crashes, and 2GB on my SSD is worth that.

 

[Carson Dyle]

If the API call to detect the page file characteristics comes back with a null instead of the expected struct, and the programmer doesn't test for null, the program will just unceremoniously crash due to trying to deference a null pointer. There is usually no obvious indication of this error, leading to potentially baffling failures. I've run into this enough times to just put in a page file in order to appease poorly-coded programs.

Sure, you can make a truth & beauty argument that such a thing should not be needed, and I would agree with you. But I still want to reduce the incidence of annoying random crashes, and 2GB on my SSD is worth that.

I don't quite follow this logic. Is there a difference between the OS coming back and telling the program that there is no additional memory because there is no page file and the OS doing the same because it's run out of virtual memory (whatever the size of the page file)?

 

[mfenn]

I don't quite follow this logic. Is there a difference between the OS coming back and telling the program that there is no additional memory because there is no page file and the OS doing the same because it's run out of virtual memory (whatever the size of the page file)?

No, there is no difference between a failure to allocate memory with or without a page file. But I'm not saying that the problem occurs when a memory allocation call fails.

What I'm saying is that programs that make use of the specific API call to discover page file characteristics can be coded poorly and not properly handle the "no page files" null result. In other words, the program is failing because it tried to be clever but implemented the cleverness poorly. If it had stayed blissfully unaware of the page file characteristics (like a proper program should), then it wouldn't run into an error.

 

[unixwizzard]

I set mine on the SSD to a few MB above what Windows complains is the minimum amount.. 800 MB on the SSD and a couple gig each on my regular hard drives..

with 16 GB system ram, probably don't need as much swap as I have set.. it's not like I'm hurting for space so I just leave it as is.

 

[Carson Dyle]

What I'm saying is that programs that make use of the specific API call to discover page file characteristics can be coded poorly and not properly handle the "no page files" null result. In other words, the program is failing because it tried to be clever but implemented the cleverness poorly. If it had stayed blissfully unaware of the page file characteristics (like a proper program should), then it wouldn't run into an error.

So you're talking about a program merely checking for the _existence_ of a page file? If that's the case, then why not have a 2MB page file instead of a 2GB one? Or maybe I'm still not following you.

 

[jnewegger23]

It sounds like in "theory" there is no actual need for page file assuming code is written correctly. But to paraphrase mfenn it seems that poorly written programs may say "rush" to the page file instead of performing status quo thus leading to an otherwise avoidable crash therefore just by virtue of having a page file at all it may help bypass that unnecessary crash. In effect, many of us want to turn off pagefile for the sake of performance of our ssd's and their theoretically increased longevity but for day to day it's easier to have a page file that is significantly large enough to be recognized by say "poorly" written code to avoid lack of page file crashes. Continuing this thought further, having an additional drive for next tier page files if another program was directed to seek it would be a continued exaggeration of such waste, so just have enough page file to avoid crashes at all and make it small enough to minimize any theoretical deterioation from "excessive" writes. This topic is highly hypothetical in that there are so many programs, drives, setups etc that it's no wonder why their is no set formula for what to set your page file at bc each user is specific in what they demand of their drives. It makes more sense now why no one lists exactly how they have it setup and why because it seems we each figure it out based on simply whether it works or not. Damn me for trying to find a logical shortcut! Also, I could be grossly misunderstanding a point or two! Anyone else care to correct any grossly out of bound thoughts on this? I feel I learn most when I realize how wrong I am. More and more I continue to grow in my appreciation of the Anandtech community!

 

[mfenn]

So you're talking about a program merely checking for the _existence_ of a page file? If that's the case, then why not have a 2MB page file instead of a 2GB one? Or maybe I'm still not following you.

To the bolded, yes that is what I am referring to.

As for the size:

To that end, I have a nominal page file of 2GB sitting on my SSD. Why 2GB? Cause it was a number that I picked out of the air. 1GB would have been totally fine as well, the important point is that it is some small, fixed size.

Windows won't let you set a page file smaller than 16 MB, but I imagine that that size would work fine a well. The important point is that it is a small, fixed size.