A high % Disk Time value is not unusual; a high percentage shows that you
are receiving a good return on your disk investment. But beware, % Disk Time
exceeding 60 percent can lead to increased response times from an overly busy
disk. A problem can occur when the % Disk Time value is high and the Avg. Disk
Queue Length is high or increasing. In this situation, a busy disk is not
handling all of its requests well. When you find a hot spot on a particular disk
subsystem, move some of the associated application files from their current disk
location to another disk that is not as heavily loaded. Then continue to monitor
the disk I/O subsystem to ensure that you haven't created a new disk hot spot.
Another technique that helps isolate disk performance problems, improves
performance, and lowers the head movement rate over the disks is to format only
one logical drive per physical drive. For example, if you have three disk
drives, create only three logical drives, such as C, D, and E.
To improve the performance of your disk drive subsystem, consider matching
the file system Allocation Unit Size to the block size of the application you
are using. For example, suppose SQL Server is using a 4KB block size. When you
format a file system on a new disk drive, launch Disk Administrator, create the
partition, commit the partition changes, select Format, and then set the
Allocation Unit Size to 4096 bytes. Matching the file system block sizes can
improve the efficiency of the disk transfers when you use the application.
For example, if you have four 4KB blocks of data to write to the disk and
the disk is slightly fragmented, you might end up with eight separate 2KB writes
to disk on a file system created with a 2KB Allocation Unit Size. When reading
this file, the disk heads subsequently have to move to eight random locations.
If you use a 4KB Allocation Unit Size, NT Server has to write to disk four
times, and thus the disk heads have to move four separate times to complete a
read of the data. Test your particular Allocation Unit Size configuration to
determine your optimum file system layout, because each application and disk
subsystem environment is a little different.
Another way to improve your disk I/O subsystem performance is to try not to
use it. If you have so much RAM that you need only I/O operations to permanently
save your data, you might not have a problem. But the more power users have
available, the more power they use. As I mentioned in Part 1, on the NT Server
memory subsystem, you can use the Control Panel, Network, Server option to set
how NT Server uses RAM. By appropriately selecting RAM use, you can allocate
more space for the dynamic allocation of the file system cache size. Be aware
that the file system cache competes with other applications for main memory. An
application that is hogging memory--which you can observe in Task Manager,
Processes, as shown in Screen 3--can lower your file system cache hit rate. (You
can observe the system cache hit rate in Perfmon, Cache object.) Obviously, how
you allocate memory is a trade-off between better application performance and
better file system and associated disk I/O performance. You must decide which
goal is more important for your server.
Tuning CPU
To determine whether NT Server has a CPU bottleneck, first ensure that the
system doesn't have a memory bottleneck. If the system is paging
excessively or thrashing because the application or process has insufficient
memory, the system is using CPU cycles to service all the paging transactions.
If you don't find a memory shortfall, look for a CPU bottleneck. Use Perfmon to
observe all processor instances and closely review the counters shown in
Table2.
A high % Processor Time (e.g., 91 percent) does not mean the system has a
processor bottleneck. If the CPU is servicing all the NT Server scheduler
requests without building up the Server Work Queues or the Processor Queue
Length, the CPU is servicing the processes as fast as it can handle them. A
processor bottleneck occurs when the Processor Queue Length is growing; %
Processor Time is high; and memory, the network, or disks don't have
bottlenecks. Thus, when a CPU bottleneck is occurring, the CPU cannot handle the
workload that NT requires because its CPU is running as fast as it can, but
requests are queued waiting for CPU resources.
One way to diminish processor bottlenecks is to move to a faster CPU, which
is particularly helpful if you have predominantly single-threaded applications.
If you have a multiuser system using multithreaded applications, you can
preserve your investment (i.e., not throw out the older CPU when the new one
arrives) by adding processors.
You can also tune CPU performance by using Task Manager to identify the
process that is consuming most of the CPU time and then adjust its priority. A
process starts with a base priority level, and its threads can vary two levels
higher or lower than its base. If you have a busy CPU, you can boost a process's
priority level from Task Manager, Processes. Right-click the process, choose
SetPriority, and then select Realtime, High, Normal, or Low. (Be careful when
you set the processor's priority to Realtime--the process can become selfish and
never release the CPU, possibly making your system unstable.)
By increasing a process's priority, you can ensure that the process will
get more CPU time than the other user applications. The priority change takes
effect immediately, but the process is manual; when you stop the application and
then restart it, the application will return to its original priority. To let
you launch applications from the command line at various priority levels, NT
Server provides the Start command, which you can place in batch scripts that you
run at server startup or directly from a command prompt. To review the Start
command's options, enter
start /? | more
at the command prompt. For more information about the Start command, see Bob
Chronister, "Ask Dr. Bob Your NT Questions,", and Christa
Anderson, "Foreground Application Handling in NT 4.0," June 1997.
Know Where You're Starting
Before you try to tune NT Server, you need to establish a baseline and find
out where the bottlenecks are. The best way to tune your server is to understand
the server hardware, the NT Server operating environment, your network
architecture, and the applications running on your system, because these
components are closely interrelated. Until you know how your system performs
over time, you won't know how much you've improved your NT Server's performance.
End of Article
