Moving PageFile

indyit · 8 Sep 2010 at 14:25

I have a 40GB SSD with my windows installation and a regular 1.5TB 7200RPM HDD as my storage. I've been getting fed up with the SSD always being so very close to running out of space because my pagefile takes up 8GB on its own. I went into advanced settings and changed it to only use the other HDD. Are there any negatives to doing this? Should I not have?

Pygmyshrew · 8 Sep 2010 at 15:04

Generally if you have 2 hard drives the advice has always been put the PF on the opposite disk to where Windows was installed, but moving it from an SSD to a perhaps considerably slower HD might not be a positive step forward in respect to performance.

8GB sounds like a big page file though, you sure you need one that big?

jbloggs · 8 Sep 2010 at 17:44

my pagefile takes up 8GB on its own

No point moving your pagefile to a (slower mechanical) HDD, leave it on your SSD and make it smaller, also move any data/folders (that are not required) for the running of the OS over onto the HDD, uninstall any unsed programs, run CCleaner and remove any rubbish from the SSD, failing these things solving your problem, buy a bigger SSD...

indyit · 8 Sep 2010 at 20:16

Thanks for the advice, I might move it back then. No I don't need it to be that big, it's what Windows recommends (actually a bit more) because I have 8 GB RAM. I'll move it back to the SSD and reduce it to 4GB.

madindehead · 8 Sep 2010 at 21:20

Strange that your pagefile is so big. Did you set it to that size? Or are you allowing Windows to manage it? Currently my pagefile is about 6GB on a 250GB drive, and I have around 47.5 GB of programs etc on my C drive, with all my documents, music etc on the other drives.

NathanE · 8 Sep 2010 at 21:29

8GB RAM means you should have a minimum 8GB page file... period.

There is such an unbelievable amount of misinformation on this subject.

indyit · 8 Sep 2010 at 23:37

NathanE said:
8GB RAM means you should have a minimum 8GB page file... period.

There is such an unbelievable amount of misinformation on this subject.

Yeah, that's why I'm pretty confused on the matter. So should I leave it on my HDD or take up the space on my SSD? (I have 10GB free on it now, I just hate stressing about it because temp files etc. keep making it close to completely full).

SH4RKY · 9 Sep 2010 at 08:56

Sell it and buy a bigger one.

SiriusB · 9 Sep 2010 at 12:07

Buy a bigger SSD. 40GB is useless. Either that or buy another 40GB SSD and pair them in RAID [for 80GB, which is much more useful size].

BunnyKillBot · 9 Sep 2010 at 12:11

Yes you absolutely should move it, and i am surprised nobody else in here has said so.

SSDs have a limited read/write lifecycle. Paging data is obviously regularly moved in and out of disk space. By using your SSD as a paging drive all you are doing is needlessly eating up the disks life expectancy. When you have an alternative, even if its slower, you should use it.

Cosimo · 9 Sep 2010 at 12:29

This is what MS say:

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.

http://blogs.msdn.com/b/e7/archive/2009/05/05/support-and-q-a-for-solid-state-drives-and.aspx

The talk of eating up an SSD's life expectancy is rubbish as they have large MBTFs (Crucial C300 - 1,200,000 hours) so you’ll be throwing them in the bin before you get anywhere near that. If trim is working you shouldn't have any performance problems.

I would just get a larger SSD.

NathanE · 9 Sep 2010 at 13:04

If I had just spent £££ on a SSD I would, for sure, place my page file on it.

The people that argue "ooh ooh but it will harm its life expectancy" are using flawed logic. You don't spend £££ on a hard disk and then not use it. Just like you don't buy a brand new car and then refrain from putting mileage on it.

A traditional hard disk can fail at any moment. It can be argued that page file I/O contributes to hard disk failures all over the world.

Put your page file on the SSD. Set it to 8GB (since you have 8GB of RAM). And be done with it. Enjoy. Sit back and laugh at all those running severely crippled PC's with their page file turned off, or those with SSDs but without configuring their page file to use it.

Pygmyshrew · 9 Sep 2010 at 14:33

indyit said:
Yeah, that's why I'm pretty confused on the matter. So should I leave it on my HDD or take up the space on my SSD? (I have 10GB free on it now, I just hate stressing about it because temp files etc. keep making it close to completely full).

lol well you didn't tell us how much RAM you had until after the suggestions were made :eek:

Broken Hope · 9 Sep 2010 at 16:55

NathanE said:
8GB RAM means you should have a minimum 8GB page file... period.

It really doesn't mean that at all.

From: http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx

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.

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 (which represent pages that aren’t being accessed actively but have not been saved to disk) 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).

I have 6GB of RAM and I have a 2GB min 4GB max Pagefile set up on my system and I'm not crippling my system at all by doing that.

Pygmyshrew · 9 Sep 2010 at 17:22

Broken Hope said:
It really doesn't mean that at all.

From: http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx

I have 6GB of RAM and I have a 2GB min 4GB max Pagefile set up on my system and I'm not crippling my system at all by doing that.

I've never brought the Page file must match your RAM theory either, Really you don't want to encourage the use page file especially if RAM is plentiful its completely contradictory in that sense, however it's practical to have a bit there for Windows to use for the less important/less accessed stuff (as the above post says to free up physical memory). Also i've always been mindful that setting your page file to high might allow for less well made software over utilise it.

NathanE · 9 Sep 2010 at 19:30

Broken Hope said:
It really doesn't mean that at all.

From: http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx

I have 6GB of RAM and I have a 2GB min 4GB max Pagefile set up on my system and I'm not crippling my system at all by doing that.

I said turning it off entirely is crippling. Running it under sized is less of an issue but still an issue. It causes more work for the kernel's memory manager because fragmentation minimisation becomes more likely.

NathanE · 9 Sep 2010 at 19:41

Pygmyshrew said:
I've never brought the Page file must match your RAM theory either, Really you don't want to encourage the use page file especially if RAM is plentiful its completely contradictory in that sense, however it's practical to have a bit there for Windows to use for the less important/less accessed stuff (as the above post says to free up physical memory). Also i've always been mindful that setting your page file to high might allow for less well made software over utilise it.

There no such thing as "over use" of the page file when memory is plentiful. A page of memory can be resident in both the main memory and the page file. The OS might preemptively "page out" a page of memory to act as a shadow but the page will remain in main memory but put on the "standby" list. Then if the memory manager realises it needs to allocate some main memory it can simply look on the free and/or standby lists of pages and acquire one of those. Provided the page of memory hadn't been modified since it was preemptively paged out - then no paging operation will need to be performed because the state of that page was already preemptively written out to the page file possibly minutes, hours or DAYS beforehand. Thus improving the responsiveness of the kernel's memory manager to the real-time task at hand of allocating memory for the current process.

All software is oblivious to the page file. Even the mythical "Adobe Photoshop" example is oblivious to the page file. All these programs care about is whether they can allocate and use a chunk of memory. Adobe Photoshop is an often used good example of a page file killer because it makes huge contiguous memory allocations. Sometimes several hundred mega bytes in size. Contiguous memory allocations are often difficult for the memory manager to fulfil. Sometimes it has to perform some reorganisation of frames of main memory by paging them out and allocating them to the new allocation. Having a large page file minimises the need for these "defragmentation" efforts by the memory manager.

Memory is designed to be used, not preserved. Hard disk space is just another form of memory. The more you can offer to the kernel's memory manager - the happier it will be and the better it can perform its job.

indyit · 10 Sep 2010 at 15:09

Wow, there truly doesn't seem to be a right answer here. I'll take NathanE's advice on this one but I'll set the initial size to be 4GB and make the maximum 8GB... been keeping watch on my RAM use and the current things I'm putting the computer to use for never exceeded 4GB.

Pygmyshrew · 10 Sep 2010 at 15:32

NathanE said:
All software is oblivious to the page file. Even the mythical "Adobe Photoshop" example is oblivious to the page file

Here lies the problem, a machine with less RAM is more likely to become bogged down and thus start using its page file for operations which it really shouldn't be the result of which is poor performance, I see it all the time on the NHS servers I work with. On the flip side a machine with crap loads of RAM will not have this problem thus an 8GB page file on an 8GB RAM Windows PC is totally and utterly redundant. You want to avoid over utilisation of the PF as much as possible while allowing enough space for the less important stuff to page therefore there is no point for average Joe when you're in the dizzy heights of 8GB on a desktop PC setting your page file to match.

NathanE said:
I said turning it off entirely is crippling. Running it under sized is less of an issue but still an issue. It causes more work for the kernel's memory manager because fragmentation minimisation becomes more likely.

Nobody in this thread has suggested turning off their page file. Care to explain under what circumstances running undersized is an issue in terms of 8GB PF/8GB RAM setup? I'm sorry but if you're capping your PF at 8GB or even 4GB or even utlisiting it that much you have a bigger problem on your hands! Simply throwing more page file at a system which is heavily utilising it is very dense.

NathanE said:
Memory is designed to be used, not preserved. Hard disk space is just another form of memory. The more you can offer to the kernel's memory manager - the happier it will be and the better it can perform its job.

You are aware how much slower in comparison a page file is compared to physical memory? Filling your page file should not be a target or acceptable, over utilisation of a page file will result in system slow downs and is the best indicator around that you need to increase the amount of RAM you have.

Columbo · 10 Sep 2010 at 16:10

Pygmyshrew said:
You are aware how much slower in comparison a page file is compared to physical memory? Filling your page file should not be a target or acceptable, over utilisation of a page file will result in system slow downs and is the best indicator around that you need to increase the amount of RAM you have.

You are comparing the pagefile to physical ram when they are not the same thing.

Even if I had 100gb of RAM, Windows would still use the pagefile as NathanE explained above.

Best course of action to me is to just leave the ruddy thing alone and let Windows manage it.