RSS
  Tuni ng NT: Is It Worth Your Time? |
|
Our Findings
Generally, adjustments to NT made via its GUI tools or in the registry did not offer significant enhancements to database performance or file throughput. Regardless of the memory-optimization settings we made, we did not see significantly better throughput or average response time over the 20, 35 and 50 motors used. However, we did find that the placement of the virtual memory swap file has a notable impact on database performance. And it was no surprise that adding memory substantially increased the performance of our SQL database.
To illustrate the point regarding RAM usage, we ran SQL Server on our server configured with 96 and 256 MB of RAM. As you can see in "Database Read Test" (at left), we found a dramatic increase in SQL performance when we increased the RAM from 96 MB to 256 MB . Our data set was approximately 750 MB in size. Oddly enough, we found the most dramatic impacts on NT performance were made simply by tailoring NT's run-time environment to its dedicated task. NT caters to the masses and runs many services by default. A number of these services are unnecessary for specific tasks (see "Services That Can Be Stopped," page 128). By disabling the unnecessary services, we freed almost 4 MB of RAM. Although this may not seem like much, every little bit helps.
The next set of gains were realized when we configured the server to use two swap files, each on a separate external SCSI disk. Intuition dictates that the fastest performing physical disk generally will result in the best paging performance. When we ran our tests with the swap file on the RAID array, for example, the disk queue length averaged nearly zero. The higher performing RAID array, with 32 MB of cache, 9,600 RPM drives and UltraSCSI device chain, was able to service disk requests much faster than the external SCSI disks. Yet our results clearly indicate that NT benefits from the ability to distribute swap files across multiple devices. In this case, NT takes advantage of the asynchronous I/O between matched (identical make and model) disk devices. This is a huge benefit for such a critical resource (virtual memory), but this should not be viewed as a substitute for real memory. During testing, we learned an important lesson. Don't make broad assumptions about your se rver and potential bottlenecks. A system bottleneck often is not where you think it is. This is why tools like Performance Monitor are essential. By running a series of tests and changing system parameters, Performance Monitor let us quantitatively and objectively pinpoint system bottlenecks.
|
 |
 |
|
Other Workshops
|
