Downloads
7608.zip

Tweak your Windows 2000 system's memory

Like many Windows NT users, I wondered how much I'd need to upgrade my hardware to run Windows 2000 Professional (Win2K Pro). My AST Bravo MS-T 6200 with a 200MHz Pentium Pro processor had just 32MB of RAM, which wasn't even enough for NT 4.0 to meet my performance needs. Win2K Pro requires a minimum of 64MB of RAM, so my initial plan was to add 32MB to my system. However, I discovered that I could get 64MB of Enhanced Data Output (EDO) RAM on two 96-pin SIMMs, which fit in two open slots on my motherboard. That amount, combined with the existing 32MB, gave my system a total of 96MB of RAM. I figured that 50 percent more RAM than Microsoft recommends would provide the Win2K Pro performance I was looking for.

After some testing, I was able to confirm that I put enough RAM on my system for Win2K Pro to meet my performance needs. In this column, I tell you how I discovered how much RAM my system needed to efficiently run Win2K Pro, and I show you the performance effect of moving your Windows 2000 (Win2K) system's virtual memory paging file.

Test for Success
To find out how much RAM I needed on my Win2K Pro system, I used a stopwatch to time how long my system took to log me on and get the applications in my startup folder running using different amounts of RAM. The applications in my startup folder include Microsoft ActiveSync 3.0, Notepad, Outlook 98, and DUN. I logged off and on a few times to get a stable time for each amount of RAM, although logging on the second time was much faster because Win2K Pro had cached most of the programs and data in memory.

After I timed this process with 96MB of RAM on my system, I had to repeat the process with less RAM on my system and examine the resulting elapsed time vs. installed RAM curve. To designate how much memory of the 96MB Win2K Pro would use, I used the /MAXMEM switch to add new entries to the boot.ini file in the root of my C drive, as Listing 1 shows. This listing tells Win2K Pro to ignore RAM above the threshold value you set.

When I started my tests, the paging file was on the D drive. As the blue line in Figure 1, page 156, shows, my results were nothing to write home about. After I increased the amount of RAM to 64MB, logging on and launching the applications took one-third of the time, and at 96MB the process took less than one-fourth of the time it did with 32MB of RAM. The time difference between 80MB and 96MB was minimal, so 80MB is probably enough RAM on my Win2K Pro system to meet my performance needs. However, my tests revealed that 64MB isn't enough RAM for Win2K Pro to meet my performance needs.

Paging File Settings
The other lines in Figure 1 record the effect of moving Win2K Pro's virtual memory paging file. To understand why the location of the paging file affects performance, let's review the way Win2K and NT manage virtual memory.

The OSs try to keep everything in RAM, but when everything doesn't fit, the OSs swap the least recently used memory pages to the hard disk, storing them in the paging file. When a user requires the swapped pages, the OSs load the swapped pages back into RAM and swap other pages to make room for the pages the user needs. Therefore, where you put the paging file is important and affects performance.

I tested the effect of moving Win2K Pro's virtual memory paging file to a hard disk separate from the OS (i.e., drive F) and running two paging files, one on the D drive and the other on the F drive. These drives are physically separate—not just two partitions on the same drive.

As the red line in Figure 1 shows, putting the paging file on a separate disk from the OS made a big difference on a system with limited RAM. With 32MB on the system, having the paging file on the F drive cut the logon and application startup time by almost one-third. However, the time benefit falls off as you add RAM: With 64MB of RAM, the paging file on the F drive was about 1 second faster than the paging file on the D drive, and there was no time difference at 96MB of RAM.

Setting up multiple paging files on physically separate drives cut the paging file size from 142MB to 71MB on each drive. With 32MB on the system, the results fell somewhere between having the paging file on the D drive and having the paging file on the F drive, as the yellow line in Figure 1 shows. This effect is a result of limited RAM.

When RAM is limited, the system spends almost as much time writing to the paging file as it does reading from it. As a result, writing to the paging file on the D drive caused excess head motion as the disk head switched between the system files it was reading from and the paging files it was writing to. When more RAM is available, the system can use the two drives to read from the paging file twice as fast as it can read from the paging file using one drive.

With 64MB of RAM, splitting the paging file on two drives cut the load time about 15 percent. At 96MB, the system was 1 second faster when paging files were on both drives, as compared with only one paging file.

To tune your paging file, check the Control Panel System applet's virtual memory settings. For NT 4.0 systems, select the Performance tab, then click Change. For Win2K Pro systems, select the Advanced tab, click Performance Options, and click Change in the resulting dialog box. Both Win2K and NT will provide a Virtual Memory dialog box that lists all paging files on all drives. Screen 1 shows this dialog box. For each drive or partition, you can create a paging file with an initial size and a maximum size.

If the current size of your paging file is larger than its initial size, it's probably fragmented. Win2K's built-in defragmenter won't defragment the paging file but will defragment free space. To use Win2K's defragmenter to defragment your paging file, find a partition with enough space to hold the paging file, defragment the partition, and move the paging file to the defragmented partition. You can then defragment the original partition. Alternatively, you can use Executive Software's Diskeeper to defragment your paging files.