PDA

View Full Version : Swap Files / Partition



Annanz
12-07-2003, 01:29 AM
Reading about swap files http://pcworld.co.nz/PCWorld/tipworld.nsf/UNID/8F3AEB630B9BA4D8CC256D3C007D2912?OpenDocument&Highlight=2,virtual,memory

It says it should be twice as large as your ram. I've got 1 gig of ram. Should make my swap file partition 2 Gigs???

Annanz
12-07-2003, 01:58 AM
Hopefully the above link will work now (http://pcworld.co.nz/PCWorld/tipworld.nsf/UNID/8F3AEB630B9BA4D8CC256D3C007D2912?OpenDocument&Highlight=2,virtual,memory)

godfather
12-07-2003, 02:04 AM
Chances are that with 1 GB of RAM, you will seldom use the swap file so performance gains may be hard to see.

Unless you do a lot of multi-tasking of large applications....

PoWa
12-07-2003, 02:57 AM
Also if you do video editing etc. 512mb should be fine really.

tweak\'e
12-07-2003, 12:38 PM
its an old pc "urban legand". i don't know why they printed that, they certainly know better than that.

go check how much swap file you are useing then set minimum swap file to slightly larger than that. that will stop windows resizing it (make it smaller) while leaving it free to grow if you suddenly use a huge memory hogging program.

kiwibeat
09-08-2003, 11:59 AM
I use 400 min and 400 max on another HDD drive so the swap file doesnt change with 98SE and 512 megs of sd 133 ram

roofus
09-08-2003, 12:41 PM
kwibeat you'd be better setting the minimum at 400 and the maximum as variable, while your running 512 ram, which means you won't use the hard disk much, there still might be that time when you need more than 400MB

kiwibeat
09-08-2003, 03:13 PM
400 megs is fine for most things had it at 600 but never really needed it I have had about 20 windows open at one stage
I also use cacheman as well .
set min max at the same means that the HDD isnt constantly being adjusted by windows

roofus
09-08-2003, 06:00 PM
I think you've mis interpretated how the min and max works.

If you set the page file at a min of 400 then the windows isn't going to be swapping and changing the size of it, if you were to be using more than 400 at a cetain time windows could expand it to suit its needs, then when its finished it would revert back to the original 400.

However the way you proposes sets it at one size and it can't grow, which would result in a crash if it was potentially breached.
Your right having 20 windows open isn't going to blow it, but that time you decided to manipulate an image or audio, you might just need a pagefile of 401MB :-)

agent
09-08-2003, 06:05 PM
For [insert words] sake!

I would've thought IDG would do some research first.

Firstly, creating a separate partition to store your swapfile (and nothing else) does not speed up your system, it slows it down. While the swapfile will be less fragmented, the time needed for the drive head to move across partitions beats the benefits of this.

You should partition your drive so the OS and swapfile are located on the first partition - the one closest to the edge of the drives, so access time is quicker. Further partitions should be located further in according to how often they will be accessed - for example, a backup partition should go last, and documents, files, etc somewhere in the middle.

Furthermore, swapfile space should be approximately 1.5x the amount of RAM you have. So, if you had 512MB of RAM, you would want to set the maximum swapfile size to 768MB. What goes into the swapfile eventually winds up back in the RAM, so setting a large swapfile means you'll be trying to put in more data than the RAM can handle - slowing down your system.

Also, on larger HDDs, you shouldn't leave the cluster size at 4K - make it 64, because larger clusters can be accessed faster, but don't go too large. Thirdparty tools may not work with larger cluster sizes, however, and they are only really necessary when you are storing large files (such as doing movie editing, or backing up CDs).

Perhaps you would like to force Windows to defrag your drives properly - a registry tweak is in need. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro l\FileSystem. Create a DWORD value called ContigFileAllocSize and set the value to 512 (decimal).

Also, while NTFS has it's benefits, it is better to make the OS/swapfile partition NTFS and the rest FAT32 - as FAT32 is faster in general.

Most people never use the NTFS last accessed filestamp, so perhaps you'd like to remove that, too. HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro l\FileSystem. DWORD value named 'NtfsDisableLastAccessUpdate', and value to 1 (hexadecimal). Remember to reboot after making registry modifications.

I'll say a large thanks to APC for those tips.

agent
09-08-2003, 06:07 PM
I really did not expect to see some bad advice like that in the link up the top of this thread from IDG.

Rod ger
09-08-2003, 06:55 PM
Hi, I'm of the opinion that you "try it and see" .
I've got a smallHD and 192Mb Ram on W98 and originally set max/min to 400Mb and then gradually reduced it til its now sitting at 75Mb max/min and it runs fine. I'm not a power user, but have done a lot of restoring images from old family photos (b&w) and never had any problems. I guess its just storage that you can ajust to your needs.

bmason
09-08-2003, 09:06 PM
I've never seen any benchmarks to back up any claims related to swapfile optimisation. Most of them seem to be based on assumptions about how windows works.

For example: what if windows writes to the file directly, bypassing the filesystem to improve performance. This would make seperate partitions, cluster sizes etc ineffective.

IMO if you have to tweak it, set a reasonable minimum size. It will stop it from being resized most of the time which should be noticeable.

Anything beyond that is most likely a waste of time.

agent
10-08-2003, 11:28 AM
If Windows were to skip around the filesystem, that would imply it knows (and places) the swapfile in a set location, and it never gets moved from there (or else Windows wouldn't know where it was) - highly unlikely, if you ask me.

The swapfile can get fragmented because it is not in one set physical location on the HDD - and while placing it in a partition of its own reduces this, it also reduces access time to the swapfile, and a hard drive is substantially slower than memory - you'd be slowing down your entire system.

agent
10-08-2003, 11:29 AM
Sorry, I meant to say "it also increases access time to the swapfile".

tweak\'e
10-08-2003, 11:42 AM
i'm not to sure that having the swap file on a seperate partition would increase the access time. the whole point of having a swapfile partition is (just like linux) keeps the swapfile from fragmenting and has it on the fastest part of the disk. i've seen a few pc's that after a defrag (exspecially when the swapfile was deleted and then remade) the pc is slower. this is simply due to the swapfile being at the slow end of the disk (and the lack of ram ;-) ).

bmason
10-08-2003, 06:16 PM
> If Windows were to skip around the filesystem, that
> would imply it knows (and places) the swapfile in a
> set location, and it never gets moved from there (or
> else Windows wouldn't know where it was) - highly
> unlikely, if you ask me.

I can't think of any reason why it couldn't map out what parts of the disk the swapfile covers. It should be as simple as looking in the FAT.

Anyway, my point was we don't know how it works and what tricks windows uses. All these ideas for performance improvements really need to be benchmarked. Currently they are just theories. If anyone can find some I would be interested.

> The swapfile can get fragmented because it is not in
> one set physical location on the HDD - and while
> placing it in a partition of its own reduces this, it
> also reduces access time to the swapfile, and a hard
> drive is substantially slower than memory - you'd be
> slowing down your entire system.

But it generally doesn't move most of it. Windows 95 was quite bad at fragmenting the end of it because the size of the file was kept close to the in-use size. Win98 and later don't resize it anywhere as much.

As for its location on the disk, it is slower but not hugely. I think its more in sequential throughput rather than seek times. Again, I would really like to see a benchmark on how much affect this actually has.