Re: Managing pagefile and hiberfil.sys and disk resize
- From: "Twayne" <nobody@xxxxxxxxxxxxxxxxxxx>
- Date: Thu, 3 Sep 2009 20:39:03 -0400
"C.Joseph Drayton" <c.joseph@xxxxxxxxxxxxxxxx> wrote in message
news:h7p3qt$fnc$1@xxxxxxxxxxxxxxxxxxxxxxxxxx
On 9/2/2009 8:23 PM, Robert Carnegie wrote:
I got myself a Gigabyte M912 little-notebook touchscreen PC, with
Windows XP Home, which is probably enough for now. I'm looking
mainly for credible pagefile advice: so hit me, folks ;-)
Quite a big hard disk for the category. 1 GBytes RAM, replaceable
with a 2 GBytes module instead: not so good.
What does "not so good" mean?
Now, as to pagefile (swap file):
I plan to back up the machine (have done so once) by booting with
Linux "Live CD" in external drive such as Knoppix 6.0.1 and copying
drive C into compressed files on D, then backing those up elsewhere
(DVD). With "experimental" NTFS support, only actual file space on C
is backed up. But I suspect this includes pagefile.sys. So part 1:
I want at most a small pagefile on C, and more elsewhere, unless
there's a strong counter-argument.
With only one disk drive, there is zero advantage to having the pf
(pagefile) located on another drive letter. It's only helpful when the
pf can reside on a separate, different physical hard drive. Using a
different partition on the same hard drive will give you no benefit and
depending on where it gets created physically in the platter/track
system, could even result in the opposite condition; slowing things
down.
Since this is a single-disk only machine, forget about moving or
splitting the pf; it will be of no benefit.
The disk is large enough to have any appropriate permanent pagefile
allowance on another partition, dedicated or not. The machine also
has an ExpressCard slot, SD card slot (SD-HC?), and three USB ports.
There's a lot of advice online that is contradictory and that I'm
suspicious of.
<http://www.aumha.org/win5/a/xpvm.php> was written by Alex Nichol,
but at least one reference says he's passed on. Other stuff just
gets passed around.
You are quite right; there are a lot of varying opinions on the pf usage
et al, but everyone will pretty much tell you that it's of no benefit on
a single-drive system, regardless of how many drive letters (partitions)
that drive is split into.
Like this:
IMO:
01. The more RAM you have, the smaller pagefile you need.
Well, the less it gets used. The pg is only used for RAM "overflow" if
you will; when there is not enough RAM to hold everything that needs to
be in RAM. The hard drive is then used as an extension to RAM to get
the additional needed space.
In an ideal situation, the pg would never get used because everything
ever needed will fit into RAM, so it won't "overflow". In practice,
it's not that simple but it's close. With 2 or 3 Gig of RAM one should
never see any pf activity for normal day to day tasks. But if say a
large graphic or video editing/rendering, or some very intensive number
crunching has to be done, THEN it might spill over into the pf because
everything might not fit in RAM at the same time when it's needed to be
there at the same time.
02. The more RAM you have, the larger pagefile you need.
That comes from the idiotic myth that you should have a pf 1.5 times the
amount of RAM you have, which is not at all what MS intended. 1.5 time
RAM is a starting figure for a 512 Meg of system RAM. The LESS RAM you
have, the more you MIGHT need a larger pagefile. Again, it depends on
what the machine is doing.
One thing you should do is avail yourself of one of the many free
pagefile monitors available on the 'net. PC Mag, Eldergeek, all kinds
of reputable places have them available. That way you get a finite look
at how much, if any, the pf is actually being used.
Normally the pf will contain a couple hundred or so k of data. It
keeps enough minimum space available for mini-dumps in case something
goes wrong. But if the system never needs the pf, those numbers don't
change more than a few tens of bytes as various things go on.
03. If you have enough RAM, you don't want a pagefile.
No idea where you got that; It's total malarky.
In addition, it's technically impossible to not have a pf. Even if
you turn it off, an amount of space on the drive will still be allocated
for pf activity and will be used if needed, rather than allow Windows to
crash just because it needs another k or so of RAM space. Windows tries
to protect itself in that manner. Likewise, if you spec too small a pf,
and windows wants more, it'll make the pf larger on its own and simply
advise you with a dialog box that it's doing it. So you don't crash,
but you suffer the annoyance of the dialogs popping up when it's too
small. Set too large, then it just wastes space for nothing.
04. You should have a pagefile on C even if you have a pagefile on
another drive. What if the other drive breaks?
The pf on C will be reallocated for what it needs and you'll get error
messages. See the previous item.
05. However much RAM you have, you should set a pagefile of at least
50 MB on C.
Yes. I usually use 250 and have never seen 50, but ... in general
that's true. Memory dumps can only be written to C so you need to keep
something there.
06. However much RAM you have, you should set a pagefile of at least
500 MB on C.
Same as previous. I suspect you're making up these numbers now.
07. A pagefile can't be defragmented.
False. There are several ways to defrag a pf. It just can't be
defragged with XP or most defraggers, that's all.
08. To avoid pagefile fragmentation, set its minimum size and maximum
size equal. The pagefile will immediately take up that amount of
disk space.
Yup. Forever. And it's a waste of space. It's always best to let the
system manage it. There are a lot of opinions about this one. Six of
one, half a dozen of the other IMO. I only use system managed size and
only have ever had 2 fragments in my pf. That's because, as long as the
drive isn't full, and the pf size was set well before it started to
become full, XP is smart enough to keep space allocated for it to grow
and that pf area will be the last area of the drive to become occupied
with file storage. If the drive starts to fill up though, you may well
get fragmentation of the pf. Whether it will be enough to bother
anything is anyone's guess. The pf prefers to live in the center area
of the disk, equidistant from both ends of the disk w/r to seek times
for the heads.
09. A pagefile can be defragmented, for instance with free download
PageDefrag.
You just stated it couldn't above. Your'e getting montonous.
10. But you may as well stick with point 08 anyway.
11. Pagefile should be 0.5 times / 1.5 times / 2 times / 2.5 times /
3 times RAM, and no more.
Forget the rules of thumb. Get as much RAM as you can, then a pf
monitor, and run your most intensive programs. See how much it gets
used, if at all. With 1.5 to 2 Gig of RAM, most people will seldom see
their pf being used.
12. Pagefile should be no more than 4 gigabytes minus the physical
RAM size.
13. Pagefile doesn't need to be on a fault tolerant storage.
14. A disk fault in the pagefile is liable to crash your computer.
15. Pagefile on a separate disk - not separate partition of same disk
- is likely to improve performance.
Yes, on a separate PHYSICAL hard drive.
16. Pagefile on a separate disk will hurt performance if the bus to
its disk (USB) is slower than for the built-in hard disk.
I think that's about it. The size issue is my main interest.
Other current concerns:
21. If - when - hibernation is switched on, a file \hiberfil.sys is
generated on C, the same size as RAM. You can't do anything about
that, except disable hibernation and maybe reboot.
No; the same size as occupied RAM. How else could you store the data?
22. How large should C be for Windows XP and a few major
applications, such as OpenOffice and Firefox, and with a view to
copying a very compressed version onto, say, one DVD? On my last
machine I made C about 14 gigabytes. It's nearly full now, which I
guess means I did it pretty right.
Better to get a bigger hard drive; they're cheap. Allow plenty of room
for expansion. Don't get caught having to resize the partitions down
the road; it can get pretty messy.
23. I can't remember what I actually did the last time I resized a
partition. Vista does it, XP doesn't. Currently my plan is:
a. Back up Windows XP (done)
b. Download and use MyDefrag to move files on C (NTFS) out of the MFT
and consoldiate them at the start of C.
c. Use Knoppix 6.0.1 and the tool "parted" to impose a smaller
partition size for C.
d. Immediately use Windows CHKDSK or other built-in tools to correct
the consequences of doing that.
You'd be a hell of a lot further ahead buying a terabyte external drive
to hold your sequential backups and employ a disk imaging application
such as Norton's Ghost our Acronis' True Image. It takes me a total of
23 minutes to pop in the boot CD, tell it where the images are stored,
and to end up with a fully functional machine as it was on the date the
image was made.
You don't seem to do scheduled backups, but Norton and TI will do
those for you so that your data is never more than 12 hours old or
whatever figure you decide to use. That includes the operating system
and all data on all the drives attached to the machine except the
external storage drive in my case. I use Ghost and it doesn an
incremental backup every night or whenever anything is uninstalled or
installed and when more than 50 Meg of data has been erased or added to
any of my drives. I also use XXCopy to make special, extra-important
backups of things like development history, things like that. The idea
is to never lose anymore data than absolutely necessary at any time.
Then monthly, after the full backups have run, I transfer the full
backup to DVDs forpermanent storage; one for me and one for my sister
(we trade image sets so we always have a set stored "offsite".
And finally, I don't have any arguement with the method proposed below
either, except that I don't think it covers all the bases. By having
the pf on and set to system managed, it's there should it ever need to
be used. No farting around with annoying messages when windows decides
it has to have one or crash; no one wants the crash.<g>
HTH,
Twayne`
Hello Robert,
The questions and points you raise are good ones, but I would like to
point out to you that your question is somewhat subjective.
The hardware your using, the software you run and what you actually do
on your computer will effect the answer.
Let me give you an example;
On my development machine, I do not run a pagefile at all. I have 2GB
of RAM and when I am programming, I tend to not be doing anything
else. When I have to manipulate graphics for an application that I am
running, I have a VM with nothing but Adobe Design Studio CS3
installed on it, in that VM I run a pagefile that is 2.5 times the
size of the allocated RAM for the VM (in this case 1GB).
The development machine and the VM are set up so differently because
Adobe loves a big pagefile, where-as the compiler I use is CPU
intensive and I have it do most of its work in RAM. With 2GB of RAM,
I can set up a RAM disk that holds compiler and resource files. That
way I can do very fast compiles.
In short, there really is no ONE answer. I would say that you should
experiment and take good notes to find out what works BEST for YOU.
Sincerely,
C.Joseph Drayton, Ph.D. AS&T
CSD Computer Services
Web site: http://csdcs.site90.net/
E-mail: c.joseph@xxxxxxxxxxxxxxxx
.
- Follow-Ups:
- Re: Managing pagefile and hiberfil.sys and disk resize
- From: Robert Carnegie
- Re: Managing pagefile and hiberfil.sys and disk resize
- References:
- Managing pagefile and hiberfil.sys and disk resize
- From: Robert Carnegie
- Re: Managing pagefile and hiberfil.sys and disk resize
- From: C.Joseph Drayton
- Managing pagefile and hiberfil.sys and disk resize
- Prev by Date: Re: Loss of Hard Disk Enumeration in Windows XP
- Next by Date: Windows Cardspace
- Previous by thread: Re: Managing pagefile and hiberfil.sys and disk resize
- Next by thread: Re: Managing pagefile and hiberfil.sys and disk resize
- Index(es):
Relevant Pages
|
