Hi :)
wrt Virtual Memory/pagefile.sys/Swap on Windows the trick seems to be to set it as a fixed value.
Find
"System Properties" - Advanced tab - Performance (top 3rd) Settings - Performance Settings - Advanced tab here too - Virtual Memory (bottom section) Change
There will be about 3 pop-ups open around now.
Use the radio buttons there to change to a "Custom size". This really needs to be greater than Ram but not more than 2xRam (else it gets confused and may even reduce performance while tripping over it's own shoelaces). It has to be greater than Ram because when hibernating (perhaps sleeping too?) the contents of Ram gets written to Virtual Memory. But giving it too much just confuses space just confuses things so just under 2xRam is good but over that might get annoying. Make sure the same number is in both the top and bottom boxes. Often there is a recommendation for how much to set it too and it's usually not a bad idea to follow that advice. I've only seen it give a crazy suggestion once or twice out of hundreds of machines.
Ok, now it gets a bit fiddly. You have to click on the "Set" button before clicking on "Ok" otherwise it forgets and you have to re-type the numbers again. Then you click "Ok" on each of the pop-ups in turn. Again if you don't it's not harmful, just annoying because it forgets.
Of course if you have already been using your machine for a while then Virtual Memory is already quite fragmented so this will only 'stop' it getting worse. It wont improve things. Also when i say 'stop' it will continue to suffer normal system rot and there are other factors such as registry fragmentation that will continue. So, it fixes just 1 problem out of many.
When trying to resurrect an ancient and much used machine i would initially set Virtual Memory to 0. Then defrag quite a lot and then plonk a fairly huge file onto the system. Then reset the Virtual Memory to a respectable size and get rid of the huge file. In theory i hoped that would force all the Virtual Memory file to be contiguous and out of the way.
Gnu&Linux does NOT SUFFER from fragmentation until the drive is something like 96% full, not sure of the exact figure but definitely over 90% (it's always that extra just 1 episode/movie of Star Trek). Files might well be fragmented much lower than that despite the elegant way that files are carefully placed in Ext2,3,4 with plenty of room all around them to allow them to grow. There is a limit to how much that policy can really work of course. However even when files are fragmented there seems to be a better system for tracking where all the bits are so the read/write head can anticipate and plan ahead a bit better.
So what i find odd is that despite that Gnu&Linux doesn't use a Swap file by default! One of the main rules in Gnu&Linux is that for any 'rule' there is always at least 1 version or distro or something that deliberately breaks that rule but in the case of Swap i haven't found one yet. They all seem to follow it! They all seem to use a separate Swap partition or don't use Swap at all.
In Windows, which can't cope with fragmented files and couldn't (until fairly recently) defrag system files people insist on setting Virtual Memory to fragment as quickly as possible. Sometimes they set it to have a fixed lower amount and only vary the top-off but that still means the file gets read and re-written elsewhere and fragmented.
Normally by default it's set to keep changing size according to how much of it is needed. That sounds good in theory. When you need more memory it just expands to fill up more hard-drive space when you need less it releases some of it. You can get Gnu&Linux to use a swap-file just the same instead (or as well as) having a separate fixed swap partition. Unfortunately Windows file-systems such as the various Fats (vFat, Fat32 etc) and Ntfs are carefully designed to make sure files fragment quite quickly and end up with bits scattered all over the place.
Say you have file A that is 20units long and the next file B is 10. Then you delete A and write a file C that is 30 units. Now you have 20units of C followed by 10 units of B followed by the remaining 10 of C. If you now delete B and copy A back then you get 20 of C, followed by 10 of A followed by the 10 remaining of C and then the last 10 of A. So when you try reading a file the read/write head lurches around the drive trying to find the various shopped up parts of the file. If that file is a frequently accessed system file such as Virtual Memory then it can significantly reduce performance.
In Gnu&Linux it is reckoned that you can significantly increase performance by putting your system files, particularly your log files, on a different hard-drive from your data. i mean a proper hard-drive not just a different partition on the same physical device. The main reason for putting your data (all in /home) on a separate partition is not to do with routine performance. it's more about making the system more robust. it allows you to install a completely new OS without any risk to your data (but still back-up anyway of course). In theory you can have several different OSes all using the same /home although that gets a bit messy if they have the same DE. it works a bit better if you have 1 KDE one, 1 Gnome(ish), and maybe 1 of any of the rarer ones (does Unity count as 1 of the rarer ones? i'd say it does but i'm sure others disagree). Otherwise you find all your different OSes use the same wallpaper and look the same (big yawn that
is) and you don't get the benefit of the different design teams interesting work.
Something i haven't really tried much, or at least can't remember the result, is putting all the Virtual Memory on a separate physical hard-drive. There is an option to split Virtual Memory across several different hard-drives/partitions some of which might be physically different drives but i'm not sure whether doing that is good or bad.
Errr, i haven't mentioned Bsd or Apple because i just haven't played around with them that much. They don't seem to slow down as much as Windows so i guess they have a similar set-up to Gnu&Linux or have some neat work-around that might not translate well to Gnu&Linux let alone Windows.
Regards from
Tom 