ubuysa
The BSOD Doctor
This is going to be controversial and I know that some will not agree with me, but the logic behind what I've done makes sense and there are no negative impacts......
We all know that the paging file is part of virtual memory, RAM being the other part. Windows uses the paging file to store virtual storage pages that don't need to be in RAM. It's important to appreciate that the paging file is ALWAYS used, even if you have way more RAM than you need. Some pages are always written to the paging file, indeed apps (and system services) can request that pages are written out. This would be done for pages that are used once; those containing app initialisation code for example, once run it will never be needed again in this run of the app.
The paging file is thus always in use, even in an apparently idle system.
Because the paging file can be large, as large as installed RAM or even larger, Windows has always managed the size of the paging file so as not to waste what used to be very expensive disk storage. Even Windows 11 dynamically manages the paging file size, keeping it small when it's not being used much and dynamically expanding it when needed. The maximum and minimum sizes for the paging file in Windows 11 are:
Minimum paging file size: Varies based on page file usage history, but it's the amount of RAM ÷ 8, and cannot be more than 32 GB, unless overridden by crash dump settings. In an 8GB RAM system for example, the paging file could be as small as 1GB. On my 32GB system the minimum paging file size is 4GB.
Maximum paging file size: Is fixed at 3 × RAM or 4 GB, whichever is larger. This size is then limited to the volume size ÷ 8. However, it can grow to within 1 GB of free space on the volume if necessary for crash dump settings. In my 32GB system for example, the maximum paging file size is 96GB, as long as the drive is 8 times larger (ie. at least 768GB).
These days most of us are using system drives in the terabyte size, mine is 1TB and it's used only for Windows and installed apps. The total space in use is less that 100GB, so there is ample space to easily accommodate the maximum paging file size for my 32GB RAM without any problems at all.
When Windows has to dynamically increase or decrease the paging file size based on usage that clearly requires system resources to do. My logic is that if I have ample space on my system drive to accommodate the maximum possible paging file size then why not pre-allocate it at that size and avoid the (albeit small) overheads of dynamically changing it?
Instead of using the traditional 'system managed' paging file size I have set my paging file size manually. The maximum size I have used is the maximum 3 * 32GB of RAM which is 96GB (98304MB - the paging file size is specified in MB). The highest minimum possible size is 32GB (32768MB) and so that's what I've set.
Yes, this uses a tiny bit more of my 1TB system drive, but it will still have over 600GB of free space even with my maximal paging file size in use. I do expect this to avoid some small overhead in adjusting the paging file size and whilst that overhead was probably not noticeable it's still avoided - well mostly, if my paging file needs to be larger than 32GB then it can be extended all the way to 96GB - but I don't expect that to ever happen.
The result is that my paging file is now 32GB in size...
Even if it goes up all the way up to the allowed 96GB there will still be over 600GB of free space on that drive, so there is no downside to this as far as I can see. I'm simply making use of the SSD storage that I have available and which would otherwise be unused.
Has it made any noticeable difference you ask? Probably not. Of course, when you make changes like this the system always feels snappier afterwards, but I think that's just my expectations. TBH whilst there may be no major advantage to maxing the pagefile size on a huge system drive I see no disadvantages either, so why not?
We all know that the paging file is part of virtual memory, RAM being the other part. Windows uses the paging file to store virtual storage pages that don't need to be in RAM. It's important to appreciate that the paging file is ALWAYS used, even if you have way more RAM than you need. Some pages are always written to the paging file, indeed apps (and system services) can request that pages are written out. This would be done for pages that are used once; those containing app initialisation code for example, once run it will never be needed again in this run of the app.
The paging file is thus always in use, even in an apparently idle system.
Because the paging file can be large, as large as installed RAM or even larger, Windows has always managed the size of the paging file so as not to waste what used to be very expensive disk storage. Even Windows 11 dynamically manages the paging file size, keeping it small when it's not being used much and dynamically expanding it when needed. The maximum and minimum sizes for the paging file in Windows 11 are:
Minimum paging file size: Varies based on page file usage history, but it's the amount of RAM ÷ 8, and cannot be more than 32 GB, unless overridden by crash dump settings. In an 8GB RAM system for example, the paging file could be as small as 1GB. On my 32GB system the minimum paging file size is 4GB.
Maximum paging file size: Is fixed at 3 × RAM or 4 GB, whichever is larger. This size is then limited to the volume size ÷ 8. However, it can grow to within 1 GB of free space on the volume if necessary for crash dump settings. In my 32GB system for example, the maximum paging file size is 96GB, as long as the drive is 8 times larger (ie. at least 768GB).
These days most of us are using system drives in the terabyte size, mine is 1TB and it's used only for Windows and installed apps. The total space in use is less that 100GB, so there is ample space to easily accommodate the maximum paging file size for my 32GB RAM without any problems at all.
When Windows has to dynamically increase or decrease the paging file size based on usage that clearly requires system resources to do. My logic is that if I have ample space on my system drive to accommodate the maximum possible paging file size then why not pre-allocate it at that size and avoid the (albeit small) overheads of dynamically changing it?
Instead of using the traditional 'system managed' paging file size I have set my paging file size manually. The maximum size I have used is the maximum 3 * 32GB of RAM which is 96GB (98304MB - the paging file size is specified in MB). The highest minimum possible size is 32GB (32768MB) and so that's what I've set.
Yes, this uses a tiny bit more of my 1TB system drive, but it will still have over 600GB of free space even with my maximal paging file size in use. I do expect this to avoid some small overhead in adjusting the paging file size and whilst that overhead was probably not noticeable it's still avoided - well mostly, if my paging file needs to be larger than 32GB then it can be extended all the way to 96GB - but I don't expect that to ever happen.
The result is that my paging file is now 32GB in size...
Rich (BB code):
C:\>dir /ah
Volume in drive C has no label.
Volume Serial Number is 369A-7F09
Directory of C:\
26/04/2024 15:43 <DIR> $Recycle.Bin
22/04/2024 21:29 <JUNCTION> Documents and Settings [C:\Users]
26/04/2024 15:44 <DIR> OneDriveTemp
25/10/2024 11:11 34,359,738,368 pagefile.sys
19/10/2024 15:13 <DIR> ProgramData
18/10/2024 08:28 <DIR> Recovery
25/10/2024 11:11 16,777,216 swapfile.sys
24/10/2024 23:14 <DIR> System Volume Information
3 File(s) 34,376,527,872 bytes
7 Dir(s) 787,780,861,952 bytes freeHas it made any noticeable difference you ask? Probably not. Of course, when you make changes like this the system always feels snappier afterwards, but I think that's just my expectations. TBH whilst there may be no major advantage to maxing the pagefile size on a huge system drive I see no disadvantages either, so why not?
