delete pagefile safe?

Page 2 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

mikeymikec

Lifer
May 19, 2011
17,759
9,699
136
My experience has been that whenever that happens my keyboard and mouse would not work and I would be unable to login or do a proper shutdown (since the PC is locked when it loses power). Forcing me to do a hard reset. As a result I have been disabling hybrid sleep

I'm not suggesting you re-enable hybrid sleep in your situation, but if only the keyboard and mouse are non-responsive (and not the whole computer), press the power button once and it should initiate the shut down process.

Occasionally I see configurations where pressing the power button once does something different (like put the computer into sleep mode) though. I have it set to put the computer into hibernate mode on my set-up, thanks to an annoying bug regarding undervolting on my board.
 

taltamir

Lifer
Mar 21, 2004
13,576
6
76
I'm not suggesting you re-enable hybrid sleep in your situation, but if only the keyboard and mouse are non-responsive (and not the whole computer), press the power button once and it should initiate the shut down process.
I am familiar with this technique. IIRC it didn't work while windows is "locked" and awaiting password. (it does work if you are not logged in, or if you are logged in... but locked is different)

I have used it on occasion when explorer was not responding but IIRC it didn't work on the hybrid sleep issue. Nor did unplugging the keyboard and plugging it into a different usb allow it to be detected....

Its been quite some time since i last tried it so I am merely explaining my recollections of the issue, could be wrong.

Occasionally I see configurations where pressing the power button once does something different (like put the computer into sleep mode) though. I have it set to put the computer into hibernate mode on my set-up, thanks to an annoying bug regarding undervolting on my board.
yea, its fully configurable and I have adjusted it to my own preferences. :)
 

mikeymikec

Lifer
May 19, 2011
17,759
9,699
136
I am familiar with this technique. IIRC it didn't work while windows is "locked" and awaiting password. (it does work if you are not logged in, or if you are logged in... but locked is different)

I have used it on occasion when explorer was not responding but IIRC it didn't work on the hybrid sleep issue. Nor did unplugging the keyboard and plugging it into a different usb allow it to be detected....

Its been quite some time since i last tried it so I am merely explaining my recollections of the issue, could be wrong.

No, it sounds logical (otherwise a logged-in user could lose data), I think you're right.
 

kleinkinstein

Senior member
Aug 16, 2012
823
0
0
Lots of religious fanatics pound their pulpit and push their 2-cents when this topic arises. But it simply doesn't matter if you keep or delete the pagefile. It makes no difference.
 

Nothinman

Elite Member
Sep 14, 2001
30,672
0
0
Lots of religious fanatics pound their pulpit and push their 2-cents when this topic arises. But it simply doesn't matter if you keep or delete the pagefile. It makes no difference.

It has nothing to do with religion, it has to do with a proper understanding of how virtual memory works and how Windows manages it. One would only suggest something like that if they really have no clue how either works.
 

kleinkinstein

Senior member
Aug 16, 2012
823
0
0
It has nothing to do with religion, it has to do with a proper understanding of how virtual memory works and how Windows manages it. One would only suggest something like that if they really have no clue how either works.

Yes, please share the empirical benefits of running with one, instead of without...or the other way around I don't care. Because it doesn't matter! But keep your religion (it's a metaphor BTW) out of your response as you enlighten us. I know it'll be tough, I can tell by how you've already responded.

Actually, don't respond. I'm done with this thread since again the PF is irrelevant today.
 

smakme7757

Golden Member
Nov 20, 2010
1,487
1
81
Gains without = Nothing

Having one is just good practice. Windows still writes memory pages to the page file even if you have 16TB of RAM and certain applications will use the page file if it is there.

There just isn't any decent reason for any normal consumer to disable the page file. Make it smaller, sure, but to completely remove it doesn't achieve anything and could cause an issue later on.
 
Last edited:

groberts101

Golden Member
Mar 17, 2011
1,390
0
0
my dirty penny on the subject.. as the same old question comes around yet again.

Keeping with the religous theme as of late. Microsoft is not god.. and Windows is not the 10 commandments.

Just because Windows defaults to a particular setting of uses a particular accellerator means squat to those out there who like to tweak for maximizing to their particular hardware and usage model. I'm only guessing here.. but I bet that many MS employees adjust the many bloated and "generally good for most systems" defaults to their desired preference as well.

So, in this instance there certianly is lattitude for those who have sufficient ram and never bump into the swapfile anyways. Unless you have oodles of ram hungry apps running and less than "about 12 gigs" or so.. the use of it is moot to those who have average workflows IMHO. If you really are overly concerned about it?.. or have apps that throw errors as a result of not having one(though I've never run into one yet in about 10 years now).. then just allow for a minimally sized swap that can grow as you need it to. The few that I've set up like that never grow.. so it certainly seems to be unecessary overblown hubub.

Some folks should also keep in mind that there are many systems out there still that have more than sufficient ram for the particular usage model.. but still use smaller SSD's so that physical flash space cannot be afforded to be tied up in an overly large system managed swapfile.

But what about the dump files you ask? Who the hell cares when you have multiple OS volumes and use images to get back to where you were if issues ever do arise. Not even worth the time to try and fix it in that scenario, IMHO.

PS. also IMHO.. anyone who doesn't think there is some overhead.. albeit slight as it may be.. with I/O and processing the swap file?.. doesn't understand that Windows is still a pig of an OS.

Oh.. and the answer to the actual question posed by the OP.. is YES it is completely safe to remove it from a stability standpoint. BUT.. ONLY if you don't care about the dump files for troubleshooting purposes or have apps that throw fits without it. Many tens of thousands have done just that for years.. even with HDD based systems.. and currently still practice minimizing Windows overhead in any tiny way possible.
 
Last edited:

mikeymikec

Lifer
May 19, 2011
17,759
9,699
136
Yes, please share the empirical benefits of running with one, instead of without...or the other way around I don't care. Because it doesn't matter! But keep your religion (it's a metaphor BTW) out of your response as you enlighten us. I know it'll be tough, I can tell by how you've already responded.

Actually, don't respond. I'm done with this thread since again the PF is irrelevant today.

Actually, the burden of proof is the other way around. If Windows has a page file by default and millions of systems are set up that way without any problem because of it, and someone asks, "is it ok to get rid of the page file?", only an idiot says yes without knowing for a fact that it is. On the other hand, someone who advises leaving it alone (because it is quite difficult to claim to know without doubt), is just offering prudent (because it is more likely to be generally compatible) advice.

One thing that I won't go so far as to declare as fact, but that I'm fairly sure that if the page file is disabled, Windows will re-enable the page file if it thinks it needs it. In short, I wouldn't be surprised that if people who think they've disabled it before go and check, they might find the pagefile hidden on their system drive. However, if I'm right, I wouldn't count on Windows re-enabling the page file because a BSOD-qualifying event has taken place.
 
Last edited:

ShintaiDK

Lifer
Apr 22, 2012
20,378
145
106
Actually, the burden of proof is the other way around. If Windows has a page file by default and millions of systems are set up that way without any problem because of it, and someone asks, "is it ok to get rid of the page file?", only an idiot says yes without knowing for a fact that it is. On the other hand, someone who advises leaving it alone (because it is quite difficult to claim to know without doubt), is just offering prudent (because it is more likely to be generally compatible) advice.

One thing that I won't go so far as to declare as fact, but that I'm fairly sure that if the page file is disabled, Windows will re-enable the page file if it thinks it needs it. In short, I wouldn't be surprised that if people who think they've disabled it before go and check, they might find the pagefile hidden on their system drive. However, if I'm right, I wouldn't count on Windows re-enabling the page file because a BSOD-qualifying event has taken place.

By that definition you shouldnt disable defrag on XP with an SSD.

Windows do not automaticly reenable the pagefile. Just as you dont get dmp files with a crash if the pagefile is moved to another partition than the booting one.
 

mikeymikec

Lifer
May 19, 2011
17,759
9,699
136
By that definition you shouldnt disable defrag on XP with an SSD.

How many sources do you want me to cite regarding "no defragging on SSDs"? I think that qualifies as "enough people who know what they're talking about".

Windows do not automaticly reenable the pagefile.
I could be wrong, hence the way I prefaced that bit of information, but I don't really care. I would like to see any evidence of a performance improvement before disabling a feature that adversely affects the ideal reaction in say a BSOD scenario.

Just as you dont get dmp files with a crash if the pagefile is moved to another partition than the booting one.
I don't see how the second sentence bears any relation to the first. I already said that I wouldn't expect Windows to re-enable a page file that it felt it needed in a BSOD scenario.
 
Last edited:

kbp

Senior member
Oct 8, 2011
577
0
0
Well Windows comes with "BING" and I do not use nor want it on my computer. Thus I remove it. . . . Maybe I should putt it back on cause MS knows something I don't.
 

smakme7757

Golden Member
Nov 20, 2010
1,487
1
81
It's an interesting discussion.

The people advising the OP to keep it give reasons - I.e: Stability, it's needed for some apps, windows will page even if you have heaps of RAM ect...

The people advising the OP to get rid of it give none?

Now i'm actually interested in what benefits there are to be had be removing the page file? What could i expect to gain from disabling my page file?
 

fluffmonster

Senior member
Sep 29, 2006
232
8
81
The page file reduces available space on the drive it is located on for other things. Irrelevant if you use a huge drive as your OS drive, but potentially relevant if you use a small SSD and a bunch of RAM since the default page file is same capacity as your RAM.

In the case of an SSD, the page file entails some writes. Is there a lot of writing to disk even when the page file isn't used by the OS? I don't know, but unless there is some utility from the page file then the writes are unnecessary and a waste of SSD "life". When my work first rolled out Win7, they had it configured to *scrub* the page file every shutdown and that was definitely a large and frequent and unnecessary write process.

Are these advantages to shrinking/removing page file important? Depends on usage, same as could be said for every reason to leave the page file. If you don't trouble-shoot, you don't care about the dump file. If you don't use any apps which demand page file, you don't care if a page file is available to those apps. I don't think its anything to get worked up about either way. If you've read this thread, you've already spent too much time on the matter.
 

taltamir

Lifer
Mar 21, 2004
13,576
6
76
In the case of an SSD, the page file entails some writes. Is there a lot of writing to disk even when the page file isn't used by the OS? I don't know, but unless there is some utility from the page file then the writes are unnecessary and a waste of SSD "life". When my work first rolled out Win7, they had it configured to *scrub* the page file every shutdown and that was definitely a large and frequent and unnecessary write process.
I have been using SSDs for years now, I have had pagefile and indexing enabled and on the SSD. It had not real effect on its lifespan.
My first SSD was an intel X-25 80GB G2 and it used up 1% every 6 months of use
My current SSD is an intel 520 240GB and it is still at 100% life remaining (bought on march 23rd 2012; its now dec 5th 2012)

If you've read this thread, you've already spent too much time on the matter.

unless you are actually interested in knowing. rather then just wanting to get the right answer and get on with it.
 
Last edited:

jimhsu

Senior member
Mar 22, 2009
705
0
76
A lot of random speculation on this thread.

Here are posts from actual windows engineers:

Sizing page files: http://mcpmag.com/Articles/2011/07/05/Sizing-Page-Files-on-Windows-Systems.aspx?Page=1

The first consideration for sizing page files is to look at the crash dump settings. During a crash dump, the NTFS file system is no longer available, but the operating system needs to write the memory in RAM to disk. The page file structure is on disk, so it is a logical choice to use as a way of writing to disk. The operating system deletes the contents of the page file and attempts to write the contents of RAM to the page file structure. Once written, the page file is renamed to memory.dmp and becomes the crash dump file.

The page file must be large enough to accommodate the selected crash dump setting, so it is a major consideration for sizing the page file. Windows and Windows Server have three crash dump settings, each of which require different page file sizes:

Complete memory dump: This option is selected by default if the computer has less than 4 GB of RAM. This setting dumps the entire contents of RAM to the page file. Therefore, the page file must be the size of RAM plus 1 MB. The 1 MB is needed to accommodate the header data. This is most likely why the 1.5 times RAM page file sizing myth became popular.
Kernel memory dump: This is the default if the computer has 4 GB of RAM or more. This setting dumps only the kernel memory. Kernel memory usage can range widely, so there is no clear page file size for it. The "Windows Internals 5th Edition" book suggests a minimum page file size of 800 MB for computers with more than 8 GB of RAM.
Small memory dump: If a Small memory dump is selected, then a page file of 2 MB or more is needed.

The second consideration for page file sizing is to accommodate the System Commit Charge and the System Commit Limit. The system commit charge is the total amount of committed memory that is in-use by all processes and by the kernel. In other words, it is all of the memory that has been written to or "promised" and must have a physical resource (RAM or page file) behind it.

If the commit charge reaches the commit limit, then the commit limit has to be increased or the committed memory must be de-allocated. The commit limit can be increased by increasing the amount of RAM or by increasing one or more of the page file sizes. De-allocation of committed memory can only happen when the owning process willingly releases memory or when a process ends. I can quickly see the system commit limit and system commit charge by using Task Manager (see Fig. 1) or by using performance counters (see Fig. 2).

Other stuff that is covered includes why the 1-1.5x guideline is a bad one, and most certainly depends on your usage scenario (i.e commit limit).

In summary, you can properly size page files by following a few simple steps:

Crash dump setting: Check your crash dump setting to see if your computer is set to "Complete memory dump" (default for computers with 4 GB of RAM or less). If so, your page file must be the size of RAM plus 1 MB or more. Otherwise, have a page file of 800 MB or more to accommodate a Kernel memory dump. If you don't care about crash dumps, then ignore this step.
Monitor the System Commit Charge peak: Monitor your computer's commit charge to determine how much committed memory the system is using at peak. This can be monitored from the Performance tab in Task Manager or by monitoring the \Memory\Committed Bytes counter in Performance Monitor.
Adjust the Commit Limit: Set the system commit limit to be larger than the highest monitored commit charge peak plus a little extra for room for growth. Remember, the commit limit is the sum of RAM and all of the page files. If you want to minimize paging, then try to have more RAM installed than the commit charge peak value. The commit limit on the server can be monitored either from the Performance tab in Task Manager or by monitoring the \Memory\Commit Limit counter in Performance monitor.

Page files and SSDs: 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.

Note also that only page files on the root drive are used for crash dumps.
 
Last edited:

jimhsu

Senior member
Mar 22, 2009
705
0
76
I forgot how Windows 7 or below manage page file sizes, but Windows 8 no longer sizes pagefiles automatically to be some multiple of RAM. On a 16GB system, my automatic page file size is just around 5GB.
 

BFG10K

Lifer
Aug 14, 2000
22,709
2,976
126
I forgot how Windows 7 or below manage page file sizes, but Windows 8 no longer sizes pagefiles automatically to be some multiple of RAM. On a 16GB system, my automatic page file size is just around 5GB.
IIRC it does 1.5x RAM to a certain size, then it does 1.0x RAM.
 

Dufus

Senior member
Sep 20, 2010
675
119
101
So then what's the benefit of it ?
Generalized into it's simplest terms, to make up for lack of RAM and provide crash dumps.

With a 32-bit system and large graphics card it may be beneficial due to the amount of page available to the system which is pagefile plus RAM. IOW you may run out of available page before running out of RAM.

With a 64-bit system and lots of RAM then maybe you only have to consider crash dumps and then whether you want a full dump or mini-dump (mini-dump needs a lot less pagefile) or maybe not interested in crash dump info at all. MS provide a standard setting which should work for the majority, not a tailored version for each individual. IMHO what you do with the pagefile should be on a case by case basis.

Note that even with the paging file removed that paging to disk can still occur with non-modifiable data i.e. most executables and data sections that are read only.
 

GrumpyMan

Diamond Member
May 14, 2001
5,778
262
136
I was under the impression that even if you disable the page file, Windows makes one secretly anyway.