• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

swap file on each partitions?

F

faye

Platinum Member
HI, I have a harddrive that has 4 partitions(c:, d:, e:, f🙂

I wonder if need to make each drive to have 300MB of virtual memory.

right now i have 900MB(c:, d:, e🙂

My OS(winxp) is installed on C:, D: is for games E: and F: are more movies and mp3s

I've checked from my "tast manager" that the most pagefile size i need is ~200MB
 
Then make just one swap file on drive C: - set it to 300MB minimum and leave the maximum open.

With swap files on each partition, Windows has to waste time checking the status of each swap file, which
means the drive heads are moving all over the place trying to keep up when they don't need to.

It is considered better advice to have more swap files if you have more than one actual hard drive.
One per hard drive.
 
Nope, you only need 1 pagefile. OPtimum results it should reside on seprate physical disk (not partition but hard drive itself), next best a different partition on same disk, last is on the same Partition as the OS.

I do not think you will notice any difference keeping your 1 pagefile on your C partition, but you certainly do not need it on more then 1 of your partitions.
 
If they're all on the same physical drive it'll hurt more than help, all you'll do is add more seeks when it needs to traverse the pagefiles. If they're on seperate physical drives it may help a little bit, but if you're paging enough that it does help you need more memory.
 
With one drive and multiple partitions the swapfile should be on a non-OS partition.
Click to expand...

No it shouldn't, that'll just cause higher seek times as everytime the pagefile needs accessed it has to seek across partitions. Ideally you want it right in the middle of the OS disk or on it's own physical disk.
 
Usually I prefer to have a specific swap partition when using windows. The reasioning is that I don't what to have the page file fighting with the regular files for space, fragmenting the system. It's just to keep things clean, not for performance.


edit: Actually I wonder sometimes why in Unix-based operating systems like Linux file fragmentation is almost never a issue, but in Windows it is almost a weekly or monthly cronic issue. You would think that something like this, since Unix hasn't have this issue for ages, would be relatively easy for Microsoft to correct. Oh well.
 
Actually I wonder sometimes why in Unix-based operating systems like Linux file fragmentation is almost never a issue, but in Windows it is almost a weekly or monthly cronic issue. You would think that something like this, since Unix hasn't have this issue for ages, would be relatively easy for Microsoft to correct. Oh well.
Click to expand...

The allocation algorithms are smarter but even so on a filesystem with a lot of create/delete activity fragmentation can't be avoided.

My root filesystem: actual 274386, ideal 267853, fragmentation factor 2.38%
My 'data' filesystem: actual 216817, ideal 22942, fragmentation factor 89.42%

Although I can't really notice a slowdown on either filesystem, the data filesystem's fragmentation is probably so high because that doesn't take into account free space fragmentation and it's got a lot of really big files and they fragment very easily.
 
Originally posted by: Nothinman

My root filesystem: actual 274386, ideal 267853, fragmentation factor 2.38%
My 'data' filesystem: actual 216817, ideal 22942, fragmentation factor 89.42%
Click to expand...

How do you get this information?
 
Originally posted by: Nothinman
With one drive and multiple partitions the swapfile should be on a non-OS partition.
Click to expand...

No it shouldn't, that'll just cause higher seek times as everytime the pagefile needs accessed it has to seek across partitions. Ideally you want it right in the middle of the OS disk or on it's own physical disk.
Click to expand...


I am, I believe, entitled to my opinion based on the information garnered from people who I think know what they are talking about.
 
How do you get this information?
Click to expand...

It's XFS specific: xfs_db -r -c frag /dev/sdd1

I am, I believe, entitled to my opinion based on the information garnered from people who I think know what they are talking about.
Click to expand...

Then don't make definative statements that come off as fact, "should be" isn't the same as "I believe".

And seek times are the biggest problems with disk speed, especially when you're dealing with disks that have low rotational speeds like IDE ones. When reading/write to multiple partitions the heads have to go back and forth between the partitions which slows down both operations. Time a copy of a file from 1 partiton to another on the same disk then time it when going between two physical disks (if you're using IDE make sure they're on seperate cables too for best speed) and you'll see a big speed difference.
 
Originally posted by: Nothinman
How do you get this information?
Click to expand...

It's XFS specific: xfs_db -r -c frag /dev/sdd1

I am, I believe, entitled to my opinion based on the information garnered from people who I think know what they are talking about.
Click to expand...

Then don't make definative statements that come off as fact, "should be" isn't the same as "I believe".

And seek times are the biggest problems with disk speed, especially when you're dealing with disks that have low rotational speeds like IDE ones. When reading/write to multiple partitions the heads have to go back and forth between the partitions which slows down both operations. Time a copy of a file from 1 partiton to another on the same disk then time it when going between two physical disks (if you're using IDE make sure they're on seperate cables too for best speed) and you'll see a big speed difference.
Click to expand...

Love your spelling. It's as good as your advice.

 
Sorry if I was typing in a hurry and didn't run it through a spell checker, I didn't realize it would be read by an english major with too much free time on his hands.

If you can't atleast attack the content don't bother posting.
 
>Then don't make definative statements that come off as fact, "should be" isn't the same as "I believe".

Any numbers/benchmarks supporting either theory? Any links supporting either theory? If not than either is a belief, not a fact.


 
Benchmarks are pointless, it's too difficult to simulate true, real world usage. They're decent for comparing raw disk speeds for comparing drives, but that's about it.

If you think about it, it makes perfect sense though. Ignoring file caching in memory by the OS the feel of how fast a disk is is governed by seek times because the longest part of every read is the amount of time it takes to position the drive heads. If you take a disk and divide it into, lets say 3, partitions you just created 3 more superblocks, MFTs, FATs, whatever so now when you want to read a file on one of the partitions the disk has to first read the info in the superblock then seek to where the file physically is and read a few sectors. If you use all the partitions actively you've created nearly 3x the work for the disk heads. Most reads during normal usage are a few hundred K because of demand loading of libraries and demand paging of files from disk, large sections of the files aren't read until they're needed at the last minute. So when starting an app up the OS reads say 50K from the main binary, then 50K from each of the necessary support libraries and as you run parts of the binary the rest is loaded from disk and since each read is far below the throughput of the disk's max the only delay is how long it takes to seek to the file.

And for the pagefile the same thing holds true, access to it is done in page size chunks (4K on 32-bit systems) so throughput means nothing with regards to it and if it's on a different partition every time a page is needed to be read or written extra seeks are necessary unless the info is already cached in memory. If the pagefile is in the center of the OS disk A) chances are very good that the MFT info for it its indeed cached and B) chances are good that the disk heads are already close to the file since it's intermixed with all the other files being accessed on the disk.

If you have different physical drives it might be a good idea to put the pagefile there because then access to it won't affect the other disk (unless they're on the same IDE cable) but like I said before, if you're hitting the pagefile enough that it makes a noticable difference where you put it, you need more memory.

The same seek delay principle is the reason why SCSI handle load so much better than IDE disks even though the throughput is comparable, a 15K RPM SCSI3 disk is spinning at over twice the speed of a 7200 RPM IDE disk so seek times are much lower then add on top of that the fact that SCSI controlers are smart enough to support queuing of commands, reordering of those commands for better access times and disconnecting of devices so no one device hogs the wire while others sit idle waiting for more commands.
 
Personally I feel that you SHOULD put a page file on seperate partitions.

It has little to do with performance, that's secondary. Although it can lead to a performance advantage under certian circumstances.

My reasoning goes like this:

It's a good idea to put your data and third party applications on a seperate partition from the system files, for cleanliness, and makes it easier to fix things due to a system failure or corruption.

So you end up with a reasonable size partition for the system files and a large partition for everything else.

Then to a certian extent, the page file doesn't like to give up disk space. I don't remember the details and it's been ages since I last looked into this. But from what I remember once a page file is made to a certian size, parts of it remain there almost perminately.

What you avoid then by having a seperate partition for the system files and the page file is that you can avoid fragmenting the partition space when you have to do things like upgrades, or installing service packs and the like.

This is were you can get a performance advantage. Say 1's= system files, 0's=page file.
Now this is what it looks like when new.
111111111111.11.1..11...000000000000.......................................

Nice and fast page access.
Now you run it like that for a while, but now you have to install service packs, which can increase the size/numbers of the system files considurably. Now your computer is under heavy load.
111111111111.11.1..111100000011101...0.1111..00011000..00...1111

Which can reduce performance and degrade reliablity. Better to have
111111111111..1111.111111....11.11........ (partition)/ 0000000.....0.....

I think that's why it's a good idea to have a seperate partition for page files.

Anyways even if it doesn't improve performance, or even reduces it slightly, it is preferable simply because it keeps things clean. Since you going to have a 100,000 increase in access time for a page file vs main memory, I don't think it makes much of a difference to increase the access time to 105,000 as much time as RAM. It's going to suck no matter what.
 
Then to a certian extent, the page file doesn't like to give up disk space. I don't remember the details and it's been ages since I last looked into this. But from what I remember once a page file is made to a certian size, parts of it remain there almost perminately.
Click to expand...

NT can't shrink a pagefile at runtime, just grow, so it won't shrink back to the minimum size until you reboot. But that's minor, because if you have enough memory you won't be paging enough to grow the pagefile.

I don't think it makes much of a difference to increase the access time to 105,000 as much time as RAM. It's going to suck no matter what.
Click to expand...

That 20% can add up real fast, something that would take 10 minutes now takes 12 or 60 minutes now takes 72 depending on the task of course.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top