Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am making a drive image that will be deployed to several computers, and I'm tweaking it for performance. It is a Windows XP image.

Considering there is only one hard drive, will the machine gain performance if I place the Windows pagefile on a separate partition, possibly FAT16 (instead of NTFS as the OS partition)? I'm thinking of this because Linux does it, actually it uses the raw partition as "swap space", which is more performant (has faster I/O) than the default journaled filesystem (I expect FAT16 to be faster than NTFS too).

If this does make sense, how should I go about it? Another filesystem? should the partition be on the beginning or end of the HDD?

share|improve this question
    
Why the downvote? It is a valid question IMHO, is not a dupe, is in the apropriate site, and I don't feel I'm saying something dumb (this is recommended in a couple of sites I saw, and I wanted to know). So please explain. –  Camilo Martin Feb 2 '12 at 17:20
    
performant is not a word –  JamesRyan Feb 2 '12 at 17:29
    
@JamesRyan "Dictionaries are descriptive, not prescriptive.". If "d'oh" (a la Homer Simpson) is a word already as per Oxford, performant will be (recognized). –  Camilo Martin Feb 2 '12 at 18:57
    
Not if people point out how stupid it is everytime someone uses it :D The problem with performant is that it doesn't actually specify whether you mean fast/efficient/something else - in fact you even had to put in brackets what you meant so your use of it was entirely pointless! –  JamesRyan Feb 3 '12 at 0:30
    
@JamesRyan Maybe it was pointless by having an explanation in brackets, but you can say "Linux is far more performant than Windows", and I doubt explanation is needed. Also, if it wasn't for you telling me it was not a word, I wouldn't know - it's everywhere! You're the first one I see complaining. It's jargon, just like "database" or "hyperlink". –  Camilo Martin Feb 3 '12 at 1:03
show 1 more comment

5 Answers

up vote 5 down vote accepted

There is no performance gain at all in putting your pagefile on a different partition on the system disk.

There is a gain, instead, in putting it on a different physical disk, but only if there are no other workloads on it.


Edit

To address your comment:

  • Compression is a Very Bad Idea for a page file, as it needs to be accessed precisely at random offsets, which becomes awfully slow if you don't know where a given sector is actually stored on disk and have to uncompress the whole thing first.
  • Fragmentation is never a concern, because the page file is always created in bulk and can't indeed be relocated at all (defrag utils always show it as a big non-movable chunk of data).
  • Whatever you can gain from a greater (theoretical) disk speed is useless if the disk is being accessed at the same time by other processes to read/write data or system files.
  • Ditto for any (theoretical) advantage of FAT above NTFS. Which is, by the way, purely theoretical, as NTFS is in no way as slow as you think it is.

Again: there is only one scenario in which moving a page file makes sense, and it's when it gets placed on its own physical disk.

share|improve this answer
    
What about the performance of FAT vs NTFS? What about indeed using NTFS, but enabling compression (so that hopefully processor speed is traded for disk I/O)? Or, what about one end of the disk being faster than the other? (and also, a different partition would avoid the pagefile from getting fragmented over the disk). –  Camilo Martin Feb 2 '12 at 19:12
    
@Camilo: see edit. –  Massimo Feb 2 '12 at 21:19
    
Regarding the edit: Well, pagefile.sys can be defragmented offline, and I usually feel a difference after defragmenting it (it grows and fragments, after all) and the MFT... I've indeed thought initially NTFS must be slow, by comparing it to Ext4. Maybe this is indeed over-optimization. Thank you for your feedback and for answering the question. –  Camilo Martin Feb 2 '12 at 22:34
    
The page file can get fragmented if it grows dynamically due to memory pressure... but the first step for someone who's seriously concerned about performance is to make sure there is no need to grow it in the first place. If you are out of memory, you have far worse things to worry about than optimizing disk performance. –  Massimo Feb 2 '12 at 23:06
    
Also, setting it to zero size, rebooting the system and then creating a new page file is a lot quicker (and safer) than defragmenting it offline. –  Massimo Feb 2 '12 at 23:07
show 1 more comment

This doesn't make much sense. Also, by moving the pagefile off of the boot volume, you lose the ability for the OS to dump crash info in the event of a BSOD. This makes troubleshooting a pain. On top of that, I can't imagine that your performance would increase by any meaningful amount.

Just leave it where it is. If you're paging a lot, solve the actual problem by adding more RAM instead of mucking around with arcane disk layouts.


Unrelated side note: I really advise against new deployments XP. It's end-of-general-support and is within two years of ending extended support. Why wouldn't you be deploying Windows 7 at this point?

share|improve this answer
1  
I never used a crash dump to solve any BSOD, and I've solved quite many of them. Actually, I was personally never in a situation (or saw a situation) where it would make a difference between having or not a dump (I know what STOP 0x7B means, why I need a dump?). And I'm not in the position of telling people "go buy RAM or your PC won't work!". Would you install Windows 7 on third-world PCs with 512 of RAM? I just want them to make the best I can within that limitation. Besides, I'm asking because people seem to recommend it even if it is the same drive. –  Camilo Martin Feb 2 '12 at 17:36
1  
Would you install Windows 7 on third-world PCs with 512 of RAM? - No, but I also wouldn't put XP on them either. If you're super-low on resources then a slim Linux distro would probably be the best fit rather than shoving out machines that won't have security patches in a couple of years. I never used a crash dump to solve any BSOD - Good for you. I have. Things like UNMOUNTABLE_BOOT_VOLUME are dead simple to solve. Plenty of others are not. The choice is yours, but generally speaking the gains are absolutely minimal at best anyway, so why push out a non-standard config? –  MDMarra Feb 2 '12 at 18:16
    
A slim Linux distro - perfect, for me (I've personally used SliTaz). But not for normal people, and I'm not going to try and convince them. Mind you, I've seen (nLited, tweaked to hell, etc) XP run on 128 MB of RAM, a 400MHz processor, and 3GB of slow HDD (and an AT keyboard). It was terribly slow, but it worked for the basic usage it was meant for. This is much better, and sincerely it is getting each step just a little faster, much better than a standard Windows 7 on 1GB RAM (and I still didn't have to disable visual effects or themes). The gains aren't "minimal". –  Camilo Martin Feb 2 '12 at 19:08
add comment

As others have already said, there is no performance gain. Quite the contrary, you can expect a measurable drop in performance. The reason for this is that by having the separate partitions on the same disk you will cause the head assembly to move more than would otherwise be the case. The effect is the same as a heavily fragmented disk.

This of course applies to anything stored in multiple partitions on a physical drive (or array) but is worse for a swap file because it is read and written to constantly.

share|improve this answer
    
I cannot see how it could cause a performance drop, since the page file would anyway be on the same disk. I do not know how fragmented the virtual memory there gets, but I expect some chunks to be read sequentially (maybe this is not the case). After all, Linux still does it, so there must be a reason. I plan (in a future) to use former MS utility BootVis to inspect on that. –  Camilo Martin Feb 2 '12 at 22:36
    
@Camilo, for starters stop trying to compare Windows and Linux. They're completely different and do things differently. The similarities between the swap/page files on the two are superficial at best. I have already explained why you would get a performance drop, so I'm unclear which part you don't understand. –  John Gardeniers Feb 2 '12 at 22:55
    
@Camilo: the worst killer of disk performance is latency, which is caused by the disk heads having to actually reach the data they need to access. If the data are scattered across the disk, latency becomes the worst bottleneck; this is why fragmentation is bad. But if the heads have to continuously jump between files on two different partitions (say, system files on C: and the page file on D:), this has exactly the same effect as a heavy fragmented disk. this is why partitions are bad for performance. –  Massimo Feb 2 '12 at 23:10
    
@JohnGardeniers I'd like to know why a swap partition would be different from a partition with a pagefile. I'm curious, I tought a pagefile would be the same as a Linux swap in a file (and by default distros choose a partition instead of a file). What's different? –  Camilo Martin Feb 2 '12 at 23:46
    
@Massimo Then why does Linux not suffer from this? Also, isn't there latency anyway if it is in the same partition, considering it would in any case move the disk heads to where the pagefile is? My point is that in this case the pagefile would never be fragmented, and several sectors to read/write on it would be close together in the disk. I do not understand why jumping between two partitions would be different from jumping between two files on the disk. –  Camilo Martin Feb 2 '12 at 23:50
show 2 more comments

Actually, there is one scenario where you may want to move the pagefile to another partition. A while back, I took over management of several older production servers that had a 3-disk RAID 5 container partitioned as C: and D:. Unfortunately, following a worst practice that was in vogue at the time, C: is only 8 GB, while D: is 128 GB. The space on the C: drive was close to being exhausted, and moving the pagefile was the only was to free up some much-needed space.

share|improve this answer
2  
Great, but how does your answer relate to the performance? –  kubanczyk Nov 9 '12 at 16:08
add comment

Actually there are a few reasons for doing this. What I typically do is research what the best practice is for that install (2012 is far different than prior, and prior they'd suggest different needs for machines with 32GB+ of memory to NOT do the 1.5x)

  1. Creating a partition at the lowest offset puts it on the faster part of the disk
  2. Forcing it to this partition at a fixed size prevents it from growing and fragmenting automagically

Both increase speed.

share|improve this answer
    
Thanks, but at 32GB+, I'm almost sure you could even disable the pagefile... –  Camilo Martin Oct 2 '13 at 14:43
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.