Getting a new build here and will have an ssd and normal hdd. should i disable the page file on the ssd and have it left on the normal hdd what are peoples thoughts on it or is it really just personally preference and will it make any diference. i have been told leaving the paging file on ssd reduces its life span any truth in this??
SSD Drive
- Thread starter TiDDEH
- Start date
Associate
- Joined
- 24 Jul 2009
- Posts
- 2,365
- Location
- -
Move pagefile to normal HDD it will save space
So by the looks of things, only do it if you literally NEED the space
Man of Honour
- Joined
- 17 Oct 2007
- Posts
- 3,871
It's genuinely better to have a paging file because it does mean more physical memory is available to the system. Whether that makes a considerable difference or not is up for debate I guess. It is also important to recognise that a paging file doesn't have such a dramatic impact on performance as some people may initially think, due to the way in which Windows manages physical memory.
The role of the paging is so the system can write pages on the modified page list out to the paging file so that memory can then be used for more useful purposes. The modified page list represents pages which have been taking out of a process working set because they aren't being accessed actively but have not yet been saved to disk.
Once pages have been written out to the paging file, they aren't erased from memory. They are moved to the standby page list where they can be soft page faulted back into the original process working set if necessary. It's only when the memory manager needs that memory for something else will it overwrite it. If the original process needs those pages again, it will then have to read it back into memory and therefore causing hard page faults.
The advantage of operating systems such as Windows Vista and Windows 7 is due to a feature called SuperFetch. Also, where as there was only one standby page list in Windows XP, as of Windows Vista, there are eight. So, in Windows XP, the first page to be put on the standby page list would be the first page to be removed. Where as in Windows Vista and later, each page is assigned a priority and placed onto the corresponding standby page list. This results in the most important pages less likely to be erased from memory.
Sizing the paging file should be based on the amount of system committed virtual memory your workload requires in relation to the amount of physical memory which is installed in the machine. The paging file has an impact on something called the system commit limit. This represents the maximum amount of committed virtual memory, which must be backed by physical memory or stored in the paging file, processes can allocate at any one time. The limit is therefore the sum of (most of) physical memory plus the size of the paging file(s). The commit limit needs to be large enough to accommodate your workloads system committed virtual memory requirements. If it isn't, your processes will be unable to allocate the virtual memory they want and will fail to run correctly.
The best way to monitor how much system commit your workload requires is by using Process Explorer. If you open the 'System Information' window of process explorer and select the memory tab, take a look at the 'Commit Charge (K)' section.
To determine how large the paging file needs to be on your own system, once you have attained your maximum workload, take note of the 'Peak' commit charge. The difference between that value and the amount of physical memory of the machine is the size of the paging file which you will need to support your workload.
For instance, if your machine has 4GB of physical memory and your workload requires 6GB of system commit, you would need a paging file of at least 2GB to support it. This should be the bare minimum for the initial size of the paging file. You would want to add extra onto that value to give yourself some breathing room. If you are interested in crash dumps, make sure it's large enough to accommodate them as well.
You could then set the maximum size to double that value. Some people would suggest setting the initial and maximum size to the same value to prevent the paging file from changing in size. The paging file will only grow when the current commit charge reaches the initial system commit limit. It will grow right up and till it has hit it's maximum size, assuming there is a demand for it. If the paging file expanding and contracting is something that concerns you, as long as the initial allocation is sufficient, the paging file will never need to grow and simply serves as a safety net.
If you have enough physical memory to support your workloads system committed virtual memory requirements, you don't need a paging file and Windows will run absolutely fine without one under that workload. For example, your machine has 4GB of physical memory and your workload requires 2.5GB of system commit. However, there are a couple of disadvantages with running with no paging file. Firstly, there will be less memory available to you, and secondly, the system won't be able to generate crash dumps.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
A few sources of information which people maybe interested in.
Videos:
Papers:
The role of the paging is so the system can write pages on the modified page list out to the paging file so that memory can then be used for more useful purposes. The modified page list represents pages which have been taking out of a process working set because they aren't being accessed actively but have not yet been saved to disk.
Once pages have been written out to the paging file, they aren't erased from memory. They are moved to the standby page list where they can be soft page faulted back into the original process working set if necessary. It's only when the memory manager needs that memory for something else will it overwrite it. If the original process needs those pages again, it will then have to read it back into memory and therefore causing hard page faults.
The advantage of operating systems such as Windows Vista and Windows 7 is due to a feature called SuperFetch. Also, where as there was only one standby page list in Windows XP, as of Windows Vista, there are eight. So, in Windows XP, the first page to be put on the standby page list would be the first page to be removed. Where as in Windows Vista and later, each page is assigned a priority and placed onto the corresponding standby page list. This results in the most important pages less likely to be erased from memory.
Sizing the paging file should be based on the amount of system committed virtual memory your workload requires in relation to the amount of physical memory which is installed in the machine. The paging file has an impact on something called the system commit limit. This represents the maximum amount of committed virtual memory, which must be backed by physical memory or stored in the paging file, processes can allocate at any one time. The limit is therefore the sum of (most of) physical memory plus the size of the paging file(s). The commit limit needs to be large enough to accommodate your workloads system committed virtual memory requirements. If it isn't, your processes will be unable to allocate the virtual memory they want and will fail to run correctly.
The best way to monitor how much system commit your workload requires is by using Process Explorer. If you open the 'System Information' window of process explorer and select the memory tab, take a look at the 'Commit Charge (K)' section.
To determine how large the paging file needs to be on your own system, once you have attained your maximum workload, take note of the 'Peak' commit charge. The difference between that value and the amount of physical memory of the machine is the size of the paging file which you will need to support your workload.
For instance, if your machine has 4GB of physical memory and your workload requires 6GB of system commit, you would need a paging file of at least 2GB to support it. This should be the bare minimum for the initial size of the paging file. You would want to add extra onto that value to give yourself some breathing room. If you are interested in crash dumps, make sure it's large enough to accommodate them as well.
You could then set the maximum size to double that value. Some people would suggest setting the initial and maximum size to the same value to prevent the paging file from changing in size. The paging file will only grow when the current commit charge reaches the initial system commit limit. It will grow right up and till it has hit it's maximum size, assuming there is a demand for it. If the paging file expanding and contracting is something that concerns you, as long as the initial allocation is sufficient, the paging file will never need to grow and simply serves as a safety net.
If you have enough physical memory to support your workloads system committed virtual memory requirements, you don't need a paging file and Windows will run absolutely fine without one under that workload. For example, your machine has 4GB of physical memory and your workload requires 2.5GB of system commit. However, there are a couple of disadvantages with running with no paging file. Firstly, there will be less memory available to you, and secondly, the system won't be able to generate crash dumps.
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
A few sources of information which people maybe interested in.
Videos:
Papers:
Last edited: