The C Man

Quote:

It can be either--I run my page file on a second HDD that has only logical partitions inside a single extended partition.

The reason for making the second HDD a single extended partition is that it is then assigned drive letters last, and will not effect the current drive letters on the first HDD--if you are for instance adding a second HDD to an existing system whose first HDD has a primary and maybe a couple logical partitions in an extended partition.

When Windows, and especially DOS, initially assign drive letters--all non-hidden primary partitions get a drive letter first--so all visible primaries on the first HDD get a drive letter, then all visible primaries on the second HDD get a drive letter, then all logical partitions on the first HDD get drive letters, and then all logical partitions on the second HDD get drive letters.

If you add a second HDD to a system that already has drive letters assigned to the extended partitions on the first HDD--those drive letters will get *bumped* because the primary on the second HDD gets a drive letter before the logical partitions--now, this is only true in DOS, Win3.1, Win95, Win98, and WinMe--NT based OS's such as WinXP *remember* drive letter assignments based on the HDD's disk ID--so this *bumping* will not occur while in the WinXP OS--but if you boot to DOS for Ghost procedures--drive letter assignments will not match because in DOS--drive letters are assigned on each boot and are not *remembered*!

If you make the second HDD a single extended partition with logical partitions inside--now its drive letters are assigned last, and the drive letters on the first HDD will remain as they were!

Quote:

As mentioned by others, the performance gain by placing the page file on a second HDD on systems with 512 MB or greater is probably greatly over-rated--except under one condition!--if you have multiple users who log on and off your system multiple times during the day, and you use *

Fast User Switching

*.

*

Fast User Switching

* saves the *system state* of a given user to the page file when one logs off, and another user logs on--now the page file is going to get *heavy usage* and you have to have a page file that is big enough to hold your system RAM times the # of users that will log on and off during the day + the amount of regular page file use.  On my system, on average I use about 180 MB for page file usage--so say for safety I set aside 325 MB for the page file (.325 GB).  If I had 1 GB of RAM and four users using Fast User Switching, then I would set aside a minimum of 4.325 GB for the page file.

Now, each time a user signs off and a new user signs on, the first users *system state* i.e. all of RAM is *paged out* to the page file--and all the second user's *system state* on the page file is read back into RAM when the second user signs on--now there is a performance benefit to having the page file on the outer part of the HDD platter on a second HDD!

Under *normal* single user use--the page file is usually not a major performance problem--programs place data there in case they have to be *paged out* because there's not enough system RAM, but if there is enough RAM, then the page file does not actually get used much--it's there and has data in it, but it's never accessed or used--so the second time a page file becomes a performance issue is if you have less than 512 MB of system RAM, or you open so many programs at once that the system runs out of RAM and has to *page out* the present program(s) in RAM so another program can take its place in RAM so the system can use that program.

Quote:

That's probably the best reason to consider placing the page file in its own partition--even if it's not on a second HDD on the outer part of the disk as the first partition.

If the page file is being managed by Windows, it will grow and shrink as needed, and Windows will place it in all the holes or empty spaces during boot that are present--then Windows adds program files during use--the page file may grow adding to itself, but fragmented from the rest of the page file--and Windows adds more files after it--so the permanent Windows files have to work around all the fragmented page file segments on the OS partition--which is contributing to the fragmentation of the OS files.  On re-boot, the page file is re-created and fills the various holes, and Windows has to work around that again, and so on the fragmenting process goes.

So, placing the page file in its own partition can help reduce the fragmentation process.

The C Man,

Quote:

Hmm ... ... it must have been late (in Sweden) when I made my comment on the 2 GB pagefile ... ... I read it as 2 MB which is the absolute minimum "recommended" by Microsoft. Sorry about that.

Nightowl,

Quote:

I never thought of that. I have set up a computer for a family of four with the standard pagefile setting 1.5-3.0xRAM. That computer is primarily used by one user and maybe another but never all four "fast user switching".

Quote:

If a system has been set up with a Windows managed pagefile, change it to a "semi-fixed" pagefile with sensible minimum and maximum sizes. Create a Ghost Image, check the integrity and immediately restore it. Since the pagefile is excluded from the image (there is a place holder displaying the size but it is empty, 0 bytes), it gets recreated in a single contiguous chunk during the restoration of the Image. Not only that, it also gets located towards the front of the partition, only the most important system files have higher priority.

Christer

Christer

Couple references to *Fast User Switching*:

How To Use the Fast User Switching Feature in Windows XP

Optimize Windows XP--Fast User Switching

In that last link above--apparently the recommendation as to how to *optimize* Fast User Switching is to *not* use it!

I found the information on Fast User Switching and the page file buried in this reference:

Virtual Memory in Windows XP

Quote:

It looks like that segment of the webpage has changed from what I originally read--now says to start by using *half the size of RAM*--used to say the *full amount of RAM* per user!

This is another interesting *page file* link:

How can I optimize the Windows 2000/XP/2003 virtual memory (Pagefile)?

***********************************************
Christer wrote:

Quote:

Another forum poster had mentioned that he used Ghost image restores as his *defragmenter* rather than programs like Perfect Disk or Disk Keeper--interesting concept!  I think if you create a page file where both the min and max are the same, you then create a *permanent* page file in one contiguous space and now Windows will not resize it--and that reduces *fragmentation* of files also if the page file is on the OS partition.

Pleonasm wrote on Dec 16^th, 2006 at 10:06am:


This is a good tweak.  I've used it on several pc's that have 1gb of memory and it definitely improves the responsiveness of XP.

Here's another reference to it:

http://www.winguides.com/registry/display.php?id=399

Pleonasm

Quote:

The tweak you mentioned above does not appear to *disable the use of the paging file* in general--it appears to only apply to one system function of whether the NT Kernel uses the paging file or not.

Ghost4me

Quote:

I tried the tweak myself--did not see any obvious performance change on my system--and I've also run across several references that question whether it has any performance effects because the *normal* behavior of WinXP is to keep the kernel in RAM as long as there is enough in the first place--and if there isn't enough RAM, well you will have other performance problems far sooner--here's one:

See *Disable Paging of Kernel*

Here's another:

See:  *Update: I asked Windows guru Ed Bott... *

Interesting links in Reply #24, NightOwl (although the experience of Ghost4me seems to contradict the author's assertion about the lack of an impact of the tweak described in Reply #21).

Here's another tip that might be of interest to readers of this thread.

Quote:
Source:  http://www.pcworld.com/article/id,123413-c,optimization/article.html#

Pleonasm

Quote:

See here for a discussion of why this tweak may be counter productive: 

Virtual Memory in Windows XP

--See the heading: *Can the Virtual Memory be turned off on a really large machine?*

Quote:

I guess if you don't really need all that RAM in the first place that the virtual memory is locking up, then this tweak causes no harm--but, if you have that much RAM, I doubt it helps performance either--because virtual memory is never used!