Should the paging file be moved from C: drive?


Should the paging file be moved from C: drive to another drive? This was the question I received today and thought I’d share my response to this.

There is no general answer for all situations, so this question needs more information about the environment. This is why you will not (and should not) find any official articles answering this question in any generalized form.

First, the paging file must be able to accommodate the crash dump settings. Windows Server 2003 requires the paging file to be on the system partition and be large enough to accommodate the crash dump setting. Windows Server 2008 and later allows the paging file to be on other direct attached drives when accommodating a crash dump. Complete memory dumps requires the paging file to be 1xRAM + 1 MB, Kernel memory dumps vary based on the amount of kernel memory usage such as pool paged and pool non-paged sizes estimating roughly 100 MB for every 1 GB of RAM. Small dumps require about 1 MB of a paging file.

Second, it depends on the amount of system committed memory that has been promised. The system commit limit is the size of RAM + paging files. It must always be larger than the system commit charge. The system commit charge will vary based on actual usage. With that said, committed memory doesn’t *not* mean that the paging file is actually being used. If the system commit charge is very large, but little of it is “touched”, then having a paging file on a slow disk drive is fine because the paging file is not really being used – just there to accommodate the commit charge *if* it happens to become “touched” memory.

Third, assuming the C: drive is a slow drive and that the system commit charge is greater than RAM, and the committed memory is actually “touched”, then the performance of the disk where the paging file is at is important. A page is 4 KB, so a sustained 1000 pages/sec (hard page faults) is 4 MB per second. Most 7200 RPM disk drives can handle 10 MB per second for reference.

If paging files are defined across multiple disks, then the paging file that is available first is used – meaning this is a load balanced situation which can help. Ultimately, if the paging file is *really* being used this much, then just add more RAM or place the paging file on a SSD.

In short, moving the paging file really depends on how much the paging file(s) are really being used (touched memory), the crash dump settings, version of the operating system, the system commit charge at peak, and disk drive performance.

Comments (15)

  1. TNJMAN says:

    In general, YES, when possible! ALWAYS move the page file to another physical disk, whenever possible. Basically, any paging that happnes OFF the "system disk" is good, BUT, the disk that holds the page file must be a disk of decent speed (7200 rpm or better – i.e., SSD, 15k SATA, etc.), and of adequate size.

    Additionally, whatever disk drive controller (embedded or separate bus-based controller), for the drive where the page file will reside, must be of adequate performance.

    And NO, if you have only separate "logical partions/drives," DO NOT MOVE THE PAGE FILE, because it will not improve performance. Example: you have one RAID 5 array of 3 disks, with D:, E:, F: partitions of different size; it would not imprive anything to move the page file from C: to D:, E: or F:, because ALL your partitions in this case are on the SAME PHYSICAL DISK AREA (3 RAIDed drives).

  2. Hi Eugene,

    Moving a page file to a location to a volume that is not replicated would be dependent on the replication software's behavior. If it understands page files and other related system files. For example, backup software generally will not backup a page file.

  3. Hi TNJMAN,

    Not all situations require moving the paging file to another disk drive. I've tried to explain this in my article. It really depends on the memory usage patterns of the system. You cannot generalize this for all situations. Some systems don't even need a paging file, while others must have one. Even ones that have a paging file might not even be using it.

    With that said, I agree with your other comments that placing a paging file on the same physical spindles is not beneficial.

  4. Eugene says:

    What about in cases of disk snapshots and disk replication — does the page file not represent ephemera and should be moved to a volume which is then not replicated?

  5. Dana Burns says:

    After reading some of these post I must say that there definitely seems to be some differences of opinion.

    First assess what the page file should be in size and to see what and IF you need one at all. Microsoft has couple decent articles or running perfmon and crunching some counters to figure out what your page file size should be. Not all machines use a swap file the same. A web server and an SQL server on the same physical hardware perform differently and as such use memory and your swap file differently.

    Second. If you can move the page file off, and you are ok with not being able to get full kernel dumps for your BSODs than do so. If you cannot get spate physical spindles (best option) you will see some minor performance increase in moving your swap file to a separate partition on the same disk (array), at least from a fragmentation perspective.

    Here are a couple interesting articles from MS regarding swap files:

    support.microsoft.com/…/2160852

    support.microsoft.com/…/889654

    All in all you need to 1st figure what you need before you ask yourself where to move it.

  6. Chris123 says:

    I want to move my pagefile out of C: because my C: partition is on a Solid State Disc, and any SSD has a limited life with respect to the number of WRITE operations. In Windows 7 (64bit) I set up a pagefile on a second (rotating) disc, and then tried to remove the Pagefile from C: on the SSD. This got me a message that "if the pagefile on C; is less than 400MB, then a dump of the Crash data when there is a System failure may be impossible". Is this a serious problem if a Crash occurs?

    The situation re SSD appears to be, if no pagefile on C: (on SSD), then Crash resilience is reduced (? seriously); but if there is a pagefile there then a crash is more likely to occur due to limited number of Writes on SSD. Which is the lesser risk?

  7. Keith says:

    Chris,

     That shouldn't be an issue if you disable the crash dumps (for the average user they really serve no purpose).

  8. Jamie Hanrahan says:

    Please be aware that if exe’s, dll’s, any file accessed through the file mapping APIs, and any file accessed with normal read/write calls without FILE_FLAG_NOBUFFERING… all are paged; the respective files are the backing store for the parts of virtual memory into which these files are mapped. In effect those are all paging files. So by moving the pagefile to some special place you are optimizing just one out of many many files (potentially hundreds) that are used to resolve hard page faults. The pagefile is only used for private committed address space (i.e. pageable stuff that has no other backing store). And if your hard fault rate is high it is likely not hitting only the pagefile.

    Moving your pagefile to a disk (or even a partition) by itself does have an advantage, however: You can then use the performance counters for that disk (or partition) to monitor your pagefile I/O activity, and see how busy it really is. The counters for “page reads/sec”, etc., include the results of page faults to all those other types of mapped files; they are not confined to pagefile I/O. (Corollary: You can therefore see significant page reads/sec, page writes/sec, etc., even if you’ve deleted the pagefile.)

  9. mir says:

    Hi ,

    I checked a production virtual server and found that C: drive space is low. Please find details below :

    OS name : MS windows server 2003 Enterprise x64 edition.
    version : 5.2.3790 service pack 2 build 3790
    total physical memory : 7GB
    total virtual memory : 17 GB
    pagefile space : 10GB

    I have another two drive and have suffecient space.

    Please suggest can I move pagefile to another drive or should i increase the C: drive space.

  10. Roger says:

    Even with logical volumes on Raided drives, In the case of low drive space on C: shouldn’t the page file be moved?

    e.g.
    C:OS = 5gb available
    D:Data = 420gb available

    So, even though they are a RAID on the same spindles, I should move my page file to D:, correct?

  11. Todd says:

    Roger – You are right. If they are on the same raid but the C: is too small move it to the other partition. I have done this on multiple servers where C: was undersized.

  12. Duncan says:

    My server has 144GB of RAM, and only seems to be using 12GB paging about half… Should I turn off paging?

  13. Mick says:

    I have a system that is a VMWare VM, the Drives are stored on a NAS, and the VM runs on a Dell poweredge 840. The 840 has a USB drive that VMWare runs from, and has a single 1TB drive in it that I use dedicated for shadow copies. I tried to move the swap
    file to the same drive , but when I did the backup stopped working. I eliminated all other page files, so I’m wondering if there’s something I’m missing? My goal is to not have to swap/page across the network to the NAS that the drives are stored on, but needless
    to say, I need backup to work too! Any recommendations are appreciated!

  14. CloudCatcher says:

    Re Pagefile:
    My laptop is a Samsung Series 7 NP700z5c.
    Can I use the now redundant SanDisk iSSD just for Pagefile?
    And if yes, do I make the pagefile equal to the size of the iSSD?

    I have changed the HDD to SSD, and the built-in iSSD (was used for speed increase) is no longer used.
    OS
    Windows 7 Professional 64-bit SP1
    CPU
    Intel Core i7 3615QM @ 2.30GHz 51 °C
    Ivy Bridge 22nm Technology
    RAM
    8.00GB Dual-Channel DDR3 @ 798MHz (11-11-11-28)
    Storage
    232GB Samsung SSD 850 EVO 250G (SSD) as ‘C’ drive
    7GB SanDisk iSSD P4 8GB (SSD) as ‘F’ drive

    1. Yes, you can have a page file on any direct attached storage device. Regarding the size, go with my KB article https://support.microsoft.com/en-us/kb/2860880.

Skip to main content