Troubleshooting I/O Transfers

 

If you have a disk problem, you may want to determine what is causing the I/O bottleneck. To do this, you would:

  1. Identify the drive on which the I/O is occurring. If you separate the Exchange files onto separate volumes, you can more easily identify if it is the paging file, the directory database (.edb) file, the Exchange streaming database (.stm) file, the log (.log) files, or the routing queue files that are causing the I/O.

    By looking at the following counters, it is possible to understand how many I/Os are going to .edb files as compared to those going to .log files:

    Database\Database Pages Written/sec Database\Log Writes/sec

    To help determine which process is causing the disk I/O, you can use these counters:

    Process(process name)\IO Read Operations/sec Process(process name)\IO Write Operations/sec

  2. Use the Sysinternals Filemon tool to determine which files are showing I/O activity. Choose the logical disks that need investigation and show all disk reads and writes. This is particularly useful for multi-use disks, such as C:\, which may have several major files that are used by the system or applications.

    The following figure shows a listing generated by Filemon for all the reads and writes to a disk.

    Listing of disk read and writes produced by Filemon

    4f53b6d0-a9c1-4dee-9d7a-f3c361927f0c

Troubleshooting Processor Utilization

You should determine what is consuming the CPU. The counters below are the most likely suspects for this problem, from most likely first to least likely fourth.

Process(STORE)\% Processor Time Process(inetinfo)\% Processor Time Process(EMSMTA)\% Processor Time Process(System)\% Processor Time

Note

Process counters count 100% for each CPU on the server. On an eight-processor computer, the value of each of the processor counters above would be between 0percent and 800%.

The following figure shows a histogram view of the processes that are most likely to consume the CPU. In this figure, the Store.exe process is using up most of the CPU. If you suspect that other processes in addition to the four most likely may be hanging up the CPU, include them in this histogram view.

A histogram view of processes most likely to consume the CPU

5c123779-469e-4e35-bd4c-2247404f6e42

Note

Looking at multiple counters in the histogram view of System Monitor (the graphing component of the Performance snap-in) is a quick way to isolate the counter indicating a problem.

Troubleshooting Memory Utilization

To determine where memory is being used, the following counters are the most likely suspects for memory consumption:

Process(process name)\Private Bytes Database\Database Cache Size

The Store.exe process indicated by the Process(STORE.EXE)\Private Bytes counter tends to consume most of the committed bytes.

Troubleshooting Network Utilization

If client traffic is experiencing unexpected network traffic (such as heavy traffic when no clients are connected), you can use Network Monitor to examine the traffic. Network Monitor is a network diagnostic tool that monitors LANs and provides a graphical display of network statistics. While collecting information from the network's data stream, Network Monitor displays the following types of information:

  • The source address of the computer that sent a frame to the network (this address is a unique hexadecimal (or base-16) number that identifies that computer on the network).

  • The destination address of the computer that received the frame.

  • The protocols used to send the frame.

  • The data or a portion of the message being sent.

The process by which Network Monitor collects this information is called "capturing." By default, Network Monitor gathers statistics on all the frames it detects on the network into a capture buffer, which is a reserved storage area in memory. To capture statistics on only a specific subset of frames, you can single out these frames by designing a capture filter. When you have finished capturing information, you can design a display filter to specify how much of the captured information is displayed in the Frame Viewer window of Network Monitor.

To use Network Monitor, your computer must have a network card that supports promiscuous mode. If you are using Network Monitor on a remote machine, the local workstation does not need a network adapter card that supports promiscuous mode, but the remote computer does.

Once data has been captured either locally or remotely, the data can be saved to a text or a capture file, and can be opened and examined later.

Note

To fully troubleshoot possible network issues using Network Monitor, consider configuring Network Monitor to capture not only what the client sends and receives, but also what the server is sending and receiving. Doing both a client-side and server-side trace of network traffic helps you troubleshoot network issues more thoroughly.