<The Problem>

You've been using your computer for some time, and are sitting at your computer, but haven't touched the keyboard for quite a while. Out of the blue, the hard disk light goes into solid activity mode, and stays that way for several minutes.

If you try to do anything, the system response is very sluggish. This is looks like swap (VM paging), but, you think, that can't be - I've got 128 MB of physical RAM! Well, I t hought so too.

Sorry, but in the default configuration of Win 95, this can, and does, happen with any amount of RAM. And even if you know you are pushing hard on the VM system, by default Win 9x doesn't use it very efficiently.

Some of this into may or may not apply to Win 98. The FS caching seems to be improved, and I'd like to think that Microsoft at least fixed the IDE and FDISK bugs, but you never know.

Fixes to Thrashing

1. In C:\Windows\System.ini, find
     [vcache]
   which is usually standing alone. Add 2 lines after it:
     MinFileCache=n
     MaxFileCache=n
   where "n" is a power-of-2 decimal number of Kbytes that is about ¼ of your total physical RAM, such as...
     MinFileCache=8192
     MaxFileCache=8192
   ...on a 32MB system. This forces Win95 to use no more (and no less) than that amount of RAM for disk cache.
   
   This prevents the Windows 95 default behaviour of grabbing nearly all free RAM for file system cache at boot. Yes, by default, file cache gets priority over idle application and data pages (which are swapped), and results in having to thrash while expanding/contracting file cache as well as needlessly swapping idle app pages.
   
   
2. A little more tricky is to do the same thing (define min/max) for the swap file itself.
   
   
   1. Use ControlPanel:System:Performance:VirtualMemory
      (*) Let me specify
        Min=VVVVV
        MAX=VVVVV
      Where VVVV is, in MB, typically 2x-to-4x your physical RAM. This will force the creation of this file at a fixed size, and eliminate the thrashing of periodic growth/garbage collection, and possibly also eliminate the performance hit from swap file fragmentation.
      
      
   2. Extra credit - also specify
        Hard Drive [K:\______]
      where K:\ is ideally a dedicated drive whose size was set (via FDISK or PartitionMagic) to a couple of MB larger than the desired swap size. Failing that, use a non-dedicated drive that rarely gets fragmented. My impression is that the swap file (Win386.swp) gets re-created on each boot-up, and will be created fragmented (many small file chunks) if the target volume doesn't have sufficient contiguous space. A fragmented swap file impairs performance once your demands on memory exceed the available physical RAM.
      
      If you partition any drive, see 2d.
      
      
   3. Web influences.
      
      If the swap file is on the same disk as your Netscape and/or Explorer web page cache/history directories, that disk is probably badly fragmented, and the fixed-size VM file won't be contiguous when it is recreated during each boot-up. Browsers add and delete literally hundreds, if not thousands of tiny files during a typical session.
      
      If you can't move the swapfile, move the caches (in the brower's Preferences or Options menus). Be sure to flush or delete the caches before moving them, or you'll leave all those small orphan files around forever.
      
      
   4. Be careful about FDISK and partitions. On Win95, apply Disktsd.vxd before messing with partitions. I know this applies to IDE disks, and the FDISK problem may also apply to SCSI disks.
      
      
      • Win95 (up through OSR 2.5 as far as I know) has a nasty bug wherein if you Exit to DOS mode, then
          C:\> exit
        back to Win95, your partition tables are corrupt. Almost any operation on any drive will actually be performed on drive C:\, usually destroying it and leaving you with an unbootable system. Apply the patch at URL:
        http://support.microsoft.com/support/kb/articles/q148/8/21.asp
        before even FDISK'ing. his is article Q148821, "Possible Data Loss with LBA and INT13 Extensions", patch file name: DISKTSD.VXD
        
        
      • FDISK has a nasty bug wherein if you make an error while defining a partition layout, and only partially unwind it, it can create a final partition that contains non-existent cylinders. If you make any mistakes, unwind the FDISK session to a completely unpartitioned disk and start over.
        
        As far as I know, this bug is not only not fixed in any version of Win 95, and may exist in Win98 & ME.
        
        If you partition with a reliable 3rd-party utility like PowerQuest Partition Magic®, you won't have this risk, but be advised that once FDISK has laid out a defective partition table, Partition Magic (up through 3.0 anyway) will usually refuse to touch it.
        
        

For further self-education on these and other astonishing Windows design and implementation gaffes, see URL: http://www.annoyances.org