Windows pagefile size with large RAM and SSD
I have 32GB of system RAM and a 256GB SSD, so I wondered the same thing. It does seems safe to change this, since even the dialog itself, at System Properties | Performance Options | Virtual Memory indicates:
Total paging file size for all drives
- Minimum allowed: 16 mb
- Recommended: 7,676 mb
- Currently allocated: 32,768 MB
When defaulted to "system managed size", it was at the maximum of 32768 equivalent to memory size.
I changed it to the "recommended" value so it is now set to range between 7676 - 32768 instead of fixed at 32768:
I'll have to reboot and see if this helps. Edit: rebooted, confirmed, pagefile is now 7GB instead of 32GB. Success!
Since the "why have a paging file at all with that much memory" argument always comes up, it is advisable to have some page file, for the reasons that Mark Russinovich outlines:
Perhaps one of the most commonly asked questions related to virtual memory is, how big should I make the paging file? There’s no end of ridiculous advice out on the web and in the newsstand magazines that cover Windows, and even Microsoft has published misleading recommendations. ...
Some feel having no paging file results in better performance, but in general, having a paging file means Windows can write pages on the modified list ... out to the paging file, thus making that memory available for more useful purposes (processes or file cache). So while there may be some workloads that perform better with no paging file, in general having one will mean more usable memory being available to the system (never mind that Windows won’t be able to write kernel crash dumps without a paging file sized large enough to hold them).
That is why I advocate the recommended paging file size, or at least ½ the recommended size if you are absolutely, positively sure the peak commit charge (max real world memory usage) of the apps you typically use fits in the memory you have. Read the section titled How Big Should I Make the Paging File? in that article for more, it is the definitive statement on the matter. If you'd like to read even more, try this excellent Server Fault question.
The best advice for setting the Paging File size (of course) comes from Mark Russinovich. On his site he describes how to use his excellent tool SysInternals Process Explorer to determine the optimal Paging File size for your machine:
"So how do you know how much commit charge your workloads require? You might have noticed in the screenshots that Windows tracks that number and Process Explorer shows it: Peak Commit Charge. 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."
Source: http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx
I have been using this method for years.
Probably you have the initial size of the swap file quite high, Windows tends to use a high value by default because if offers better performance. Put the initial size to a small size (in your case I suppose that "small" are 1 or 2 GB) and maintain the maximum value in 24 GB. (If you note that Windows always grows the file over the initial size you should use a higher value).
The trick here is changing the initial value, not the maximum value. If Windows grows the swap file is because it needs that memory.