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.