On 18 Oct 2006 at 8:42, Thomas Mayer wrote:

> David
> 
> I believe you meant to put a negative somewhere in the first sentence of 
> your reply. In essence the swap file will become more fragmented if you 
> let windows manage it rather than the procedure you use in limiting the 
> minimum and maximum size of the swap file.

  No, I said what I meant.  Fragmentation requires the interaction of TWO 
mecahnisms:  the growing and shrinking of the file, and the creation and 
destruction of OTHER files.  If the swap file has a partition all to itself, 
that second mechanism never applies to that partition, and so the fact that 
the swap file is growing and shrinking doesn't lead to fragmentation.

> Also, I believe that 4GB is way too large for a swap file. I have found 
> that even though I have plenty of physical RAM, windows will still 
> utilize the swap file (no matter what MS indicates to the contrary).

  IF there is a swap file, then Windows MUST allocate space in it whenever 
any process allocates memory.  I don't know what you've seen from Microsoft 
that led you to believe anything different.

> And the larger the swap file size, the more windows will use it
> instead of physical RAM. 

  Swap file is used "instead of" physical RAM only when there isn't enough 
physical RAM.  It is normally used WITH physical RAM.

> The rule of thumb to double the RAM is probably good up to 
> about 512MB of RAM, but if there is more physical RAM, the size of the 
> swap file can be reduced to force windows to use the faster physical RAM 
> before it uses the swap file. I have experimented with not having a swap 
> file and everything runs fine with the exception of one program that for 
> some reason requires a swap file. Also, I have one video editing program 
> that requires the swap file to be less than 64MB so that windows does 
> not slow the program down by using the swap file.

  That makes no sense to me.

  When a running program needs RAM, it is requested from the OS.  IF it is 
RAM to hold code, a chunk of virtual memory is allocated and mapped to the 
chunk of executable file (.EXE, .DLL, or whatever), and then that virtual 
space is mapped to physical RAM and the file chunk is copied from the disk.  
IF the OS needs that physical space for something else, it will update the 
map so that the next time it needs that chunk of code (same virtual memory) 
it will map it to another available chunk of physical RAM and read it from 
disk again.  (Obviously, you'll get better performance if you have enough 
RAM to minimize this happening.)
  If the RAM is to hold data, then there is no preexisting chunk of disk to 
back it up.  If there is a swap file, Windows will allocate a chunk of it to 
back up the virtual memory allocated for that data space.  (The request for 
space will FAIL "out of memory" if there is a swap file but it is full and 
cannot grow.)  Because this is data, temporarily reallocating that physical 
RAM for anything else requires writing the current data out to the swap 
file, so this is a bit slower than re-using RAM holding code.  If there is 
no swap file, the space is just allocated in physical RAM, and when that's 
full, that's the end.
  Both code and data chunks *can* be marked "do not swap" for performance 
reasons.  Most applications rarely resort to this, since Windows does an 
acceptable job of managing this and excessive swapping can be reduced by 
adding more physical RAM.
  (The "working set" of a program is the amount of code and data it needs to 
keep in physical RAM to provide reasonable performance.  For instance, a 
word processor might keep basic editting functions and the current page in 
physical RAM, and load printing code or other pages from disk only as 
needed.)

  What causes Windows to "use the swap file more" is "not enough physical 
RAM for the application load" and NOT "too big a swap file".  (All rules of 
thumb about deriving swap file size from installed RAM size *assume* that 
the installed RAM is about right for the application load on the machine.  I 
don't think there's any real foundation for that assumption.)
  I can't guess why you have an application that requires a swap file, and 
one that requires that it be less than 64MB; my inclination is to think that 
they may have been written by people who didn't understand how this works.  

David Gillett


> David Gillett wrote:
> > On 18 Oct 2006 at 13:11, Laurie wrote:
> >
> >   
> >> Is there any advantage to having the swap file on a seperate partition?
> >> Does it reduce the tendency to fragment?
> >>
> >>     
> 
> >>   Putting the swap file on a separate partition will reduce fragmentation 
> >> ONLY if you have left it at the default "let Windows manage it" 
> >> configuration, where it will grow and shrink as needed.  I routinely 
> >> statically allocate it to a specific size, so that doesn't happen, and so 
> >> Windows has no need to change which disk blocks it uses.
> >>
> >>   The obvious next question is "How big should that static size be?", and 
> >> the traditional rule of thumb has been to calculate its size based on the 
> >> amount of physical RAM in the machine.  That *assumes* that the amount of 
> >> phusical RAM present reflects the needs of your OS and typical application 
> >> load -- which it doesn't necessarily.
> >>   In XP, the swap file has a maximum size of 4GB, which happens also to be 
> >> the maximum physical address space of a 32-bit CPU.  That's more than enough 
> >> for most people, and hard drive space is getting incredibly cheap.  (The 
> >> last 200GB drive I bought cost $55.)  So for now I'd just set it to 4GB -- 
> >> split across several drives (*) -- and not worry about whether that's more 
> >> than is really needed.

        The NOSPIN Group has added a new feature on our website,
           web based bulletinboard for questions and answers:
              Visit our sister website at http://nospin.com