Download PC Repair Tool to quickly find & fix Windows errors automatically PageFile is a system file that Windows uses when it runs out of physical RAM or whenever it wants to store something temporary
and needs RAM for something else. That said, you can always change the location of the Page File and save it on another hard drive connected to your PC. However, some of the users noticed that Windows kept using HDD instead of SSD for Page File when the RAM was full. Since SSD will perform better, it looks like a better choice. In this post, we will
look at the solution that can fix the problem.
One user noticed on the Task Manager that the secondary hard disk (HDD 5800 RPM) was in heavy use. So
the user went ahead and disabled the Page File from the disk settings and rebooted the PC. However, to his surprise, the PC kept using HDD even though the page file was not there anymore. He even tried to delete the file physically, but it did not work. The solution is straightforward. When a user wants to unhide files, there are two settings— Show hidden files and folders and
Show/hide protected operating system files. The option can be seen when you open the File Explorer Options. If you want to delete the page file, then you need to enable this option and then go and delete the file. - Open File Explorer and click on the three-dot menu to open Folder
Options
- Switch to the View tab, and thenClick on the radio button next to the Show hidden files, folders, or drives.
- Check the box next to Hide Protected operating system file types
- Go to the HDD, locate the Pagefile.sys, and Swapfile.sys, and delete them
- Open Win + R to open the Run Prompt
- Type sysdm.cpl and press the Enter
key
- Switch to the Advanced tab and click on the Settings button under performance
- In the performance options window, switch to the Advanced tab, and click on the Change button under Virtual memory.
- Here you can configure the amount of Virtual memory or Page file.
Having done that, your HDD should not be under pressure when the RAM is full, and instead, the PC should deliver better performance with the SSD. I hope the post is helpful and you know how to
configure virtual memory on the PC. Do I need a page file if I have enough RAM?Pagefiles are still necessary since all operating systems reserve enough swap space before launching a program just in case its RAM is needed urgently. If you have enough storage space, you should allocate 10% or let the system manage it. What is Swapfile.sys?It’s a virtual memory file stored on your system drive, along with pagefile.sys and hiberfil.sys. It is generally used to swap out
Microsoft’s Store apps. It is super helpful if you use a lot of Microsoft Store apps. Ashish is a veteran Windows and Xbox user who excels in writing tips, tricks, and features on it to improve
your day-to-day experience with your devices. He has been a Microsoft MVP (2008-2010).
Ars Scholae Palatinae Registered: Jan 22, 2002 Posts: 820
|
| I imagine this question has been asked to death but which is better? Currently I have the page file set on my secondary HDD to conserve space on the SSD. My system has 16GB of DDR3 so I was tempted to disable it completely but I didn't.
|
Ars Legatus Legionis Registered: Aug 19, 2003 Posts: 22855
|
| Leave it on the SSD and don't disable it-- just let Windows manage it. If you have 16GB RAM, Windows will tend to manage the file very conservatively-- only writing to it on fairly infrequent occasions as you actually need to page out data from RAM. It won't get hammered like on a RAM-starved system. You do need one, though. Even though your application size isn't going to necessarily be a challenge for the amount of RAM you have, Windows just has to do housekeeping
sometimes, and may want to write to pagefile occasionally.
|
Ars Centurion Registered: May 11, 2009 Posts: 271
|
| Personally, I like setting the min/max page file size simply because if you are using an application that has a memory leak, your page file can grow to be a huge size. We've been bitten by this at work a few times.
|
Ars Scholae Palatinae Registered: Jan 22, 2002 Posts: 820
|
| gblansandrock wrote: Personally, I like setting the min/max page file size simply because if you are using an application that has a memory leak, your page file can grow to be a huge size. We've been bitten by this at work a few times. That happened to me yesterday. I was scratching my head wondering why the size of my SSD went down by 18GB. I checked the page file and windows had automatically set it to 18GB for some reason (recommended size was 5.5GB). I
then moved the page file to my secondary HDD.
|
Ars Legatus Legionis
et Subscriptor Registered: Nov 10, 1999 Posts: 14723
|
| If you are worrying about conserving space on your SSD, you need a bigger SSD.
|
Ars Legatus Legionis
et Subscriptor Tribus: Sierra Six Three Registered: Jan 21, 2001 Posts: 47680
|
| 1. Do not disable it completely.
2. Set it as system managed on your most spacious drive and forget all about it. I personally wouldn't put it on an SSD as SSD real estate is important and page files are not, so long that one exists which is able to size itself to at least the size of installed physical memory.
|
Ars Praefectus Tribus: Kenmore, WA Registered: Feb 19, 2002 Posts: 3845
|
| Keep in mind putting your page file on the HDD will stop it from spinning down.
|
Ars Legatus Legionis
et Subscriptor Tribus: Sierra Six Three Registered: Jan 21, 2001 Posts: 47680
|
| owdi wrote: Keep in mind putting your page file on the HDD will stop it from spinning down. On which OS? It certainly doesn't affect Win7 x64.
|
Ars Tribunus Militum Tribus: Upstate New York Registered: Apr 5, 2002 Posts: 2022
|
| Microsoft appears to recommend keeping the pagefile on a SSD for performance reasons. MSDN wrote: Should the pagefile be placed on SSDs? Yes. Most pagefile operations are small random reads or larger sequential writes, both of which are types of operations that SSDs handle well. In
looking at telemetry data from thousands of traces and focusing on pagefile reads and writes, we find that • Pagefile.sys reads outnumber pagefile.sys writes by about 40 to 1,
• Pagefile.sys read sizes are typically quite small, with 67% less than or equal to 4 KB, and 88% less than 16 KB.
• Pagefile.sys writes are relatively large, with 62% greater than or equal to 128 KB and 45% being exactly 1 MB in size.
In fact, given typical pagefile reference patterns and the favorable
performance characteristics SSDs have on those patterns, there are few files better than the pagefile to place on an SSD. Unless you're operating on a ridiculously small SSD, there are probably other, better candidates for relocation.
|
Ars Legatus Legionis
et Subscriptor Tribus: Sierra Six Three Registered: Jan 21, 2001 Posts: 47680
|
| Microsoft's information neglects that SSD space is normally at a premium. The pagefile is not performance critical (or even important) and is taking SSD space away from a potentially installed application which could be. If you have to hit the pagefile then who cares? Performance has already tanked. Being 100x faster than 10,000,000 times too slow isn't much of an improvement. Yes, a HDD is ten million times slower than (quite slow) RAM, and an SSD is around a hundred
times faster than a HDD for small random accesses. The SSD is still a hundred thousand times too slow. At this point, we're arguing whether we'd prefer AIDS or Ebola, firing squad or long-drop hanging. SSD real estate is too valuable to be wasted on something so irrelevant as a pagefile and if you get a bad memory leak, the pagefile can grow to encompass all available space, and so slaughter an SSD which needs about 20% free space to play with.
|
Senator Tribus: somewhere in nonpaged pool Registered: Mar 21, 2001 Posts: 20211
|
| neuromaster wrote: Microsoft appears to ... • Pagefile.sys read sizes are typically quite small, with 67% less than or equal to 4 KB, and 88% less than 16 KB. I think this info is suspect. You can't possibly have a pagefile read that's less than 4 KB... because that's the size of a page.
|
"Manual Labor"
Ars Legatus Legionis
et Subscriptor Tribus: Redwood City, CA Registered: Aug 7, 2001 Posts: 12574
|
| ^ They do say "or equal to"... you're almost certainly right, but they were sloppy in the way they reported their statistics.
|
Senator Tribus: somewhere in nonpaged pool Registered: Mar 21, 2001 Posts: 20211
|
| A lot, maybe a majority, of MSKB articles are written by college interns. Same for a lot of the code samples in the various development kits. They are at least cursorily checked for accuracy and valid conclusions, but if you're looking for something at the same level of Windows Internals, that's the wrong place.
|
Ars Legatus Legionis
et Subscriptor Tribus: Sierra Six Three Registered: Jan 21, 2001 Posts: 47680
|
| If all MSKB articles were written with the same level of competency as... say, the documentation with windbg, then there'd be a lot more highly accurate information about Windows in this world. Instead we get some real, real trash. The "%PRODUCT% may display %ERROR% when %CONDITION%" articles do little more than pollute Google.
|
Ars Tribunus Militum Tribus: Old Europe (Germany) Registered: Jul 3, 2003 Posts: 1698
|
| Hat Monster wrote: Microsoft's information neglects that SSD space is normally at a premium. The pagefile is not performance critical (or even important) and is taking SSD space away from a potentially installed application which could be. If you have to hit the pagefile then who cares? Performance has already tanked. Being 100x faster than 10,000,000 times too slow isn't much of an improvement. Yes, a HDD is ten million times slower than (quite slow) RAM,
and an SSD is around a hundred times faster than a HDD for small random accesses. The SSD is still a hundred thousand times too slow. At this point, we're arguing whether we'd prefer AIDS or Ebola, firing squad or long-drop hanging. SSD real estate is too valuable to be wasted on something so irrelevant as a pagefile and if you get a bad memory leak, the pagefile can grow to encompass all available space, and so slaughter an SSD which needs about 20% free space to play with.
??? This is utter nonsense. Tell me which file is more performance relevant than the page file?? Certainly not your average Word document. So IF I'd had to put anything on the SSD, then it would be the page file which is being accessed all the time but not an arbitrary application or document. Certainly it's slower than RAM, a lot slower. But still a factor of 100 makes a difference between 1 second and one and a half minutes. Unfortunately not everybody is in your comfortable position
to get 120 gigabytes of RAM into their machine.
|
Ars Legatus Legionis
et Subscriptor Tribus: Sierra Six Three Registered: Jan 21, 2001 Posts: 47680
|
| Quote: ??? This is utter nonsense. Tell me which file is more performance relevant than the page file?? Certainly not your average Word document.
If I want to load that Word document, then NO file on the system is more performance relevant. Quote: So IF I'd had to put anything on the SSD, then it would be the page file which is being accessed all the time but not an arbitrary application or document.
Then you don't
have enough RAM. Why do you have an SSD in a system with only 2 GB RAM? If the page file is being accessed all the time, then you plain need more RAM. No ifs. No buts. RAM. Now. Quote: Certainly it's slower than RAM, a lot slower. But still a factor of 100 makes a difference between 1 second and one and a half minutes.
That's not really how it works. Quote: Unfortunately not everybody is in your comfortable position to get 120 gigabytes of RAM
into their machine. They are in the position to get 8 or 16 GB. I take perfmon stats from a system with just 8 GB. It's coming up on three years old now. It's my main machine. The page file is irrelevant on this system. Were I to create a similar aimed system today, it would have 32 GB of RAM.
|
Ars Centurion Tribus: Ähtäri, Pohjanmaa, Finland Registered: Oct 22, 2005 Posts: 207
|
| All you need is one large file copy, and Windows happily throws stuff out from RAM to page file, to make room to disk cache. Full anti-virus scans, backups and stuff like that work too. If you have enough RAM, then you don't need a very large page file, so it isn't a problem that it's on an SSD, right? If you want to get really fancy, just put small, fixed size page file to an SSD and another, 0 to X GB file, to an HDD. Sure, it only matters occasionally, but it's
not like you are going to be accessing those particular gigabytes on an SSD very often anyway. Or if you are, you probably want larger SSD. It doesn't really matter whether you have 128 or 124 GBs available in the first place. -JLarja
|
Ars Tribunus Militum Tribus: Old Europe (Germany) Registered: Jul 3, 2003 Posts: 1698
|
| Hat Monster wrote: Quote: ??? This is utter nonsense. Tell me which file is more performance relevant than the page file?? Certainly not your average Word document.
If I want to load that Word document, then NO file on the system is more performance relevant. Quote: So IF I'd had to put anything on the SSD, then it would be the page file which is being accessed all the time but not an arbitrary application or
document.
Then you don't have enough RAM. Why do you have an SSD in a system with only 2 GB RAM? If the page file is being accessed all the time, then you plain need more RAM. No ifs. No buts. RAM. Now. Quote: Certainly it's slower than RAM, a lot slower. But still a factor of 100 makes a difference between 1 second and one and a half minutes.
That's not really how it works. Quote: Unfortunately not everybody is in your comfortable
position to get 120 gigabytes of RAM into their machine. They are in the position to get 8 or 16 GB. I take perfmon stats from a system with just 8 GB. It's coming up on three years old now. It's my main machine. The page file is irrelevant on this system. Were I to create a similar aimed system today, it would have 32 GB of RAM. If you argue like this, then you shouldn't put any file on the SSD because actually no file is worth the cost. Of course unless to use your computer
mostly single-task, ie compiling only slightly changed source code all the time of using a huge database. If on the other hadn you're a user like me, using Notes/e-mail, Chrome, Word with some 20-50 documents a day, Excel with the same number of sheets, Acrobat with uncountable numbes of pdfs, web-based applications and a lot more (which is a pretty much standard use case I'd say) then the page file contains certainly the most-used data.
In my specific case, my machine is trashing the HD /
page file all the time because in my corporate setup we are using Win7 32bit, so my RAM is limited to even less than 3GB which is a pain. I used to have a (physically) really small machine with a glacier-speed 1.8 inch HDD, and along with the corporate network stuff it customarily took 15 or more minutes after RESUME (!) from hibernate before it was actually usable.
|
Ars Tribunus Militum
et Subscriptor Tribus: Londinium Registered: Jan 6, 2005 Posts: 1951
|
| JLarja wrote: All you need is one large file copy, and Windows happily throws stuff out from RAM to page file, to make room to disk cache. Full anti-virus scans, backups and stuff like that work too. If you have enough RAM, then you don't need a very large page file, so it isn't a problem that it's on an SSD, right? If you want to get really fancy, just put small, fixed size page file to an SSD and another, 0 to X GB file, to an HDD. Sure, it only
matters occasionally, but it's not like you are going to be accessing those particular gigabytes on an SSD very often anyway. Or if you are, you probably want larger SSD. It doesn't really matter whether you have 128 or 124 GBs available in the first place. If you had Hat Monster's suggested 16 GB RAM, you do probably want a larger SSD, and your suggestion of multiple paging files seems more like "basic sysadmin" than "get[ting] really fancy"
In the 16 GB RAM scenario, the default behaviour of Windows is to take 16.3 to 48 GB of your SSD for paging. Add in the 16 GB it takes by default for hibernation, and you have to reserve 64 GB of that drive's ~110 GB formatted capacity before you've started. Even if you can shoehorn Windows, applications and user data into the remaining ~45 GB, it's no good as you'd want to leave ~30 GB free
to ensure consistent performance from the SSD anyway. So 16 GB RAM and a 120 GB SSD is by default an unbalanced configuration, and a "correct" solution with 16 GB RAM is a larger SSD. As most 16 GB machines are desktops, though, and a lot of these have large mechanical drives too, and Windows supports multiple paging files, specifying a small fixed-size paging file on C: and having a system-managed one on the mechanical drive is not unreasonable. My only question would be does
Windows post-Vista still prefer to page to the least-active drive (as XP and 2000 did) ? If so, this strategy would result in slower than desirable paging in normal use, but that's probably a price worth paying.
|
Ars Praefectus Tribus: Pittsburger Registered: Aug 28, 2008 Posts: 5617
|
| According to http://technet.microsoft.com/en-us/maga ... 82717.aspx it's better to have multiple paging files across several physical drives, though it doesn't say anything about preference. Ideally you'd hope that the smaller SSD paging file fills up before slower HDD is used.
|
Ars Legatus Legionis
et Subscriptor Tribus: Sierra Six Three Registered: Jan 21, 2001 Posts: 47680
|
| Quote: My only question would be does Windows post-Vista still prefer to page to the least-active drive (as XP and 2000 did) ? If so, this strategy would result in slower than desirable paging in normal use, but that's probably a price worth paying. It will page to the page file on the disk with the lowest I/O queue depth, though I think it doesn't count low priority/background I/O. Not sure on that one, DG probably knows. So yeah, least
active.
|
Ars Centurion Tribus: Ähtäri, Pohjanmaa, Finland Registered: Oct 22, 2005 Posts: 207
|
| If you had Hat Monster's suggested 16 GB RAM, you do probably want a larger SSD, and your suggestion of multiple paging files seems more like "basic sysadmin" than "get[ting] really fancy" I do (both on my personal laptop and on my work computer). I also have a desktop with 12 GBs. Generally, I consider even talking about page file "fancy", and anything up
"really fancy", but perhaps that doesn't quite work in Ars forums .In the 16 GB RAM scenario, the default behaviour of Windows is to take 16.3 to 48 GB of your SSD for paging. Add in the 16 GB it takes by default for hibernation, and you have to reserve 64 GB of that drive's ~110 GB formatted capacity before you've started. Even if you can shoehorn Windows, applications and user data
into the remaining ~45 GB, it's no good as you'd want to leave ~30 GB free to ensure consistent performance from the SSD anyway. So 16 GB RAM and a 120 GB SSD is by default an unbalanced configuration, and a "correct" solution with 16 GB RAM is a larger SSD. As most 16 GB machines are desktops, though, and a lot of these have large mechanical drives too, and Windows supports multiple paging files, specifying a small fixed-size paging file on C: and having a system-managed one on the
mechanical drive is not unreasonable. My only question would be does Windows post-Vista still prefer to page to the least-active drive (as XP and 2000 did) ? If so, this strategy would result in slower than desirable paging in normal use, but that's probably a price worth paying. Why would you let Windows take 16 GBs for paging, if you don't expect to need it? I suggested 4 GBs above, but if you are really sure, you only need few megabytes (at least, if you have other, on
demand page files on other disks). The 16 GBs required for hibernation just means that we are talking about 112 GBs vs. 108 GBs instead of 128 vs. 124 (to go by my example). And if you think 16 to 48 GB page file is required, you probably prefer to have that on SSD instead of HDD, even if it is only 100 times faster (right course of action would be, of course, to add more memory). Heck, you'd probably want to buy an SSD just for that. -JLarja
|
Ars Tribunus Militum
et Subscriptor Tribus: Londinium Registered: Jan 6, 2005 Posts: 1951
|
| Why would you let Windows take 16 GBs for paging, if you don't expect to need it? Well, people do because by default this is what Windows does, takes RAM+300MB to 3*RAM on %SystemRoot% for pagefile.sys, and 99% of the Windows users out there don't change default behaviour. (This issue is going to go away, as Windows 8 introduced a much lower minimum of a few MB, in recognition of this problem. Vista and 7 use the above range, 2000 and XP set it
as RAM to 3*RAM.) Quote: I suggested 4 GBs above, but if you are really sure, you only need few megabytes (at least, if you have other, on demand page files on other disks). Thinking more about this, I'm not sure this is such a good strategy. If you have one other, Windows-managed paging file on one other disk, your paging file on the SSD will only get used when you're keeping the other disk busy. If, as you suggest, you had multiple paging file on other disks Windows
would spread the load depending which disk is busy - but still, the 4 GB or few MB paging file on the SSD would be largely unused. If you're really sure your commit charge peak is and will remain less than installed RAM, then a few MB or GB is a reasonable amount of a ~120 GB SSD to allocate for paging, and you've still got some paging ability. Quote: The 16 GBs required for hibernation just means that we are talking about 112 GBs vs. 108 GBs instead of 128 vs. 124 (to
go by my example). Nitpick: your example 128 GB SSD is a ~117 GB formatted C: partition, so your 4 GB fixed-size paging file and 16 GB hibernation file put you at 97 GB. One a 120 GB SSD, you'd be at 90 GB with a small 4 GB fixed paging file, versus 94 GB if you move it on to the HDD. Quote: And if you think 16 to 48 GB page file is required, you probably prefer to have that on SSD instead of HDD, even if it is only 100 times faster (right course of action would be, of
course, to add more memory). Heck, you'd probably want to buy an SSD just for that. In an environment where you can size for your workload (e.g. by monitor current commit charge and determining the peak and sizing off that), these ideas are reasonable - but on a standard laptop or desktop, a 16 to 48 GB paging file is what you get, by default, from Windows when you have 16 GB RAM - so in a typical environment where people don't think about these things, a %SystemRoot% of ~120 GB is a bit
skinny. The simple solution is to tell people to spec either a 256 GB or larger SSD, or Windows 8
|
Ars Centurion Tribus: Ähtäri, Pohjanmaa, Finland Registered: Oct 22, 2005 Posts: 207
|
| Why would you let Windows take 16 GBs for paging, if you don't expect to need it? Well, people do because by default this is what Windows does, takes RAM+300MB to 3*RAM on %SystemRoot% for pagefile.sys, and 99% of the Windows users out there don't change default behaviour. Well, we haven't talked about default behaviour at any point. For what it's worth, I completely agree that using Windows on a <= 120 GB disk is something that
may get average user in trouble (you need to keep an eye on it, think about what files you can store etc.). I certainly don't want to go through the trouble. But obviously this thread isn't about what average users do. Quote: Quote: I suggested 4 GBs above, but if you are really sure, you only need few megabytes (at least, if you have other, on demand page files on other disks). Thinking more about this, I'm not sure this is such a good strategy. If you
have one other, Windows-managed paging file on one other disk, your paging file on the SSD will only get used when you're keeping the other disk busy. If, as you suggest, you had multiple paging file on other disks Windows would spread the load depending which disk is busy - but still, the 4 GB or few MB paging file on the SSD would be largely unused. You need to set the other page files to start at zero size (as I suggested) and only grow on demand. Their only purpose is to prevent
crashing if some unexpected memory spike occurs. If that happens, then you are in trouble anyway, because your ridiculously finely tuned system isn't behaving as expected. My point is that if there's no demand, then the (small) page file should be on the SSD. If there is, then the page file should be on SSD for performance reasons. Quote: Quote: The 16 GBs required for hibernation just means that we are talking about 112 GBs vs. 108 GBs instead of 128 vs. 124
(to go by my example). Nitpick: your example 128 GB SSD is a ~117 GB formatted C: partition, so your 4 GB fixed-size paging file and 16 GB hibernation file put you at 97 GB. One a 120 GB SSD, you'd be at 90 GB with a small 4 GB fixed paging file, versus 94 GB if you move it on to the HDD. I guess that next time I should just write some convoluted examples of N GB
page files on M GB SSD on a computer with P GBs of memory, giving some limits to N, M and P that I find sensible. Yeah, that will really clear things up.After 3+ years, my work computer has 60 GBs in Windows + Program Files + Program Files (x86). Excluding Spotify's cache, Users dir has about 10 GBs. So we have 70 + 16 (hibernate) + 4 (page file) = 90. Frankly, I don't really see much difference between 10 GBs free or 30 GBs free. Both are way too low for me to be comfortable with. 10 GBs
vs. 14 GBs or 30 GBs vs. 34 GBs are just noise. -JLarja
|
Senator Tribus: somewhere in nonpaged pool Registered: Mar 21, 2001 Posts: 20211
|
| All you need is one large file copy, and Windows happily throws stuff out from RAM to page file, to make room to disk cache. Not necessarily. Any reasonable file copy method uses file mapping, which does not go through the file cache. Or, it may use FILE_FLAG_NOBUFFERING, which also does not go through the file cache. (n.b.: It's a file cache, not a disk cache. There's a difference.) Even if one did use a stupid file copy method, the file cache's working set is
not allowed to grow without bound at the expense of process's working sets. And even when something is "thrown out of RAM", it isn't necessarily written to the pagefile. The pagefile is but one of many dozens (or more) of files used as "backing stores."
|
"Let there be Bacon."
Ars Legatus Legionis Registered: Mar 26, 1999 Posts: 19608
|
| Didnt we already have this screaming match in the MS sw fora? Boot drive - SSD, disable the page file on teh ssd, enable it on a 2ndary non ssd hd (or across multiples if you have multiple drives) importantly, leave it as windows managed, dont set a lower and upper bounds, dont try and be clever and do the old 1.5x memory stunt, taht was great in win95 era, but now hard drives are using NTFS / win8 format, not fat32 . TLDR: Put the page file on a
normal HD, set it for windows managed, LEAVE IT ALONE.
|
Ars Praefectus
et Subscriptor Tribus: Washington, DC Registered: Nov 9, 2007 Posts: 4895
|
| You could always leave it on the SSD too--if you have the space.
So, if you are going to stuff 16GB of RAM in a machine, go with a 256GB SSD. I have a Latitude E4310 at work, 128GB SSD, 8GB of RAM.There is plenty ofroom for all the standard office apps, a bunch of networking and management tools, isos, etc. Run the WEI, leave everything else alone.
|
Senator Tribus: somewhere in nonpaged pool Registered: Mar 21, 2001 Posts: 20211
|
| You need to set the other page files to start at zero size (as I suggested) and only grow on demand. Their only purpose is to prevent crashing if some unexpected memory spike occurs. If that happens, then you are in trouble anyway, because your ridiculously finely tuned system isn't behaving as expected. My point is that if there's no demand, then the (small) page file should be on the SSD. If there is, then the page file should be on SSD for performance reasons.
"You are in trouble anyway because your system isn't behaving as expected" is a mighty thin justification. If your system suddenly needs additional pagefile space, you really don't want to put more delays in the path by requiring it to extend the pagefile.
|
Ars Centurion Tribus: Ähtäri, Pohjanmaa, Finland Registered: Oct 22, 2005 Posts: 207
|
| You need to set the other page files to start at zero size (as I suggested) and only grow on demand. Their only purpose is to prevent crashing if some unexpected memory spike occurs. If that happens, then you are in trouble anyway, because your ridiculously finely tuned system isn't behaving as expected. My point is that if there's no demand, then the (small) page file should be on the SSD. If there is, then the page file should be on SSD for performance
reasons.
"You are in trouble anyway because your system isn't behaving as expected" is a mighty thin justification. If your system suddenly needs additional pagefile space, you really don't want to put more delays in the path by requiring it to extend the pagefile. Sure. In my opinion, one should just buy a bigger SSD and this whole conversation is moot. It all depends. At home, I often have commit charge near 30 GBs on a computer, just because I have set BOINC to
keep stuff in memory. If I had an SSD in that (especially if it was a small one), I probably wouldn't want to have the massive page file on it. The fluctuations in commit charge are also pretty big. However, on my laptop, which has 16 GBs of memory, commit charge hardly ever ovet 10 GBs and 4 GB page file seems to be more than enough. If the laptop had second hard drive, I probably set up another page file there, just so that if something goes wrong, it will start filling the other drive
instead of boot drive. However, during two years nothing (like that) have gone wrong, so I'm not too worried. My laptop use case simply doesn't seem to include 64 bit software that leaks memory. -JLarja
|
Ars Praefectus
et Subscriptor Tribus: dm17 Registered: May 29, 2006 Posts: 3874
|
| My rule of thumb is: Stick it on the drive that has the lowest load, and set Min=Max=Ram*3.
|
Ars Tribunus Militum
et Subscriptor Tribus: Londinium Registered: Jan 6, 2005 Posts: 1951
|
| Well, we haven't talked about default behaviour at any point. For what it's worth, I completely agree that using Windows on a <= 120 GB disk is something that may get average user in trouble (you need to keep an eye on it, think about what files you can store etc.). I certainly don't want to go through the trouble. But obviously this thread isn't about what average users do. The thread was started in response to someone bitten by the default behaviour and
asking for advice after changing from the default to paging to the HDD. The first reply advocated sticking with the default behaviour. Sure, though, the thread isn't about what average users do. Quote: You need to set the other page files to start at zero size (as I suggested) and only grow on demand. Their only purpose is to prevent crashing if some unexpected memory spike occurs. If that happens, then you are in trouble anyway, because your ridiculously finely tuned system
isn't behaving as expected. My point is that if there's no demand, then the (small) page file should be on the SSD. If there is, then the page file should be on SSD for performance reasons. Does this work? I'll have to try this out when I've got a moment and see whether the system pages to a 10 MB C:\pagefile.sys or a 0 MB but growable E:\pagefile.sys Seems to me that the Windows default is not a good one and tinkering with this is very sensible, but I'm wary of proposals for
ridiculously finely tuned systems. I like Darkseid's suggestion. Quote: Frankly, I don't really see much difference between 10 GBs free or 30 GBs free. Both are way too low for me to be comfortable with. 10 GBs vs. 14 GBs or 30 GBs vs. 34 GBs are just noise. 34 GB free on a 120 GB SSD is just fine, IMO, and 30 GB free is about as low as I'd want it to go - so the space saved by not having a 4 GB C:\pagefile.sys does make a difference. The price jump to a 180 or 240
GB SSD is still significant enough that for some people spec'ing a new system it's worth just moving the paging completely to a HDD. For those with existing installs such as the OP, "just buy a bigger SSD" may not be as good an option.
|
Senator Tribus: somewhere in nonpaged pool Registered: Mar 21, 2001 Posts: 20211
|
| You need to set the other page files to start at zero size (as I suggested) and only grow on demand. Their only purpose is to prevent crashing if some unexpected memory spike occurs. If that happens, then you are in trouble anyway, because your ridiculously finely tuned system isn't behaving as expected. My point is that if there's no demand, then the (small) page file should be on the SSD. If there is, then the page file should be on SSD for performance
reasons.
"You are in trouble anyway because your system isn't behaving as expected" is a mighty thin justification. If your system suddenly needs additional pagefile space, you really don't want to put more delays in the path by requiring it to extend the pagefile. Sure. In my opinion, one should just buy a bigger SSD and this whole conversation is moot. It all depends. At home, I often have commit charge near 30 GBs on a computer, just because I have set BOINC to
keep stuff in memory. If I had an SSD in that (especially if it was a small one), I probably wouldn't want to have the massive page file on it. The fluctuations in commit charge are also pretty big. However, on my laptop, which has 16 GBs of memory, commit charge hardly ever ovet 10 GBs and 4 GB page file seems to be more than enough. If the laptop had second hard drive, I probably set up another page file there, just so that if something goes wrong, it will start filling the other drive
instead of boot drive. However, during two years nothing (like that) have gone wrong, so I'm not too worried. My laptop use case simply doesn't seem to include 64 bit software that leaks memory. -JLarja If you're really "tuning" (or, rather, "using only as much disk space as you can get away with") things closely, commit charge isn't the best metric. Look at the performance counter for pagefile peak usage. It's expressed as a percentage. You want your default pagefile space to
be large enough that it doesn't get over 25%. If you want to use commit charge, then you want your default pagefile space at least 2x that figure. The reason for having lots of extra space in the pagefile is that, as with any heap, the space allocation algorithms work better with a lot of free space to work in. In the pagefile, large free areas help further by making it more likely that pagefile writes can be large, which means that reads can also be large - fewer, larger IOs are better
than more, smaller IOs (even to an SSD). The reason for using a smaller factor from the commit charge than from the actual usage %age is that while commit charge does show the maximum possible usage of the pagefile, some or even most of that won't commonly actually be in the pagefile.
|
Senator Tribus: somewhere in nonpaged pool Registered: Mar 21, 2001 Posts: 20211
|
| Seems to me that the Windows default is not a good one and tinkering with this is very sensible, The Windows default is just fine for the vast majority of machines and workloads. It may use a little more disk space than you could get away with, that's all. If you have more than one hard drive, and you don't mind putting a pagefile on one or more of the additional drives, you're outside the typical use case. Most people who have two or more
drives on their machines have specific uses in mind for those additional drives and don't want Windows to assume that they're available for pagefiles.
| Last edited by DriverGuru on Thu Apr 18, 2013 9:07 am
|
Ars Tribunus Militum
et Subscriptor Tribus: Londinium Registered: Jan 6, 2005 Posts: 1951
|
| Sure, I meant specifically in the situation under discussion (16 GB RAM and ≤ 128 GB SSD + HDD).
|
Ars Praetorian Registered: Mar 31, 2007 Posts: 404
|
| That happened to me yesterday. I was scratching my head wondering why the size of my SSD went down by 18GB. I checked the page file and windows had automatically set it to 18GB for some reason (recommended size was 5.5GB). I then moved the page file to my secondary HDD. I had a similar issue re: page file size a few months ago, as detailed in this thread. The
solution I chose was to leave the page file on the SSD, but set the min and max values to 800 MB.
|
Ars Centurion Tribus: Ähtäri, Pohjanmaa, Finland Registered: Oct 22, 2005 Posts: 207
|
| Quote: You need to set the other page files to start at zero size (as I suggested) and only grow on demand. Their only purpose is to prevent crashing if some unexpected memory spike occurs. If that happens, then you are in trouble anyway, because your ridiculously finely tuned system isn't behaving as expected. My point is that if there's no demand, then the (small) page file should be on the SSD. If there is, then the page file should be on SSD for
performance reasons. Does this work? I'll have to try this out when I've got a moment and see whether the system pages to a 10 MB C:\pagefile.sys or a 0 MB but growable E:\pagefile.sys Works for me with values 512, 8192, 8192 across three disks (HDD, SDD, SDD), but I haven't tried it with really small page file. Quote: Quote: Frankly, I don't really see much difference between 10 GBs free or 30 GBs free. Both are way too low for me to be
comfortable with. 10 GBs vs. 14 GBs or 30 GBs vs. 34 GBs are just noise. 34 GB free on a 120 GB SSD is just fine, IMO, and 30 GB free is about as low as I'd want it to go - so the space saved by not having a 4 GB C:\pagefile.sys does make a difference. Only because you assigned arbitrary sweet spot between 30 and 34 GBs. By the way, I didn't actually do any math when I picked the 30 GB mark. It may well be that real number (with 120 or 128 GB SSDs) would be 20 or 50 GBs.
My space requirement was also from one data point (my work computer) where I could probably free gigabytes of space just by removing uninstall files from three years of Windows Updates. You can always find a situation, where that 4 GBs is critical. IMO, it just isn't very likely to happen in real life, even on 120 GB SSD. Much more likely, you just run into same problem a bit later. Quote: The price jump to a 180 or 240 GB SSD is still significant enough that for some
people spec'ing a new system it's worth just moving the paging completely to a HDD. For those with existing installs such as the OP, "just buy a bigger SSD" may not be as good an option. I'd still suggest removing seldomly used programs and files before getting stressed up about page file. At that point we are far into "inconvenient and cumbersome" territory though, so maybe some hypothetical performance lost in paging doesn't matter. -JLarja
|
Ars Centurion Tribus: Ähtäri, Pohjanmaa, Finland Registered: Oct 22, 2005 Posts: 207
|
| If you're really "tuning" (or, rather, "using only as much disk space as you can get away with") things closely, commit charge isn't the best metric. Look at the performance counter for pagefile peak usage. It's expressed as a percentage. You want your default pagefile space to be large enough that it doesn't get over 25%. If you want to use commit charge, then you want your default pagefile space at least 2x that figure. The reason for having lots of extra
space in the pagefile is that, as with any heap, the space allocation algorithms work better with a lot of free space to work in. In the pagefile, large free areas help further by making it more likely that pagefile writes can be large, which means that reads can also be large - fewer, larger IOs are better than more, smaller IOs (even to an SSD). The reason for using a smaller factor from the commit charge than from the actual usage %age is that while commit charge does show the maximum
possible usage of the pagefile, some or even most of that won't commonly actually be in the pagefile. Yeah, I think the combined starting size of all page files is 50 GBs on that computer. The situation is a bit different from typical though, since most of the memory load is from processes that could be suspended for hours, if not days, at a time. BOINC is also set to suspend all running tasks when computer is in use, so I don't even see what happens on task changes. Judging from how
transparent the whole thing is, I would hazard a guess that Windows knows to page out suspended processes first, and only then touches running ones. Mostly the whole thing is just interesting experiment. I don't have any particular reason to have BOINC keep the suspended processes around. By the way, isn't maximum commit charge actually physical memory + all page files (which includes things like memory mapped files and executables at least on newer Windowses), so it can be a lot higher
than page file size, especially with small page files (like I have just 4 GB on my laptop). If you aren't typically needing most of the physical memory (e.g. it's just additional disk cache with marginal performance benefit), you won't need a large page file either. If you are making use of all of your physical memory, then you probably want large page file to back it. -JLarja
|
Ars Tribunus Militum
et Subscriptor Tribus: Londinium Registered: Jan 6, 2005 Posts: 1951
|
| By the way, isn't maximum commit charge actually physical memory + all page files (which includes things like memory mapped files and executables at least on newer Windowses), so it can be a lot higher than page file size, especially with small page files (like I have just 4 GB on my laptop). Almost. There's a small difference due to OS reservation of some RAM for itself. On the box I'm looking at right now the commit limit is 93 MB lower than RAM + pagefiles (4
GB + 704 MB).
|
Senator Tribus: somewhere in nonpaged pool Registered: Mar 21, 2001 Posts: 20211
|
| By the way, isn't maximum commit charge actually physical memory + all page files (which includes things like memory mapped files and executables at least on newer Windowses),
No. The commit limit is physical memory, minus a small amount reserved for nonpageable stuff, plus the current size of all actual pagefiles - NOT including memory mapped files (and executables, but we really don't need to say that, as executables ARE memory mapped files).
i.e. mapping to a file does not increase the system commit limit - nor the system commit charge. It IS counted against the total virtual size of the process (the Process | Virtual bytes counter in PerfMon). (So is Reserved v.a.s., for that matter.) Any accessible virtual address space has to have someplace it can be stored: RAM, the pagefile, or a mapped file. VAS that is mapped to files automatically has a backing store - the respective mapped files, so it doesn't count against the
commit limit. Private committed VAS is backed by the pagefile. The point of the commit limit is to avoid "overcommitting" the resources that can be used to hold committed memory - which is RAM + pagefile(s). Note that if you run the system total commit (which does not include mapped regions) right up to the commit limit, then all of the stuff backed by mapped files has to be pushed out of RAM to make room. (This description intentionally omits consideration of AWE,
which is only just barely used even by Microsoft.) Quote: If you aren't typically needing most of the physical memory (e.g. it's just additional disk cache with marginal performance benefit), you won't need a large page file either.
"Minimal performance benefit"? You think the difference between accessing something cached in RAM vs. reading it from disk all over again is "minimal"? And it's not just file cache. (Please stop saying "disk cache".) Unless you've
closed a big program recently, much of what you see as "available" RAM in e.g. Task Manager is on the standby page list - which is a cache for pages recently dropped from working sets. So "available" isn't necessarily not being used. It's "available" in that it can be immediately used to resolve a hard fault without having to write anything out to disk, but until then it can be used to satisfy a soft fault to the process it used to be part of. So a lot of your "available" RAM is not "not
needed", it's sort of a system-wide extension to all process's working sets. To get an idea of how much of the "not needed" RAM is actually helping, compare your total page fault rate to your page read rate... then imagine how much longer it would take to do anything if all the faults in your total fault rate were hard faults (requiring disk reads).
|
Ars Praefectus Tribus: Kenmore, WA Registered: Feb 19, 2002 Posts: 3845
|
| I don't get this obsession with giant paging files. If you have spare ram you don't need an xbox huge paging file. More ram != bigger pagefile.sys I have 16gb of ram and a 160gb SSD OS drive. I left the paging file on c:, and set it to a starting size of 100mb, and max size of 2gb. My last reboot was 4 days ago, and my paging file is currently... 100mb. Windows has not felt the need to grow it. Seems like a good solution for those with lots of RAM and SSD space at
a premium.
|
What drive should page file be on?
Pagefile in Windows 10 is a hidden system file with the . SYS extension that is stored on your computer's system drive (usually C:\). The Pagefile allows the computer to perform smoothly by reducing the workload of the physical memory, or RAM.
Should I store my files in SSD or HDD?
The HDD offers high storage capacities at a low price, while the SSD provides blazing fast access speeds at a higher cost. Used together, PC users can access their most important files quickly via the SSD, while storing media and other large files on their less expensive HDD.
Where should I put my paging file?
Assuming all drives are of about equal performance, the best place for the pagefile is: On the most-used partition of your least-used hard drive. "Least-used hard drive" because that drive will be less busy with other things. "On the most-used partition" because that's where the heads will be much of the time already.
Can I move my pagefile to another drive?
Although for the most part, the feature works automatically, if needed, you can move the paging file (pagefile. sys) to another drive to increase the overall performance, or if you work with reads and writes intensive applications, then you want to reduce the number input/output (I/O) activity on the main drive.
|
