locked
Paging file - where to put it? RRS feed

  • Question

  • In the old day of XP, the rules were simple: make the paging file 1.5 times the size of your RAM, and put it on a separate disk if possible.

    What is the received wisdom for Windows 7 64-bit?  For example, my pc has 6GB of RAM, and the C drive is faster than the E drive (where I could put my paging file).  And by the old rules, this would mean a paging file of 9GB!  Ridiculous. 

    So the question is twofold: 

    1. Do we move the paging file to a second, not so fast hard disk?

    2. What size should the paging file be when a lot of RAM is installed?





    Friday, June 24, 2011 1:39 PM

Answers

  • Hi pkn2011.  I have great respect for Mark Russinovitch, and I read the article with much interest.  Thanks for that.  On page file size, he says:

    "To optimally size your paging file you should start all the applications you run at the same time, load typical data sets, and then note the commit charge peak (or look at this value after a period of time where you know maximum load was attained). Set the paging file minimum to be that value minus the amount of RAM in your system (if the value is negative, pick a minimum size to permit the kind of crash dump you are configured for). If you want to have some breathing room for potentially large commit demands, set the maximum to double that number."

    So that answers that question.  On letting Windows mange the page file, he says:

    You’ll notice that the default configuration is for Windows to automatically manage the page file size. When that option is set on Windows XP and Server 2003, Windows creates a single paging file that’s minimum size is 1.5 times RAM if RAM is less than 1GB, and RAM if it's greater than 1GB, and that has a maximum size that's three times RAM. On Windows Vista and Server 2008, the minimum is intended to be large enough to hold a kernel-memory crash dump and is RAM plus 300MB or 1GB, whichever is larger. The maximum is either three times the size of RAM or 4GB, whichever is larger. That explains why the peak commit on my 8GB 64-bit system that’s visible in one of the screenshots is 32GB. I guess whoever wrote that code got their guidance from one of those magazines I mentioned!"

    • Marked as answer by Bigteddy Wednesday, July 6, 2011 2:12 PM
    • Unmarked as answer by Bigteddy Thursday, July 7, 2011 8:15 AM
    • Marked as answer by Bigteddy Thursday, July 7, 2011 8:16 AM
    Wednesday, July 6, 2011 2:11 PM
  • Hi,

    I noticed the following statement from the artical:

     "If you have enough RAM installed in your computer, you may not require a page file at all, unless one is required by a specific application."

    "There is no specific recommendation for page file size. Your requirements will be based on the hardware and software that you use and the load that you put on the computer."

    As to how it actually works may be a hard code when designing Windows we won't know. Also it is not suggested to manually change paging file settings without knowing both hardware and software side. So Leave it to Windows will be the best choice.

    Regards,


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
    • Marked as answer by Bigteddy Tuesday, July 5, 2011 12:42 PM
    Friday, July 1, 2011 7:24 AM

All replies

  • On Fri, 24 Jun 2011 13:39:30 +0000, Bigteddy wrote:

    In the old day of XP, the rules were simple: make the paging file 1.5 times the size of your RAM,

    It was never a "rule." It was a recommendation that some people made,
    but it was always a poor one. It's exactly backward. The more RAM you
    have, the less page file is needed.

    and put it on a separate disk if possible.

    A separate physical drive is generally good, but a second partition is
    also very poor advice; it does nothing but increase the amount of head
    movement and therefore slows you down.

    And also realize that if you have enough RAM for the apps you run, the
    page file is very seldom used, and therefore the settings for it
    hardly matter at all.

    What is the received wisdom for Windows 7 64-bit?  For example, my pc has 6GB of RAM, and the C drive is faster than the E drive (where I could put my paging file).  And by the old rules, this would mean a paging file of 9GB!  Ridiculous. 

    So the question is twofold: 

    1. Do we move the paging file to a second, not so fast hard disk?

    2. What size should the paging file be when a lot of RAM is installed?

    Again, there are no "rules." But it works the same way, and what you
    should do hasn't changed. Your word "ridiculous" is exactly correct.

    Just leave the standard setting. Any changes you make are highly
    unlikely to improve anything.


    Ken Blake, Microsoft MVP
    Friday, June 24, 2011 6:41 PM
  • I checked my paging file (currently managed by Windows), and it is 6GB, with a maximum of 9GB.  Those are the Windows auto settings.  And obviously, it's on drive C, because I haven't changed any of the default settings.

    I am happy to let Windows manage my paging file, and I hear you when you say that it will be seldom used, but I still wonder:  Surely 2 SATA channels are better than one?  And if Windows uses the paging file (which I think it does sometimes, regardless of how much RAM you put in) at the same time at it is accessing, say, program data, then wouldn't it be better on a separate disk  than on the same one.

    I agree that putting it on another partition on the same physical disk would be counter-productive.

    My comments on XP really only appied in the early days, when people had, like, 256MB of RAM.  On one of my servers, which has 4GB of RAM, I have found that a 3GB paging file is optimal.  So as soon as you go above 1GB, those 'rules' don't apply, I agree.

    Friday, June 24, 2011 7:22 PM
  • An afterthought:  Although you say the 1.5 recommendation was never a rule, it's interesting to note that when Windows is left to manage the paging file, it follows this 'rule'.

     

    Friday, June 24, 2011 7:28 PM
  • On Fri, 24 Jun 2011 19:22:18 +0000, Bigteddy wrote:

    My comments on XP really only appied in the early days, when people had, like, 256MB of RAM.  On one of my servers, which has 4GB of RAM, I have found that a 3GB paging file is optimal.  So as soon as you go above 1GB, those 'rules' don't apply, I agree.

    Again, even in early days of XP, the less RAM you have, the more page
    file you need. If you have as little as 64MB of RAM, a 96MB page file
    is almost certainly insufficient. If you have 2GB, a 3GB page file is
    more than almost anyone would need.


    Ken Blake, Microsoft MVP
    Friday, June 24, 2011 7:44 PM
  • This is the article is used to help me establish the aforementioned server paging file size:

    http://support.microsoft.com/kb/889654

    I am going to analyse my machine's performance according to these guidelines, and I'll post back to this forum if I find anything interesting.

    I'm especially interested to see if a separate paging disk will affect the figures.

    Friday, June 24, 2011 7:51 PM
  • Hi,

     

    Thanks for posting in Microsoft TechNet forums.

     

    How is it going? I would appreciate it if you could drop me a note to let me know the status of the issue. If you have any questions or concerns, please feel free to let me know.

     

    Best Regards

    Magon Liu

    TechNet Subscriber Support in forum. If you have any feedback on our support, please contact tnmff@microsoft.com


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
    Monday, June 27, 2011 10:07 AM
  • Hi Magon,

    There seems to be no concensus on the following questions, considering a Windows7 64-bit system with > 4GB RAM:

    For maximum physical RAM utilisation (and therefore maximum performance), should you manage the page file manually, or let Windows manage it?

    If the answer is the former (which I think it is), the questions are:

    1.  How big should the page file be?

    2. Should the page file be placed entirely on a separate disk, or should it be split among disks?

    If anyone can point to any Microsoft documentation on these questions, I would be very grateful.

     

     

    Monday, June 27, 2011 11:45 AM
  • Hi,

    I noticed the following statement from the artical:

     "If you have enough RAM installed in your computer, you may not require a page file at all, unless one is required by a specific application."

    "There is no specific recommendation for page file size. Your requirements will be based on the hardware and software that you use and the load that you put on the computer."

    As to how it actually works may be a hard code when designing Windows we won't know. Also it is not suggested to manually change paging file settings without knowing both hardware and software side. So Leave it to Windows will be the best choice.

    Regards,


    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. ”
    • Marked as answer by Bigteddy Tuesday, July 5, 2011 12:42 PM
    Friday, July 1, 2011 7:24 AM
  • Hi Magon,

    I have noticed from running performance counters over the last few days, that the % page file usage never exceeds 10%.   Windows is currently managing my paging file.  I have also read that if your paging file is too big, performance suffers.  Also, if Windows manages the page file, or you set it to have different current and maximum sizes (making it dynamic), that could lead to page file fragmentation.

    It seems like my paging file is too big (by a factor of 10!) when Windows manages it.

    Friday, July 1, 2011 7:40 AM
  • Hi BigTeddy,

    From your description, your PC is over specified for the work it's being put to. Windows paging file (and other) settings are for average working programs plus an additional factor to allow for maintenance, scans, etc. As your usage falls outside of the average presumed during the design of W7, why don't you change your paging file to say, 2GB fixed and continue to study the performance counters over the next few weeks. For a rough and ready check on how much combined RAM/paging file is used, check the Commit(GB) figure near the bottom of the Performance tab in Task Manager, up to 6/8 is fine, 7/8 means you need to increase the paging file size - fast! In my testing, reaching around 90-92% of commit meant imminent problems like programs or Windows itself crashing.

    My current PC has similar specs to yours and recently, a similar, low use pattern. Previously, it was working much harder, outside the average envelope on the other end. I still have 2x paging files of 4GB each (+ 4GB ReadyBoost) on different drives, currently only 1.6GB used. When the PC was working hard however, there were extended periods when the paging files were 85%+ capacity but the work output was around 25-30% more than was possible on the default settings.

    Unless your 2nd drive is significantly slower than the System drive, there may be times when a paging file on it would be used by Windows in preference to the System drive paging file, as the System drive has many other calls being made on it that could slow access to that paging file, meaning that Windows would prefer to use the 2nd paging file during those times as it would be faster.

    Friday, July 1, 2011 1:57 PM
  • Hi all,

    I think Magon was right when he said "Let Windows manage the paging file".  After exhaustive testing under light and heavy memory loads, I have settled on a fixed-size paging file of 4GB on a different disk. (My PC has 6GB RAM).  This is not much different from what Windows was doing, except it had a dynamic 6GB paging file on the same disk.

    The reason for putting it on a different disk is that I noticed that my 'average disk queue length' on drive C dropped when I did this, but not by much (from 450 to 400).

     

    Tuesday, July 5, 2011 12:41 PM
  • So Magon was right yet you still did it a different way, how illogical that seems ;)

    The reduced 'disk length queue' reasoning is touched upon in the last paragraph of my post above.

    I would advise retaining a small paging file on the System drive in case Windows needs to create a dump on BSOD. If you set Windows to create a minidump, then a 100MB page file will be ample and allow immediate troubleshooting.

    Tuesday, July 5, 2011 1:02 PM
  • I meant 'right' in a general way.  It's good enough for most users, and we don't really need to worry about it.  But after all my hard work of monitoring perfomance counters, and analysing them in a spreadsheet, I just had  to do my way! 

    I do think in my particular setup, that doing it 'my way' is resulting in a marginal performance improvement, but not enough to justify going through all that I did to get to that conclusion. (if you see what I mean).

    So in that way, I think Magon was right: It's not worth bothering about anymore.  This is not XP.

    Tuesday, July 5, 2011 1:31 PM
  • PS: Good tip about the C: drive paging file for dump purposes - thanks
    Tuesday, July 5, 2011 1:34 PM
  • There's a diversity of info on Paul Adams blog too - found at:

    http://blogs.technet.com/b/mrsnrub/archive/2009/03/13/the-ubiquitous-pagefile.aspx

     

    including in regard to dump file as quoted below:

     

    If your system bugchecks, you NEED:

    1. a pagefile on the boot drive with a minimum size at least as large as RAM+50MB

    2. the same amount of free disk space on the boot drive If you don't have this, you get no dump file generated.

     

    Regards, pkn2011

     

    • Proposed as answer by pkn2011 Saturday, August 6, 2011 3:14 AM
    Tuesday, July 5, 2011 7:48 PM
  • There's a diversity of info on Paul Adams blog too - found at: http://blogs.technet.com/b/mrsnrub/archive/2009/03/13/the-ubiquitous-pagefile.aspx including in regard to dump file as quoted below:

    If your system bugchecks, you NEED:

    1. a pagefile on the boot drive with a minimum size at least as large as RAM+50MB

    2. the same amount of free disk space on the boot drive If you don't have this, you get no dump file generated.

     

    Regards, pkn2011

     

    That would be for a FULL memory dump, only useful if you can debug yourself or have someone on your LAN able to debug it for you.

    Interesting link though :) Mark Russinovitch makes a quick revisit to page file sizing at the end of this article.

    Wednesday, July 6, 2011 12:14 AM
  • Hi Satrow, you said..

    That would be for a FULL memory dump, only useful if you can debug yourself or have someone on your LAN able to debug it for you.

    Interesting link though :) Mark Russinovitch makes a quick revisit to page file sizing at the end of this article.

     

    I'm battling with a dump file for just a single program at any one time, let-alone a FULL memory dump. 8-)  Lots more reading ahead..

    & although my pagefile strategy seems to work well on my 32bit Vista Laptop - whether it'll stand up on a 64 bit system is yet to be determined.. 

     

    thanks, pkn2011 

     

    Wednesday, July 6, 2011 1:21 PM
  • Hi pkn2011.  I have great respect for Mark Russinovitch, and I read the article with much interest.  Thanks for that.  On page file size, he says:

    "To optimally size your paging file you should start all the applications you run at the same time, load typical data sets, and then note the commit charge peak (or look at this value after a period of time where you know maximum load was attained). Set the paging file minimum to be that value minus the amount of RAM in your system (if the value is negative, pick a minimum size to permit the kind of crash dump you are configured for). If you want to have some breathing room for potentially large commit demands, set the maximum to double that number."

    So that answers that question.  On letting Windows mange the page file, he says:

    You’ll notice that the default configuration is for Windows to automatically manage the page file size. When that option is set on Windows XP and Server 2003, Windows creates a single paging file that’s minimum size is 1.5 times RAM if RAM is less than 1GB, and RAM if it's greater than 1GB, and that has a maximum size that's three times RAM. On Windows Vista and Server 2008, the minimum is intended to be large enough to hold a kernel-memory crash dump and is RAM plus 300MB or 1GB, whichever is larger. The maximum is either three times the size of RAM or 4GB, whichever is larger. That explains why the peak commit on my 8GB 64-bit system that’s visible in one of the screenshots is 32GB. I guess whoever wrote that code got their guidance from one of those magazines I mentioned!"

    • Marked as answer by Bigteddy Wednesday, July 6, 2011 2:12 PM
    • Unmarked as answer by Bigteddy Thursday, July 7, 2011 8:15 AM
    • Marked as answer by Bigteddy Thursday, July 7, 2011 8:16 AM
    Wednesday, July 6, 2011 2:11 PM
  • As the person who actually linked back to the Mark Russinovich article, can I ask you what your min. and max. page file sizes are now (or what they would be if you were to follow the advice you quoted above)?
    Wednesday, July 6, 2011 8:48 PM
  • What I did to assess a page file size was to load all my vm's with high memory requirements, until all my memory was used.  I got a warning from Windows when the available memory was too low.  That was with a 1GB paging file.  So I upped the paging file until, with the same load, I had no warnings, and the machine was working well enough.  Then I doubled it, for extra breathing space, and came up with 4GB. (6GB physical RAM).

    As far as minimum and maximum go, I keep them the same, to avoid fragmentation.

     

    Wednesday, July 6, 2011 9:06 PM
  • So pretty close to the : " As your usage falls outside of the average presumed during the design of W7, why don't you change your paging file to say, 2GB fixed and continue to study the performance counters over the next few weeks." that I suggested earlier then ;).
    Wednesday, July 6, 2011 10:57 PM
  • Hi Satrow,

    I think that was a good suggestion, and I didn't ignore it.  I did in fact set my paging file to 2GB, but I didn't need to monitor it for very long to find out it wasn't enough under very high loads.

    I don't run my pc under high loads very much, but even so, I don't want to think that Windows is hampered by something I've done.  So I doubled it for good measure.

    I don't think it's an excact science.  For example, with a 4GB page file, my %usage peak was around 10%.  So I dropped the paging file to 1GB, expecting to see a usage of about 40%.  But, no, the % usage actually dropped !  So who knows how Windows decides how to use it?

    Based on all that I have read and learned through this exercise, I would submit these 'rules of thumb' for best performance:

    1. If you have 64-bit Windows, and 4GB or greater RAM, set the paging file to somewhere between 2/3 RAM size and total RAM size, depending on memory load and how much physical memory you have.  The more physical memory the smaller the PF can be, but only down to a point.  As I say I think maybe half the memory size would be the absolute minimum if you are going to make full use of your RAM.

    2. Put the paging file on another, similar speed internal hard disk.

    3. Set the registry to create a custom dump file that you can specify the location of (avoiding the need for a PF on drive C:)

    But, I'll say it again:  This is for geeks only.  For general purpose use, as Magon said, leave it alone.  The performance hit is not going to be noticeable for most.

     

     



    Thursday, July 7, 2011 6:33 AM
  • Hi Bigteddy,

    Well it was Satrow who has credit for posting Mark R's link. I posted the one a message or 2 earlier re: "the ubiquitous pagefile", check back if you missed it..

    Going on what I've read so far I'll not be changing my pagefile settings from what they are at present. Custom size - with Windows recommended value as seen on the Virtual memory page as its initial size. Maximum at least double that. I kinda load everything up initially, and then close things if I'm not using them during the session as I go, so I kinda start at a peak type load every boot.

    My Max pagefile size in reality hasn't ever been above about 4.5 Gb (windows recommended 4603 Mb as set by me back in 2008) but usually it's somewhere between 3.5-4Gb (currently 2907M/7573M) - though I'm running withOUT the SmartRAM utility I usually employ - to see if it's better than with it. In fact I definitely liked it better WITH SmartRAM running I must say; things seem to have more delay on loading really (available RAM only 32% and there's a far smaller cache only 1.35Gb but for the moment I keep stopping myself from running it all the same.. 8-)

    Regards, pkn2011

    • Edited by pkn2011 Thursday, July 7, 2011 7:53 AM reforamtted text
    Thursday, July 7, 2011 7:47 AM
  • Hey pkn2011,

    Nice one for that link (I gave you a helpful vote).  Just to take a kind of a swerve back to the original question, "Where to put it?",

    I can safely say that it can (and should) be put entirely on a separate disk drive of similar speed to the primary one.  This is now feasable with Windows 2008, and Vista and above.  The following article explains how you can set memory dumps to a different drive than the primary one:

    http://support.microsoft.com/?id=969028

    Also, because hard drives are so cheap, and you need one anyway for Windows Backup, why not? (assuming you have a desktop machine)

     

    Thursday, July 7, 2011 8:23 AM
  • Hi Bigteddy,

    Thanks for the vote, I passed it onto Satrow for his helpful link too. I'm certainly still proud to receive my first Bronze medal though! 8-)

    Your post above also deserves a vote! and until this thread I can say I didn't recall that you COULD move the paging file, so I'll certainly be reading into this all further, I'm reconsidering my backups too as I include the 460 Desktop & HPmini into my thinking (in addition to this Laptop). I've only a 1TB drive for backups so far so I have to keep moving it from one to the other for backups each time at the moment - that's already becoming a pain in the proverbial, so time to get at least another 1-2Tb HD, I've also an older 320G WD usb-powered drive I'll likely dedicate to the HPmini..  

    Searching for the dumpfiles in the default  temp dir in appdata and manually moving them into a folder on the desktop needs a rethink for sure; so it'll be good to land them on my chosen path automatically - certainly a  much better idea. And you say cheap! my first 80Meg Hd cost me over $1000 back in the 1980's plus another several hundred for the controller.. <g> (SCSI on an Amiga500 hehe 1.5 meg of RAM from memory. Still I could run a mailer/BBS/fax on it Aok. 8-)

    I was definitely wanting to review how to manipulate the registry again - I've kinda forgotten in the days since I was using Win 3.1 odd.. I even dug up my old MSDOS manual the other week hoping to check what the "LEGACY" setup was on the 64bit nowadays. But I couldn't even set FILES=255 in config.NT so I'll have to get back to that sometime in the future.. I used to like having bunches of .BATs around launching assorted things for me in the past. oh well

    So first I'd better go order another HD so I can dedicate a backup drive to each of the 3 computers. and meanwhile get back into the reading I think!

    Regards, pkn2011   

     

    Thursday, July 7, 2011 9:29 AM
  • I often regret having thrown out my first pc:  The year was 1988, and it was a 12MHZ "XT" machine, with 1MB of RAM (of which less than 640KB was actually usable by programs) and a 20MB Seagate hard drive and 25x80 monochrome display.

    If I still had that now, it would be a collector's piece. It ran DOS 3.3, and I did all my programming in Turbo Pascal and dBase III.  Yes, we used to write our own programs back then.  Those were the days!




    Thursday, July 7, 2011 11:13 AM
  • Hi Bigteddy, my first PC was a card that lived inside an Amiga2500. It took me about a year to write scripts and BATs to fully automate it into my BBS setup. I still have it here, and it might all start up if I ever decide to turn it on again one day.  I guess it's got a pagefile too - though I'm not going to try moving it now. (OOTR) 8-)

    Nostalgia, pkn2011

    Thursday, July 7, 2011 11:47 AM
  • Hi all, when I said..

    though I'm running withOUT the SmartRAM utility I usually employ - to see if it's better than with it. In fact I definitely liked it better WITH SmartRAM running I must say; things seem to have more delay on loading really (available RAM only 32% and there's a far smaller cache only 1.35Gb but for the moment I keep stopping myself from running it all the same..

     

    No I can't take waiting for folders to load and them not. Programs to load and them getting stuck. My available RAM less than 35%. SmartRAM is back on and it's staying on!

    pkn2011

     

    Thursday, July 14, 2011 7:48 AM