• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

SSD for the pagefile?

Yes, the latencies will be lower with SSDs, but does lower latencies justify a more expensive product with less throughput and less storage space, I’m not sure.

It's low latencies is all SSDs have going for it ATM, we can not even factor in noise as most disk drives are almost silent these days.

SSDs have its benefits for small niche reasons, like doing graphic design and video editing on a professional level as part of a job, but value for money it isn’t there yet. RAID will never be mainstream until they can compete with disk drives for storage at similar prices.

Dont forget how cool they run mine dont even get warm.

Just put the pagefile on a normal HDD and see if it shows the system down any did not really bother me but found that i only needed it on for Titan Quest so it stays disabled now.
 
I just thought about it but... how about a small RAMdrive for pagefile? xD especially for tripple channel users that rarely use more than 3-4gb :)

you could always put a 128mb pagefile on a RAMdrive, since that would not affect performance for RAM or almost not and accelerate pagefile alot

erm????

pagefile = ram data stored temporarly in a nother location......

what you susgests he does is shoot himself in the foot? your going to lower the total amount of avalible ram to the system and create a ramdrive out of that so the system can copy ram to ram?
 
Well, on my system, whatever i start, boom it starts the very same instance.
 
I just thought about it but... how about a small RAMdrive for pagefile? xD especially for tripple channel users that rarely use more than 3-4gb :)

you could always put a 128mb pagefile on a RAMdrive, since that would not affect performance for RAM or almost not and accelerate pagefile alot

+1 for a clever idea... sounds cheaper than buying another drive for a pf...
 
why are you guys supporting putting a pagefile on an SSD?! and 2GB? WTF?

ALLOW me to EDUCATE

* Introduction :

For those who don't know, here are the links on how SSDs work, why they've got only limited number of write / erase cycles, and why MLC SSDs have a very short life-span as compared to SLC SSDs. The entire article is in itself quite informative, and you should read it if you've the time to do so.

So now you know that every write / erase means the clock of doom is ticking closer to zero hour for your SSD. The clock ticks ten times faster if you've got a MLC SSD which is what is relatively common. So to protect the data and money you've invested in your SSDs, you definitely need to make them last longer.

But you've got lots of things in Windows, that are an indispensable part of the OS, that keep writing or erasing data a huge number of times without your knowledge. Most of these can be avoided or at least made to operate in such a way that they don't harm your SSDs, and now we'll look at them:

1. Defragmentation software :

Defragmentation software consolidates files by moving all the fragments of a file to one place i.e., to adjacent sectors in a HDD, or adjacent cells in a SSD. In this process, it erases data from some cells and writes them into other cells. Keep doing it daily or even weekly, you're going to end up exceeding the write / erase cycles too quickly for your liking.

And for SSDs, defragmenting is totally unnecessary. You see, in HDDs, the seek head has to move over various sectors and hence it has a read time in the order of miliseconds. So it'd help reduce this seek time noticeably by defragmentation when you place all parts of the file sequentially in order to eliminate the necessity of searching through the entire platter.

But with SSDs, there are no moving parts and the SSD already knows in which cell each part of the file is written and so seek time is thousands of times still less; it's in microseconds, and so however heavily a file is fragmented, the SSD knows exactly where every fragment is, and any amount of fragmentation is not going to affect the seek time of SSDs and hence read time for that file.

So remember to disable defragmentation of any SSD volume that you might be having.

2. Logs and disk clean up utilities :

Logs are another problem because data is being constantly written to the SSD's cells. If you're going to use some disk clean up utility, it'll simply delete the data in those cells. So those cells would have been made to undergo one write / erase cycle everytime the utility cleans up your SSD. And contnuation of the log will be written to other cells (because of wear-levelling) and they will also be made to undergo similar such unnecessary write / erase cycles.

So the best thing is to do is not maintain logs, but if you do need them, like temperature logs for CPU, GPU, etc.. then see if you can change the directory of where a log file is being written. If you can change it, then ensure that the directory does not point to a SSD volume. But most of the logs are maintained by Windows and can't be relocated and so the best thing to do will be to let them be as such and use the clean up utility a lot less frequently.

3. Internet Explorer browser cache and default downloads folder :

The content of every website visited is written to a small browser cache. Within that cache itself, data gets written and rewritten many times. Add to that the number of times you delete that internet cache (or some disk clean utility does it for you) and you end up with a very large number of write / erase cycles.

So you can change the directory of the browser cache and ensure that this directory does not point to a SSD volume. So now, the temporary internet files no longer get written into your SSD. You should also change the default directory where the files you download are saved to, when using download managers, and let the new directory not be on a SSD volume.

4. Instant messaging :

Whenever you send Instant mesages or have PC to PC voice chats, the typed messages, or spoken sound files are written as very small files to the SSD before being sent to the other person (it's in a folder which is either the installation folder of the IM software or located in Application Data or Local settings) and then they are deleted after the chat.

Again, these write / erase wears SSD cells. Try installing the program in a mechanical HDD instead of SSD if the IM files are saved to the installation folder. If it's otherwise and the files are written inside Application data or Local settings, only the program creator should alter the program to suit SSDs. Additionally, if you've read through the entire article I've linked this post to, you'll find writing of very small packets of data into most MLC SSDs by itself causes problems.

5. Page file :

Page file or virtual memory is a portion of the HDD, or a particular number of cells of a SSD that's used as if it were RAM. Now data gets written, erased and rewritten into the page file a staggering number of times every minute. And this data is the page file constantly changes with the dynamism of the data in the RAM. So your SSD will hardly last a year if it has got the page file in it.

And wear levelling algorithms will constantly change the cells that act as page file and so you'll end up with all of the cells of the SSD worn out completely in the blink of an eye. So the best option is to add 2 GB more of RAM and then disable your page file altogether. This simple step will dramatically prolong the life of your SSDs, even if you have the operating system in it.

Or if you're very particular about having a page file, you can change the drive where the paging file is, and have it on a mechanical drive instead, but beware; applications will suffer lags because the mechanical drive involved is not as fast as the SSD and hence the benefits of a SSD will not be fully realized as it is made dependent on a mechanical drive.


6. Registry :

Now coming to the second biggest, but the most incurable problem of all: the Windows registry. It grows constantly everytime you install programs or even simply use Windows, and data entries are also constantly being deleted from the registry. The rate at which registry entries are written / erased is in itself enough to wear out SSDs within a few years. Add to that the fact these are written in very small packets, and that disk caching will not be of much use here.

This is most bugging because there is nothing you can do to translocate the registry to another directory. So this can be resolved only if Microsoft decides to create upcoming versions of Windows optimized for SSDs with registry whose location is left to our choice at the time of installation of the OS. Until then there's nothing we users can do. Perhaps the statement "if SSDs suck, blame Windows and not SSDs" has a lot more veracity in it after all.

7. Intelligent disk management :

The simplest way of all; just don't move files from one partition to another or install or uninstall, or create or delete files and folders unless absolutely necessary.

SSDs are simply great with marvellous read and write speeds, lightning quick access times, great durability and with enormous endurance wherein they can last almost infinitely when you just keep reading files from it.

But when it comes to writing files and erasing them many times over as in normal usage, the real Achilles' heel of the SSDs are exposed and that's where the trouble begins with them. This happens to be the sole aspect in which HDDs beat them.

Source
 
Last edited:
Thanks Solaris, some very important and useful info there.

So we've seen disabling the pagefile causes problems (Thrackan; post #89)
This is where n-ster's idea deserves some merit; If you've got, say, 8 GB of RAM (or hat's 5GB) and you know your pagefile's not being used, could you stick it on an 128MB RAMdisk?
The benefits would be:
Don't have to work/defrag round a pagefile
If you don't have your pf on your OS drive (like me) you free up a drive
Hopefully won't have the problems exprienced with a disabled pagefile


Maybe some could test the theory?
 
Thanks Solaris, some very important and useful info there.

So we've seen disabling the pagefile causes problems (Thrackan; post #89)
This is where n-ster's idea deserves some merit; If you've got, say, 8 GB of RAM (or hat's 5GB) and you know your pagefile's not being used, could you stick it on an 128MB RAMdisk?
The benefits would be:
Don't have to work/defrag round a pagefile
If you don't have your pf on your OS drive (like me) you free up a drive
Hopefully won't have the problems exprienced with a disabled pagefile


Maybe some could test the theory?

idk if that would work. because a ramdisk unless a physical standalone unit is simply like a virtual drive. granted it will use the ram. but like a virtual machine the ramdisk file will be on the SDD and will be saved too periodicly. The best thing to do imo is switch the pagefile to a seperate drive. and run it as low as possible (windows says 200mb) that will force more ram to be used when virtual memory runs low. but also not wear out the SDD.
 
You don't even need a pagefile. I haven't run into an issue yet where I do need it as I never even come close to maxing out my RAM.
 
Stuff uses the pagefile anyway, whether it's there or not. Things still get paged..
 
Stuff uses the pagefile anyway, whether it's there or not. Things still get paged..

But whole whole point of the pagefile is to throw stuff your RAM can't fit onto your drive, why would something default itself to the pagefile and not the RAM first?(considering you have enough RAM)

That's one thing i dont get.
 
edit - never mind - was thinking of ramdisk not ssd
 
Last edited by a moderator:
Further more if you want to save wear and tear you could always tell the OS to put user and account temp files browser cache files on another HDD. And i my self don't see any performance hit due to the fact of how little this request is.

As for IM programs i just put it on a HDD why does it need to load fast anyways although you might notice a little hit i guess if it was auto starting but not seen one yet.

In the end there is a balance that can be gained for your requirements.
 
Stuff uses the pagefile anyway, whether it's there or not. Things still get paged..

Things get paged to physical RAM, the pagefile is not needed if there is sufficient RAM. I've had zero issues. Nada.
 
Things get paged to physical RAM, the pagefile is not needed if there is sufficient RAM. I've had zero issues. Nada.

me either. just play safe over 4 disable it. if NEVER had a problem even rendering
 
Things get paged to physical RAM, the pagefile is not needed if there is sufficient RAM. I've had zero issues. Nada.

i've tried cutting back on my pagefile several times. if you are careful not to run lots of background tasks (terminate stay resident - as they used to be called in dos) and not have multiple open windows, you can get away with it. But without fail, I always open one too many apps and my system first slows down to a crawl and then hangs.

So finally I just resigned myself to having an 8gig page file (equal to amount of RAM) on my SSD. I still manage to bump up against the limit from time to time, but it requires some effort now.
 
i've tried cutting back on my pagefile several times. if you are careful not to run lots of background tasks (terminate stay resident - as they used to be called in dos) and not have multiple open windows, you can get away with it. But without fail, I always open one too many apps and my system first slows down to a crawl and then hangs.

So finally I just resigned myself to having an 8gig page file (equal to amount of RAM) on my SSD. I still manage to bump up against the limit from time to time, but it requires some effort now.


thats going to destroy your SSD
 
thats going to destroy your SSD

Thanks Solaris. I read your post and bookmarked the link. I figured that the SSD was perishable commodity anyway but I've been having problems with both systems that have an ssd slowing down. Maybe it was the load leveling and all of the other stuff that goes on under the sheets. IDK. But I've moved the page file to the 2 internal hdd's and I'll see how that goes.

Personally, I would sacrifice the SSD for better response times but it seems to be getting me just the opposite so we'll see how the new configuration works out. I put 5gig of pagefile space on each drive hoping that it will use both of them. I think it fills one first and then the other but I'm pretty sure that I go over 5gig in normal use.
 
Thanks Solaris. I read your post and bookmarked the link. I figured that the SSD was perishable commodity anyway but I've been having problems with both systems that have an ssd slowing down. Maybe it was the load leveling and all of the other stuff that goes on under the sheets. IDK. But I've moved the page file to the 2 internal hdd's and I'll see how that goes.

Personally, I would sacrifice the SSD for better response times but it seems to be getting me just the opposite so we'll see how the new configuration works out. I put 5gig of pagefile space on each drive hoping that it will use both of them. I think it fills one first and then the other but I'm pretty sure that I go over 5gig in normal use.

seems legit remember to clear /remove the page file fro the SSD and reboot to get your space back
 
It won't be useful. Put the entire OS on it, and then alter key directory paths (such as Documents, Music) to other drives, install programs on other drives.
 
I already use a small RAMdisk for windows/IE temp files.

I guess I'll just keep a pagefile on my velociraptor then..
 
5. Page file :

Page file or virtual memory is a portion of the HDD, or a particular number of cells of a SSD that's used as if it were RAM. Now data gets written, erased and rewritten into the page file a staggering number of times every minute. And this data is the page file constantly changes with the dynamism of the data in the RAM. So your SSD will hardly last a year if it has got the page file in it.

And wear levelling algorithms will constantly change the cells that act as page file and so you'll end up with all of the cells of the SSD worn out completely in the blink of an eye. So the best option is to add 2 GB more of RAM and then disable your page file altogether. This simple step will dramatically prolong the life of your SSDs, even if you have the operating system in it.

Or if you're very particular about having a page file, you can change the drive where the paging file is, and have it on a mechanical drive instead, but beware; applications will suffer lags because the mechanical drive involved is not as fast as the SSD and hence the benefits of a SSD will not be fully realized as it is made dependent on a mechanical drive.
Jesus christ. Not again. (double facepalm)
If you have enough RAM, pagefile is barely being used - but that said, you still DO need it. People should really learn what it does and how it works. Yeah it *usually* works, but you CAN run into problems. I tried myself, and even with small (256MB) pagefile I did get various error messages about being low on memory and stuff. That's simply how it works. See here:
http://en.wikipedia.org/wiki/Virtual_memory
http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx
http://blogs.technet.com/b/markrussinovich/archive/2008/07/21/3092070.aspx
Saying that pagefile will ruin the SSD in a blink of an eye is simply ridiculous.
and suggesting stuff like disabling it and even creating a RAMdisk for it is too. There are numerous articles about this.

Simply think of the above: if it was true, there would already be an army of people yelling that their SSDs wore out in a month or something from regular use. It is not so!

I agree with redirecting browser cache and possibly temp as well, but the rest of the stuff doesn't make any sense at all.
 
Jesus christ. Not again. (double facepalm)
If you have enough RAM, pagefile is barely being used - but that said, you still DO need a pagefile. People should really learn what it does and how it works.
Saying that pagefile will ruin the SSD in a blink of an eye is simply ridiculous.
and suggesting stuff like disabling it and even creating a RAMdisk for it is too. There are numerous articles about this.

Simply think of the above: if it was true, there would already be an army of people yelling that their SSDs wore out in a month or something from regular use. It is not so!

I agree with redirecting browser cache and possibly temp as well, but the rest of the stuff doesn't make any sense at all.


BS it has been proven before that the system will use the page file for ANYTHING cache related with ANY program before it uses the ram. The system does this on purpose to make sure their is sufficent ram to run the applications processes. that is why when disabling/shrinking the pagefile more ram is used (depending on what is cached*) and also why it is reccomended to have 4+GB.
 
Link with proof please.
Are you talking about XP? That would make some sense, because it doesn't manage memory all that well. On Windows 7 - don't touch it! (much)
 
http://blogs.msdn.com/b/e7/archive/2009/05/05/support-and-q-a-for-solid-state-drives-and.aspx

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 favorable performance characteristics SSDs have on those patterns, there are few files better than the pagefile to place on an SSD.


----

Performance Degradation Over Time, Wear, and Trim

As mentioned above, flash blocks and cells need to be erased before new bytes can be written to them. As a result, newly purchased devices (with all flash blocks pre-erased) can perform notably better at purchase time than after considerable use. While we’ve observed this performance degradation ourselves, we do not consider this to be a show stopper. In fact, except via benchmarking measurements, we don’t expect users to notice the drop during normal use.

Of course, device manufactures and Microsoft want to maintain superior performance characteristics as best we can. One can easily imagine the better SSD manufacturers attempting to overcome the aging issues by pre-erasing blocks so the performance penalty is largely unrealized during normal use, or by maintaining a large enough spare area to store short bursts of writes. SSD drives designed for the enterprise may have as high as 50% of their space reserved in order to provide lengthy periods of high sustained write performance.

In addition to the above, Microsoft and SSD manufacturers are adopting the Trim operation. In Windows 7, if an SSD reports it supports the Trim attribute of the ATA protocol’s Data Set Management command, the NTFS file system will request the ATA driver to issue the new operation to the device when files are deleted and it is safe to erase the SSD pages backing the files. With this information, an SSD can plan to erase the relevant blocks opportunistically (and lazily) in the hope that subsequent writes will not require a blocking erase operation since erased pages are available for reuse.

As an added benefit, the Trim operation can help SSDs reduce wear by eliminating the need for many merge operations to occur. As an example, consider a single 128 KB SSD block that contained a 128 KB file. If the file is deleted and a Trim operation is requested, then the SSD can avoid having to mix bytes from the SSD block with any other bytes that are subsequently written to that block. This reduces wear.

Windows 7 requests the Trim operation for more than just file delete operations. The Trim operation is fully integrated with partition- and volume-level commands like Format and Delete, with file system commands relating to truncate and compression, and with the System Restore (aka Volume Snapshot) feature.

Windows 7 Optimizations and Default Behavior Summary


As noted above, all of today’s SSDs have considerable work to do when presented with disk writes and disk flushes. Windows 7 tends to perform well on today’s SSDs, in part, because we made many engineering changes to reduce the frequency of writes and flushes. This benefits traditional HDDs as well, but is particularly helpful on today’s SSDs.

Windows 7 will disable disk defragmentation on SSD system drives. Because SSDs perform extremely well on random read operations, defragmenting files isn’t helpful enough to warrant the added disk writing defragmentation produces. The FAQ section below has some additional details.

Be default, Windows 7 will disable Superfetch, ReadyBoost, as well as boot and application launch prefetching on SSDs with good random read, random write and flush performance. These technologies were all designed to improve performance on traditional HDDs, where random read performance could easily be a major bottleneck. See the FAQ section for more details.

Since SSDs tend to perform at their best when the operating system’s partitions are created with the SSD’s alignment needs in mind, all of the partition-creating tools in Windows 7 place newly created partitions with the appropriate alignment.
 
Back
Top