Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««1234

Can you set a pagefile more than 4GB? Expand / Collapse
Author
Message
Posted Monday, August 23, 2010 12:37 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, November 25, 2010 6:54 AM
Points: 71, Visits: 88
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.
Post #973221
Posted Monday, August 23, 2010 7:28 PM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Sunday, April 13, 2014 6:32 PM
Points: 438, Visits: 899
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
Post #973803
Posted Wednesday, September 01, 2010 4:44 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, January 28, 2011 2:32 AM
Points: 5, Visits: 12
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.
Post #978636
Posted Wednesday, September 01, 2010 4:48 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, January 28, 2011 2:32 AM
Points: 5, Visits: 12
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.
Post #978639
Posted Wednesday, September 01, 2010 11:51 PM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, November 25, 2010 6:54 AM
Points: 71, Visits: 88
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.
Post #979304
Posted Thursday, September 02, 2010 2:41 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Friday, January 28, 2011 2:32 AM
Points: 5, Visits: 12
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.
Post #979349
Posted Thursday, September 02, 2010 2:53 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, November 25, 2010 6:54 AM
Points: 71, Visits: 88
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.



Post #979357
« Prev Topic | Next Topic »

Add to briefcase «««1234

Permissions Expand / Collapse