Is there any noticable difference to putting the 1.5x size of RAM swap file on a different HDD than the OS (specifically XP)?
Swap file location
- Thread starter Monkey muppet
- Start date
In my opinion, yes it makes a difference.
I usually place the swap file (virtual memory/page file/whatever) in it's own partition (or drive), seperate from the OS and lock it at min/max 1.5 X physical ram. Why?
Well, going back to Win9x, and WinNT I was constantly fighting with fragmented files. Placing the swap file on a seperate partition or drive helped cut down on fragmenting (especially once the size was locked). It also allowed me to defrag my drive using the earlier "Disk Defragmenter" that came with both OSes (I'm too cheap to buy a 3rd party app), as resizing or writing to the file by the OS caused the defrag to restart from the beginning.
Secondly, fixing the size seemed to cut down on delays caused by the OS inflating/deflating the file when memory demands changed.
XP may be better at managing the page file, but I don't care to try.
I usually place the swap file (virtual memory/page file/whatever) in it's own partition (or drive), seperate from the OS and lock it at min/max 1.5 X physical ram. Why?
Well, going back to Win9x, and WinNT I was constantly fighting with fragmented files. Placing the swap file on a seperate partition or drive helped cut down on fragmenting (especially once the size was locked). It also allowed me to defrag my drive using the earlier "Disk Defragmenter" that came with both OSes (I'm too cheap to buy a 3rd party app), as resizing or writing to the file by the OS caused the defrag to restart from the beginning.
Secondly, fixing the size seemed to cut down on delays caused by the OS inflating/deflating the file when memory demands changed.
XP may be better at managing the page file, but I don't care to try.
rule of thumb is the manufacturers recommended size for a pagefile placed on the MOST USED partition of the LEAST used HDD.
EDIT: and locking the size eliminates fragmentation.
EDIT: and locking the size eliminates fragmentation.
Yes, you will be unable to obtain a memory dump for crash analysis.
Please search on this topic. I has probably been covered at least 20 times this year alone. Thanks.
Not only that but fragmentation (internally since it is a sparse file or externally) is irrelevant. Unless it is extremely fragmented, fragmentation will make no difference. The page file isn't sequentially read and is only read in up to 64kb chunks of data at a time.
You could just have two swap files, one on the OS partition and one on the second drive at a much larger size. Windows should be able to determine who has better performance(the second page file, in theory) and use that for actual paging operations. Then if you get a BSoD, you should be able to capture the dump. Viola(sic)
Nothinman
Elite Member
- Sep 14, 2001
- 30,672
- 0
- 0
And it also increased seek time delays because every time the pagefile was accessed the heads would have to seek over to the other partition and then back again to get to the data.
Windows never shrinks the pagefile, it only expands it. So any delays that you accounting to the pagefile changing sizes were most likely something else.
Windows XP actually moves this further to the center of the disk by default. This lowers the penalty of movement of a swap at either "end" of the disk to data on the other side.
And for some reason you know where the operating system is placing the data to begin with? Partitions are the only way you can force data sets into particular zones on the disk.
Nothinman
Elite Member
- Sep 14, 2001
- 30,672
- 0
- 0
You can't guess where any paging to/from will happen reliably. If you're actually hitting the pagefile then you're surely also dropping non-modified binaries and shared-libraries so when the OS goes to page them back in it'll be jumping all over the disk because you'll be paging in data from the binaries and shared libraries, the registry, data files that are open, the pagefile itself, etc.
Again depending on partitions single or more, you cannot rely on the notion that your data will be organized in a logical manner to avoid wasted seek times. Zoning data sets by themselves is the only thing you can do to guarantee certain levels of performance. Additionally any actuator contention is going to hurt disk performance. In the typical desktop system, you are going to use paging operations. It seems a bit strange to think by making the swap on a most used partition on a disk will guarantee some performance benefit. Going back to partition setup, you have no way of guaranteeing that the data sets are any closer to the page file. Even if the page file is on the most used partition. So much administrator overhead would go into figuring average seeks from the requested data sets to paging file. How large would the partition be for acceptable performance? Could the Page File be moved closer to the outer edge for better overall performance? Is the most accessed data in a zone towards the inner portion of the disk?
A lot more has to be answered than a blanket statement of most used partition of least used disk. In the end it's debating single disk configuration and there isn't a lot of room for performance gains in that arena.
A lot more has to be answered than a blanket statement of most used partition of least used disk. In the end it's debating single disk configuration and there isn't a lot of room for performance gains in that arena.
Nothinman
Elite Member
- Sep 14, 2001
- 30,672
- 0
- 0
In a lot of cases zoning data won't help performance either because you'll just end up seeking between zones which will hurt performance. And in any system you're going to use paging operations, it's the only way that the kernel knows how to get data from some medium into memory. You can tweak how the paging happens by doing things like non-buffered I/O or reading the entire file once to make sure it's in cache, but that's about it.
No administration overhead should go into this, all you should have to do is "leave it be" or if you have another physical disk to put the pagefile on that's seperate from the OS and from your data, go for it. But if the pagefile is affecting performance that much, you need to buy more memory and no amount of tweaking can change that.
No administration overhead should go into this, all you should have to do is "leave it be" or if you have another physical disk to put the pagefile on that's seperate from the OS and from your data, go for it. But if the pagefile is affecting performance that much, you need to buy more memory and no amount of tweaking can change that.
if this was a realworld noticable performance boost, no one would argue about it. i put it on my raptor drive and still didnt notice a thing, i get exact same fps in games, os runs the same so who cares what some number in a benchmark says assuming it says any different.
The only performance "gain" is moving to another disk. The gain being, that you aren't causing performance degradation on the boot volume.
@Nothinman, I'm talking about zoning data that requires the fastest seek times to the outer edges. If you check out HDTach, you can see where a sudden drop in disk throughput comes into play. You could partition from the edge to that point where performance starts to drop off, and gaurantee you will have the fastest overall performance in that region of space. This will also force the average seeks to go down as the disk is not seeking against the entire volume. The operative word is overall, as you can never guarantee the system will only use this disk space, unless you only use the small partitioned area. Though like I said, once you start to talk about overall performance rather than significant results it's almost a moot point to tweak. Though if one was inclined there are ways off laying out data sets to get the most overall optimal performance.
@Nothinman, I'm talking about zoning data that requires the fastest seek times to the outer edges. If you check out HDTach, you can see where a sudden drop in disk throughput comes into play. You could partition from the edge to that point where performance starts to drop off, and gaurantee you will have the fastest overall performance in that region of space. This will also force the average seeks to go down as the disk is not seeking against the entire volume. The operative word is overall, as you can never guarantee the system will only use this disk space, unless you only use the small partitioned area. Though like I said, once you start to talk about overall performance rather than significant results it's almost a moot point to tweak. Though if one was inclined there are ways off laying out data sets to get the most overall optimal performance.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 24K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 20K
-
-
-
Facebook
Twitter