Windows 7 Thread, Win 7 and SSD in Technical; I run without it or I put it on a HDD. Never ever ever ever ever put it on a ...
2nd November 2011, 01:08 PM #16
I run without it or I put it on a HDD. Never ever ever ever ever put it on a SSD, unless you enjoy buying new ones every couple of years.
2nd November 2011, 07:14 PM #17
The SSD is absolutely the best location for the page file. There really is no need to worry about writes either.
Originally Posted by SYNACK
Regarding its size, please read the following article by Mark Russinovich. The text below is just a small excerpt (it goes into a lot more detail)... 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 favourable performance characteristics SSDs have on those patterns, there are few files better than the pagefile to place on an SSD. (Source
How Big Should I Make the Paging File?
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. Almost all the suggestions are based on multiplying RAM size by some factor, with common values being 1.2, 1.5 and 2. Now that you understand the role that the paging file plays in defining a system’s commit limit and how processes contribute to the commit charge, you’re well positioned to see how useless such formulas truly are.
Since the commit limit sets an upper bound on how much private and pagefile-backed virtual memory can be allocated concurrently by running processes, the only way to reasonably size the paging file is to know the maximum total commit charge for the programs you like to have running at the same time. If the commit limit is smaller than that number, your programs won’t be able to allocate the virtual memory they want and will fail to run properly.
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
The page file should be left ENABLED. You do not want to disable it completely. Please read the article above for a technical explanation (or click here for a shorter version).
Originally Posted by MK-2
Last edited by Arthur; 2nd November 2011 at 07:23 PM.
2nd November 2011, 07:15 PM #18
Originally Posted by j17sparky
2nd November 2011, 07:28 PM #19
TBH i've always just moved the pagefile to an HDD rather then SSD purely for space.
By mac_shinobi in forum Hardware
Last Post: 4th June 2011, 08:30 PM
By DaveP in forum Windows 7
Last Post: 21st August 2009, 03:22 PM
By mbedford in forum Windows 7
Last Post: 10th August 2009, 08:39 AM
By SYNACK in forum Jokes/Interweb Things
Last Post: 1st July 2009, 06:33 AM
By Pottsey in forum Windows
Last Post: 30th January 2007, 10:27 PM
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)