Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
Discussions Rules and Guidelines
Report this post
select fastest drive, and set to 8-32g or the most you would use
other drives, set to no page file
and reboot
https://www.lifewire.com/increase-virtual-memory-in-windows-10-4777163
C Drive
8192 MIN
24576 MAX
If pagefile.sys is a given size, there's probably a reason for it (presuming you didn't have a memory leak once upon a time during your current session). Either you set it that large, or it is set to handle itself and it grew that large because it needed close to that once upon a time.
We can only guess the reason because there's no information provided. How much RAM do you have? What is you current commit charge? What was the greatest commit charge for the current session (meaning since the last restart)? When was the last time the session was reset (via a restart, not a shutdown)? Does that impacted its size? These are things that may answer why your page file is a particular size.
At the end of the day, you might benefit from more RAM, more storage, or even both, depending on answers to the above. Or maybe you don't need more of either and you're fixating on something that isn't even a problem. And telling Windows to disallow your page file to get as big as the memory load you're trying to do may need could just be counteractive and make things worse.
Unless you know the maximum commit charge you'll need, I wouldn't plug in anyone else's magic values here. This is not something anyone can know because it depends not on the installed RAM amount, but it depends on the commit charge of the user in question. And if you know your own commit charge, you can formulate your own values instead. Or just let system managed handle it since it dynamically does this according to the commit charge of the system. It starts with a very conservative size and should only increase it if your commit charge warrants it, so in theory, it won't waste space if it doesn't need to, and if it is large, it likely needs (or once upon a time during the current session, formerly needed) it.
Do note that the file is going to represent the reserved space based on the current commit limit minus RAM amount. It doesn't necessarily mean it's 50 GB of actual data (it's almost surely less, because it if was containing 50 GB of actual data, it'd have already grown itself to be larger ahead of time in case it needed to allocate more actual data later). And if it is close to 50 GB of data, or ever was during that session, then there's a good chance that force reducing it is the last thing you may want to do.
Well there is no reason it should be taking up 50GB
What I would suggest is to disabled the "shut down equals hybrid hibernate" behavior Windows defaults to because if the OP hasn't and is always shutting down but never restarting, they're basically carrying on one long kernel session, and one occurrence gone awry could persist.
Or if they don't want to change that, simply restart and see if the size changes after that.
As a last ditch method, I'd disable the page file, restart, and then set it back to system managed. What that will accomplish is it will force reset it to the initial size (which with 16 GB installed, should be small [few GB or so], and only become larger if need be) but it will still be able to grow if it was needing to. Then, observe the commit charge, commit limit, and pagefile.sys size over time (last one is a hidden system file for a reason though and I'd forget observing it directly) and see what happens. If it doesn't grow large again, issue resolved and you didn't make any limiting changes, and if it does grow that large, then you know you need it.
Are you getting low memory or Wow64 warnings in Event Viewer? That suggests a memory leak somewhere. If your memory use is OK (under 80%), you can consider to reduce the size but I would never disable the pagefile. There are plenty of guides online to do it. Let the system manage it rather than setting an amt. manually.
The one can cause the other, but not all low memory conditions arise because of a leak.
A lot of things people might think is a leak might not be too. They presume some high amount must be a leak. When memory gets allocated but not deallocated is when there is a leak.
I would not consider reducing the size of the page file because you gain nothing from it. Why put a quota on a resource you paid for?
i didnt remember i once put it to 49000 or smth :D
Ive had mine set to 8192 Min/Max for quite some time now, never once had an issue, so thats also something to consider.
It is not. There is no "sweet spot" for a given RAM capacity because the needs of the page file are according to your memory load, not your installed RAM capacity. Read that again. And then again.
I wish people would grasp this already and stop recommending completely random values to people when they have no idea if it said value will be sufficient or too much for the person they are recommending it to.
If there's a sweet spot, it's system managed, because it tracks your commit charge and adjusts your commit limit accordingly in real time.
Bottom line though is there is no true sweet spot for the PageFile settings. This is generally why MS has it defaulted to Auto and picks min and max amounts based around installed RAM. But again that's not always best and neither is trying to suggest a certain Min and Max to someone. Only reason I do that is as a suggestion cause in the end you yourself can pick whatever you want.
Please do yourself a favor and open your Task Manager, regardless of what you're doing. Look at the "in use" memory value. Now look at the "committed" value (the first one) as that is your current commit charge. Now subtract the former from the latter. If that disparity is ever over 1 GB, then a 1 GB page file recommendation would be insufficient if you were using all of your RAM (this is admittedly assuming the current disparity either remains or scales up, but it typically does). In that case, you would be prevented from using all of your RAM (and you might even face crashes or data loss), simply because of an insufficiently configured setting that is acting as a quota.
I don't know about you, but the disparity for me is almost always over 1 GB on a fresh Windows boot just at idle, and it tends to grow as I do more. Sometimes a lot more.
I know old habits die hard, and I know random internet techs like to think they know better than Microsoft does, but memory management is a complicated thing, and Microsoft and the developers of this stuff, with an endless amount of data and use cases to draw upon, really do know more than most of us here. Both Microsoft[learn.microsoft.com] and Mark Russinovich[learn.microsoft.com] are pretty clear on their recommendations here. That recommendation is that the need of the page file can't be generalized and depends on the memory load in question, and ultimately what they boil it down to is that it should be able to contain the greatest the commit charge will ever become. That's it. If it can do that, then it is sufficient. If it can't, then it is not. They never give any magical XX GB values if you have YY GB of RAM, and for good reason. Because it depends on your commit charge, not simply your installed RAM capacity.
System managed adjusts the commit limit in response to the commit charge, so it's often the best "set it and forget" option. I'd change it away from this only if you have problems with it (and most people won't, and in the uncommon cases there are issues, often the problem is needing to raise the initial size, not limiting the maximum size). Windows 10/11 also do a much different job at this than Windows XP, or Windows 7, or even early era Windows 10 did. Clinging to old habits that might have been placebo isn't always the best way to default on things. I'm saying all of this as someone who used to think like that on this same subject. It took finding out the hard way for me.