Page file?

[Deleted809848User]

So I have 4GB ram total. Should I let windows manage page file or should I set it manually? If so what should I set the Min and max too? (Below is my ram information)

 

 

Module Name OCZ XTC Platinum OCZ3P1333LV2G

Serial Number None

Module Size 2 GB (2 ranks, 8 banks)

Module Type Unbuffered DIMM

Memory Type DDR3 SDRAM

Memory Speed DDR3-1066 (533 MHz)

Module Width 64 bit

Error Detection Method None

 

Memory Timings

@ 533 MHz 7-7-7-16 (CL-RCD-RP-RAS) / 27-59-4-8-4-4 (RC-RFC-RRD-WR-WTR-RTP)

@ 457 MHz 6-6-6-14 (CL-RCD-RP-RAS) / 23-51-4-7-4-4 (RC-RFC-RRD-WR-WTR-RTP)

@ 380 MHz 5-5-5-12 (CL-RCD-RP-RAS) / 19-42-3-6-3-3 (RC-RFC-RRD-WR-WTR-RTP)

 

Memory Module Features

Auto Self Refresh Supported

Extended Temperature Range Not Supported

Extended Temperature Refresh Rate Not Supported

On-Die Thermal Sensor Readout Not Supported

 

Memory Module Manufacturer

Company Name OCZ Technology Group, Inc.

Product Information http://www.ocztechnology.com/products/memory/

 

[Vecna6667]

I usually set my page file manually because I have an SSD so I had to direct it to the mechanical HDD. If you do manual configuration, the recommended setting for min and max should be equal to the amount of RAM times 1.5(or that's how I have it set.) In your case 6144 MB. The minimum can be half or equal to the amount of RAM but I usually have it equal the maximum as said before.

[FMod]

I usually set my page file manually because I have an SSD so I had to direct it to the mechanical HDD.

That's not really "had to". It's like buying a new car, but leaving it in the garage and driving your old car daily so that you don't wear the new one out to much.

 

Placing the paging file on SSD is good for performance, and that's what you buy a SSD in the first place. You probably don't buy one with your last dollar either, so in 10 years' time, when it wears out, you'll long have lost any use for it.

 

 

So I have 4GB ram total. Should I let windows manage page file or should I set it manually? If so what should I set the Min and max too?

Always manually unless you have a SSD. Doesn't matter much, as long as min==max, for HDD.

For SSD let the OS manage.

 

Size-wise, 1.5x system RAM is a very old recommendation. Today a better one is about 4GB for systems with 4-8 GB of RAM, and about 2GB for systems with 12-16GB, assuming you mostly just play games, don't really need that much RAM and only bought it because it was cheap. Too large a pagefile slows your system down and fragments more. Too small will result in unnecessary RAM usage.

 

For proper sizing, you need to measure your peak commit charge and set it to (peak.commit-RAM)*(1.5..2) times that. Of course the number will be negative for most any gamer, so default to 2-4 GB as set above.

NB. This advice will probably be also obsolete in 2-5 years; if you're reading this in 2017 and your games are true 64-bit, you need more.

[Vecna6667]

I usually set my page file manually because I have an SSD so I had to direct it to the mechanical HDD.

That's not really "had to". It's like buying a new car, but leaving it in the garage and driving your old car daily so that you don't wear the new one out to much.

 

Placing the paging file on SSD is good for performance, and that's what you buy a SSD in the first place. You probably don't buy one with your last dollar either, so in 10 years' time, when it wears out, you'll long have lost any use for it.

 

 

After having an SSD fail on me in 13 months of owning one(mostly because I didn't redirect the temp and tmp folders,) I've avoided placing a paging file on an SSD because it increases the number of write operations on the SSD and thus shortens the life the drive(plus my HDD easily has room to spare.) As for my recommended size, it's works for me and has been effective, but then again, I've never had more than 6 GB of RAM on any of my computers(that might soon change.) I do like the suggested size for the 12 to 16 GB of RAM though and on greater than 16 GB, I would even consider disabling the page file as it becomes more and more obsolete.

[FMod]

After having an SSD fail on me in 13 months of owning one(mostly because I didn't redirect the temp and tmp folders,)

I doubt that was the cause of the failure.

Newer SSD have advanced write minimization and wear leveling algorithms. Older SSD have brute force overprovisioning and older much longer-lived flash memory.

You'd have to run it in a database web server torture environment day and night to wear it out in a year.

 

 

 

My best SSD contains the OS, and the pagefile, and temp folders, AND intensive caching (Fancycache MBU) for hard drives. (That's not your grandma's Smart Response, it goes hard on the drive.)

Its estimated write cycle lifetime, by SSDLife, is 1 year that has passed and still 6 to go. That's less than the usual 10 years.

 

Am I worried? No. Once it has 3 years estimated (mind you, SSDLife lowballs), I won't care. I'll have a better one and that one will do all the hard work. The now-old SSD will now contain games, or it will be put in a laptop (well, it won't, it's PCI-E, but if it could be). So its remaining 3 years will turn into 15 or more, because games don't write to their folders.

 

Will I care then? No. It will become so small and worthless in 10 years that I'll put it into some netbook or maybe it will be too small even for that, I'll give it a eSATA cable and use it like a thumbdrive. That will turn its remaining 5 years into 25. And in 25, I won't even have a use for it at all.

 

 

I would even consider disabling the page file as it becomes more and more obsolete.

Better not to. The paging file is architecturally required and it always improves performance. It's not spare RAM; windows uses it, most of the time, to reserve space that isn't actually being used. No page file means waste of RAM and generally greater bugginess. About 2GB is the essential minimum (2GB is maximum 32-bit program address space).

 

If you actually need all the 16GB, the requirement goes back up to about 8GB, or even more, per commit charge.

[Vagrant0]

After having an SSD fail on me in 13 months of owning one(mostly because I didn't redirect the temp and tmp folders,)

I doubt that was the cause of the failure.

Newer SSD have advanced write minimization and wear leveling algorithms. Older SSD have brute force overprovisioning and older much longer-lived flash memory.

You'd have to run it in a database web server torture environment day and night to wear it out in a year.

Actually, no.

 

While newer drives are better, older ones could be worn out rather quickly. Windows itself writes and reads to both the pagefile and temp files very frequently, especially if you're browsing websites, playing online games, or really doing anything that involves temporary handling of files. Even ignoring the advancements of newer drives, it is still always best practice to have your pagefile and temp folder managed by a drive other than your system drive since this helps distribute the load and acts as a measure to help make the system drive last longer (even in the case of mechanical drives). Even in cases where the pagefile drive is much slower than the system, you can still get higher performance by using that drive instead of your main SSD.

 

While I'm not using a SSD, I can clearly see difference in drive wear and fitness between my two drives. Drive 1 has the system and most of the game data, Drive 2 has the pagefile, storage, and all of my temporary stuff. Both drives are same capacity, same make, same model, installed at the same time. But my second drive has much more wear and tear and will likely fail first. And they're mechanical. I have no doubt that I'd have already burnt through atleast one SSD if I was using it for temp files.

 

 

More to the point, SSD's usually have a main limitation of storage space. Do you REALLY want to have 8-20gb of that space taken up by pagefile?

[FMod]

While newer drives are better, older ones could be worn out rather quickly. Windows itself writes and reads to both the pagefile and temp files very frequently, especially if you're browsing websites, playing online games, or really doing anything that involves temporary handling of files.

The first generation of cheap consumer SSD with Jmicron controllers had issues like that. But they had bigger issues than that as well.

 

Quality first generation drives and all starting with the second generation - that's any Intel, any Crucial, any OCZ starting with Agility 2 - don't suffer from this. These drives can take about 8-12 years in a consumer PC, running 24/7, with OS, temp and paging file on the SSD. And in 8-10 years, it will be worth very little either way.

 

It's already happening, I see people using older SSD like thumbdrives (because they're still much faster than the best USB ones), and it's only been 5 years since consumer SSD hit the market. These drives still have as much as 60% of their write cycles left, and now, out of a PC, they'll barely use up 1% and take the rest to their landfill grave.

 

Or you might buy a new, bigger and better SSD, and install games on your old one. Games write very little in their install directory, when at all, so once again, you just won't need these write cycles.

 

 

Even ignoring the advancements of newer drives, it is still always best practice to have your pagefile and temp folder managed by a drive other than your system drive since this helps distribute the load and acts as a measure to help make the system drive last longer (even in the case of mechanical drives).

If you have multiple equally fast or comparably fast SSD, then yes.

In my case, I've got a few older SATA SSD and a new Revodrive.

 

The Revo is pretty nifty. It consists of four already fast SSD, put in RAID0, on a PCI Express board, with a high-performance hardware controller running them. In total it has about 10x the performance of the better of earlier consumer SSD.

That's quite a bit of performance. It's enough to handle an OS, with pagefile and everything, and run Metro 2033 or modded Fallout 3, and act as cache for 6 other drives, and still have a lot to spare.

 

 

Even in cases where the pagefile drive is much slower than the system, you can still get higher performance by using that drive instead of your main SSD.

Not sure really. Are there any third-party tests confirming that?

 

So far what I know indicates otherwise. SSD are not just faster hard drives; they are closer to RAM than they are to HDD. Hard drives can only read one file at a time, one sector more precisely, one task. If they are forced to do two things at once, they have to jump there and back, slowing down to a crawl. SSD don't have this limitation.

 

We're talking 100-200 IOPS versus 10,000-50,000. It's not horse versus car, it's horse versus supersonic missile. A single SSD can handle the random IO workload of a whole array of 15,000 rpm enterprise HDD and still be faster at it - faster by so much that they are used to cache such arrays. And not special expensive units, plain old X25-E.

 

Put simple, a modern consumer PC, handling modern consumer workloads, doesn't generate enough IO requests to choke even a low-cost modern SSD.

 

 

More to the point, SSD's usually have a main limitation of storage space. Do you REALLY want to have 8-20gb of that space taken up by pagefile?

Just set it to be pretty small - as little as 256MB minimum - and let the OS expand it as needed. Unless you use the pagefile hard, you won't need more than a couple gigabytes. And if you do use it hard, you'll want it fast. On SSD, don't use fixed size, they don't have fragmentation issues like HDD do.

 

With HDD you're buying storage space, with SSD you're buying IOPS throughput. So the best way to make use of one is to put as much of your I/O workload on the SSD as you can. That will use more cycles, but if you can afford to buy it, you can afford to use it. There's a lot of write cycles in there, more than you're likely to ever use.

[Vagrant0]

Just set it to be pretty small - as little as 256MB minimum - and let the OS expand it as needed.

My experience with system managed pagefile sizes has never been a good one. Sure, things may work fine initially, but any time the OS needs to make more room you can take a rather large performance hit or suffer some amount of instability. Granted, this was mostly on an older, slower PC with Windows ME installed, but it still indicates that there is some increased system load when this sort of thing happens. Given that the time when you need a larger pagefile is at those times when you're usually already at a higher system load, the problem just compounds itself. Best to just set it to 1.5 your installed RAM and leave it be.

 

 

Regarding speeds. Although newer SSD can be faster, the bottleneck is usually other places so in the case of 90% or more of operation, there isn't much of a difference unless you're overclocking top of the line parts, watercooling, and trying to hack NASA.

[FMod]

My experience with system managed pagefile sizes has never been a good one. Sure, things may work fine initially, but any time the OS needs to make more room you can take a rather large performance hit or suffer some amount of instability.

That's an issue with HDD, because they suffer from fragmentation, including that of free space, and extending the pagefile is an issue, shrinking it later even worse, because it gets fragmented again. SSD are really very different, it's not a factor there. A lot of things that are critical with hard drives cease to mean anything with solid state storage.

 

As to size recommendation, here is a detailed article on the subject by Mark Russinovich (who is sort of the expert): http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx

 

His conclusions are:

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 ... you’re well positioned to see how useless such formulas truly are.

Set the paging file minimum to be that value [peak commit charge] 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.

 

 

Regarding speeds. Although newer SSD can be faster, the bottleneck is usually other places so in the case of 90% or more of operation, there isn't much of a difference unless you're overclocking top of the line parts, watercooling, and trying to hack NASA.

Well, I'm not trying to hack NASA, but other than that. However I also run FancyCache, which is a very intensive disk caching application. Since I only have 16 GB of RAM, it necessitates using SSD storage for level 2 cache. That is about the only thing that would overload a low-end SSD in home use.

[Vagrant0]

Regarding speeds. Although newer SSD can be faster, the bottleneck is usually other places so in the case of 90% or more of operation, there isn't much of a difference unless you're overclocking top of the line parts, watercooling, and trying to hack NASA.

Well, I'm not trying to hack NASA, but other than that. However I also run FancyCache, which is a very intensive disk caching application. Since I only have 16 GB of RAM, it necessitates using SSD storage for level 2 cache. That is about the only thing that would overload a low-end SSD in home use.

You missed what I was meaning. I was not saying that the SSD would bottleneck, but rather that the speed of the RAM, Processor, or connection method would likely hit a limit sooner unless you've spent a silly amount of money on a system for those few instances where you would actually need that much power. It's like owning a Ferrari when you live in the middle of New York. Sure it might go fast, but there aren't many natural situations where that speed can actually be used.