Can you set a pagefile more than 4GB?

Question

Can you set a pagefile more than 4GB?

Viewing 7 posts - 31 through 36 (of 36 total)

You must be logged in to reply to this topic. Login to reply

ab.sqlservercentral SSC Journeyman Points: 89 More actions · Answer 1

Magic Man (8/20/2010)
ab.sqlservercentral (8/20/2010)
Magic Man (8/19/2010)
Why set a size and constrain the memory manager in the first place?. Set the pagefile as system managed, it will be set to an initial size and can grow with extents if required.
Because you will not get a valid memory dump in case you get a bluescreen. That's what the inital post was about.
You will because the OS will extend the pagefile size if needed to accomodate it.

It won't. In case of a BSOD, the paging file is just used as any preallocated space to back the memory dump. In case of a bluescreen, just a minimum of functionality is provided and autoextend is not part of it, at least the memory dump WILL be corrupt.

Try it out if you don't believe it.

antonio.collins SSCrazy Eights Points: 9600 More actions · Answer 2

ab.sqlservercentral (8/18/2010)
Guys,
those pagefile discussion drives me crazy. First, most of the posts are off-topic. The discussion is about MEMORY DUMPS, not about paging file calculation. Second, most people don't know the internals about paging:
- for all those who complained to need "hacks" and "tricks" and want to configure it to a minimum: Windows doesn't need a paging file.
- for those of you who calculate the paging file based on RAM: This is a wrong approach. The paging file doesn't need to be "2x RAM or 4x RAM" - it just depends. [snip] (and as I told in a previous post: Configure a kernel memory dump, that's enough in 98% of all cases).
- for those of you who care about fragmentation in the PF: The performance drop WHEN the paging file is used (it won't be often!) is THAT high that fragmentation just doesn't matter.
- Despite all myths about it: paging doesn't happen often. It's very hard to see (and DON'T take the hard faults as an indicator of paging!). [snip]
- A thumb rule: monitor your server look how the "peak commit limit" behaves. This is what might get paged out at MAX on your server to the paging file in the worst case. This number should be the basis of your calculation, not the size of RAM.
- If you use AWE in your SQL Server to support more than , your pages will NEVER be paged out.
- IF you set "lock pages in memory" your SQL Server pages will not get trimmed in case of high memory demand.
regards
Andreas

+5 Andreas!

on a small dev/test server, a large pagefile may be necessary, but a production db server shouldn't have a higher peak commit than its accesible physical ram. in fact, a large pagefile can hinder performance because the OS could start swapping executable pages -- that will kill performance. i would never suggest limping along in a memory starved environment by adding more paging space even if its on an ssd

Magic Man Newbie Points: 7 More actions · Answer 3

ab.sqlservercentral (8/23/2010)
Magic Man (8/20/2010)
ab.sqlservercentral (8/20/2010)
Magic Man (8/19/2010)
Why set a size and constrain the memory manager in the first place?. Set the pagefile as system managed, it will be set to an initial size and can grow with extents if required.
Because you will not get a valid memory dump in case you get a bluescreen. That's what the inital post was about.
You will because the OS will extend the pagefile size if needed to accomodate it.
It won't. In case of a BSOD, the paging file is just used as any preallocated space to back the memory dump. In case of a bluescreen, just a minimum of functionality is provided and autoextend is not part of it, at least the memory dump WILL be corrupt.
Try it out if you don't believe it.

It will because setting system managed should allocate an initial size that is at least as large as RAM. If it doesn't then do so manually before returning it to system managed.

Magic Man Newbie Points: 7 More actions · Answer 4

antonio.collins (8/23/2010)[hr
on a small dev/test server, a large pagefile may be necessary, but a production db server shouldn't have a higher peak commit than its accesible physical ram. in fact, a large pagefile can hinder performance because the OS could start swapping executable pages -- that will kill performance. i would never suggest limping along in a memory starved environment by adding more paging space even if its on an ssd

It won't hinder performance at all. The memory manager will only swap executable pages if it needs to, irrespective of the pagefile - executable pages wouldn't go to pagefile anyway since they are already backed on disk. They will just be dropped and paged back in as/when needed.

Gimping the pagefile only reduces the options available to the memory manager and make it more likely to drop executable pages at the expense of paging out (to pagefile) unbacked pages. Leave it alone, it can manage the memory better than you.

ab.sqlservercentral SSC Journeyman Points: 89 More actions · Answer 5

Magic Man (9/1/2010)
ab.sqlservercentral (8/23/2010)
Magic Man (8/20/2010)
ab.sqlservercentral (8/20/2010)
Magic Man (8/19/2010)
Why set a size and constrain the memory manager in the first place?. Set the pagefile as system managed, it will be set to an initial size and can grow with extents if required.
Because you will not get a valid memory dump in case you get a bluescreen. That's what the inital post was about.
You will because the OS will extend the pagefile size if needed to accomodate it.
It won't. In case of a BSOD, the paging file is just used as any preallocated space to back the memory dump. In case of a bluescreen, just a minimum of functionality is provided and autoextend is not part of it, at least the memory dump WILL be corrupt.
Try it out if you don't believe it.
It will because setting system managed should allocate an initial size that is at least as large as RAM. If it doesn't then do so manually before returning it to system managed.

That's just not true. Did you read the whole post? I was talking about crashes.

1. Again: In case of a BSOD (= system crash!), the paging file won't be increased. Your memory dump WILL be corrupt in case it doesn't fit in the paging file. Try it out.

2. windows doesn't caluclate the system managed paging file size based on RAM file size. I wonder where you have this information from? The paging file on my largest systems would be hundreds of GB if it was true - and they aren't! Windows doesn't need a paging file at all and it doesn't calculate the size based on the RAM size.

3. (what I already told): You need to take care to have as much paging file that a kernel memory dump can be written. You don't need a full memory dump in most cases.

Last but not least: This post was about Crashes and Kernel Memory dumps, not about how to manage the PF.

Magic Man Newbie Points: 7 More actions · Answer 6

For such huge RAM requirements then agreed, you don't need nor want a full dump, so set the size to that required by the dump but then leave it as system managed to enable future exapansion if required.

As for Windows not needing a pagefile. It doesn't need lots of things but can work a lot better with them. Why artificially constrain the job of the memory manager by not allowing it to manage the pagefile as it sees fit.

ab.sqlservercentral SSC Journeyman Points: 89 More actions · Answer 7

I don't say you should remove it. I just said, that windows is perfectly working without one. And I said that you shouldn't calculate it based on RAM size.