1. You are viewing our forum as a guest. For full access please Register. WindowsBBS.com is completely free, paid for by advertisers and donations.

Pagefile Location

Discussion in 'Legacy Windows' started by kwbassociates, 2003/03/06.

Thread Status:
Not open for further replies.
  1. 2003/03/06
    kwbassociates

    kwbassociates Inactive Thread Starter

    Joined:
    2003/03/06
    Messages:
    4
    Likes Received:
    0
    Hello all. I hope my question is rather simple. We are running Windows NT SP6 on our main server.

    What are the consequences if the pagefile is moved from the C drive onto another logical drive? Also, how big should the pagefile size be? I was told 1.5 to 2 time the amount of physical memory available. Is this correct?

    Thanks in advance for any input.

    Allen
     
  2. 2003/03/06
    Newt

    Newt Inactive

    Joined:
    2002/01/07
    Messages:
    10,974
    Likes Received:
    2
    The result of moving it will be a slight performance improvement. Absolutely no downside.

    As to the size thing, there is no really good rule. Too many variables. But since the results of filling it up are moderately horrible for a server, I tend to go large.

    I'd suggest if you have enough disk space to set the minimum at 2 times physical memory and leaving the maximum size blank.

    And since NT4 does not have any good way to defrag the file, I'd also suggest a copy of the free PageDefrag. Gives you an easy way to check fragmentation of all your registry hives and you can set it to defrag at next boot or at every boot or never with a mouse click.
     
    Newt,
    #2

  3. to hide this advert.

  4. 2003/03/08
    sholton

    sholton Inactive

    Joined:
    2003/03/08
    Messages:
    9
    Likes Received:
    0
    Actually, the performance impact will be dependent upon several factors.

    If you 'page' alot (over-committed real memory), moving the pagefile to another LOGICAL volume could be a mistake (assuming that by LOGICAL volume, you mean another partition of the same physical hard drive.)

    The reason is simple - by moving to another partition on the same drive, you are guaranteeing that the distance that the head will have to move for a paging operation is longer, which also means that the I/O for the page dataset will be slower. This is (obviously) dertrimental to performance - especially in a high page-rate environment. Not only that, but the head will have to move farther back to the DLL (or whatever) it was trying to load after it has moved a page(s) out-of-the-way to the pagefile.

    If, on the other hand, you invest a small amount of money for a relatively small but fast SEPARATE disk, and allocate only the pagefile on that disk, then perfomance may improve dramatically, since the only I/O to that device would be for paging, and there would be minimal head movement required, since the head would already be somewhere within the bounds of the pagefile ALWAYS - so minimal seek distances and times (note: you could also store rarely used stuff on this disk - so that there is no contention for the disk when the page I/O is needed.)

    Obviously, the more (less) you page, the more (less) significant the placement of the pagefile becomes wrt performance. Add more RAM, for example, and your page rate should decrease (potentially disappear except for when you first load a program), and the performance effect of pagefile placement is minimal.
     
  5. 2003/03/09
    rambler

    rambler Inactive

    Joined:
    2003/03/08
    Messages:
    85
    Likes Received:
    0
    Spot on that man! I weary of the times I've read the advice "move the page file to another partition to improve performance ". If you've only got one HD, the best place for the page file is slap bang in the middle of "active" files to reduce seek time. You can allocate page space on more than one HD with NT4, W2K and probably XP Pro. With a busy machine like a server, this could well be advantageous, as Windows will tend to use the faster HD(s).
     
  6. 2003/03/10
    kwbassociates

    kwbassociates Inactive Thread Starter

    Joined:
    2003/03/06
    Messages:
    4
    Likes Received:
    0
    Thanks for the responses so far. I think I understand the problems of moving the pagefile. I'll say what I think and please correct me if I'm wrong.

    Our server has Windows NT 4 SP6. We have 3 PHYSICAL drives. 2 of those drives are mirrored with 2 LOGICAL volumes: C and E. The 3rd drive only has volume F.

    Say our server does most of its work on the C drive. If I were to move the pagefile to E, then I would degrade performance because:

    "by moving to another partition on the same drive, you are guaranteeing that the distance that the head will have to move for a paging operation is longer" - sholton

    However, if I were to move the pagefile to F, which is on a separate PHYSICAL drive, then I would increase perofrmance because:

    "the only I/O to that device would be for paging, and there would be minimal head movement required" - sholton

    Is this correct?

    Allen
     
  7. 2003/03/10
    rambler

    rambler Inactive

    Joined:
    2003/03/08
    Messages:
    85
    Likes Received:
    0
    Exactly - got it in one (or was it two?). On a busy server, especially with mirrored drives, you'd probably see a performance improvemnent even if your F drive wasn't as fast as the C drive. The disk heads on the F drive would always be over the page file.

    Years ago, when I worked with large mainframes, we positioned page files on disks with low activity data. Large hard drives were expensive back then, so it was difficult to justify spending £40,000 ($60,000) each on dedicated drives for paging only. These drives were in cabinets about the size of a large washing machine, had 14" multiple platters (10 double-sided), and held a MASSIVE 2.5Gb each. The drive motors could probably have powered a small electric car.
     
Thread Status:
Not open for further replies.

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.