Windows NT Performance Monitor

Windows NT Performance Monitor

Performance Monitor is a graphical tool for measuring the performance of Windows NT computers on a network. You can view the behaviour of objects on any NT or Windows 2000 computer, such as processors, memory, cache, threads, and processes.

Each of these objects has an associated set of counters that provide information about device usage, queue lengths, delays, and information used to measure throughput and internal congestion.

We use the information in a couple of different ways. Data gathered by Performance monitor is used to both show where problems occur on a system, assist with capacity planning, and to gather information about a network server's performance over time to ensure that the network responds efficiently to customer needs.

Performance monitor provides charting, alerting, and reporting capabilities that reflect both current activity and ongoing logging. You can open, browse, and produce charts from log files later as if they reflected current activity.

Alerts are used to provide immediate notification if a parameter you are monitoring exceeds a defined range, for example, if you could use performance monitor to monitor the components of your email server you could tell it to raise an alert to inform you if outbound SMTP messages exceeded a certain value this would be your warning that there was a possible communications problem with your ISP or upstream network provider.

Report view simply shows Objects and Counters in a report format. However, for the purposes of this course, we are concerned with charting and logging.

See Fig.1 for an example of Performance Monitor in action.

Performance Monitor Features

The following overview lists how you use Performance Monitor to view the performance of objects:

• Simultaneously view data from any number of computers, allowing you to compare and contrast the same performance counters on different machines at once.
• Export data from charts, logs, alert logs, and reports to spreadsheet or database programs for further manipulation and printing.
• Add system alerts that list events in the Alert Log and notify you either by reverting to Alert view, logging the event in Event Viewer's Application log, or issuing a network alert. This concept is exploited in SQL server, for example, where a SQL server agent monitors counters (and the event log) to take corrective action if an error condition arises.
• Run a predefined program either every time or only the first time a counter value goes over or under a user-defined value. An example of this would be a script to tidy up disk space on a public volume being triggered if the disk was to become too full.
• Create log files containing data about objects on different computers.
• Append selected sections of existing log files to a single file, forming a long-term archive.
• View current-activity reports or create reports from existing log files.
• Save individual chart, alert, log, and report settings, or save the entire workspace set up to reuse when needed. Think of this as setting up a template for future use, important when doing long term monitoring as it's important to make sure that you are always comparing "like with like

Objects, instances, and counters, the building blocks of Performance Monitor

When monitoring a system, you are actually monitoring the behaviour of its objects. In the Windows NT operating system, an object is a standard mechanism for identifying and using a system resource, individual processes, sections of shared memory, and physical devices.

Performance Monitor groups the counters by object type. A unique set of counters exists for the processor, memory, cache, hard disk, processes, and other object types. Certain object types and their respective counters are present on all systems. However, other counters, such as such as Exchange, IIS or SQL server objects appear only if the computer is running the associated software.

Each object type can have several instances. For example, the Processor object type will have multiple instances if a system has multiple processors. If an object has more than one instance it is common to be able to monitor each instance individually and/or view a "total" of all the instances.

Two object types, Process and Thread, have a particularly close relationship. A Windows NT process is created when a program runs. A process may be an application (such as Microsoft Word or Corel Draw), a service (such as Event Log or Computer Browser), or a subsystem (such as the print spooler or POSIX).

In addition to an executable program, every process consists of a set of virtual-memory addresses and at least one thread.Threads are objects within processes that execute program instructions. They allow concurrent operations within a process and enable one process to simultaneously execute different parts of its program on different processors. Each thread running on a system shows up as an instance for the Thread object type and is identified by association with its parent process. For example, if Print Manager has two active threads, Performance Monitor identifies them as Thread object instances Printman ==> 0 and Printman ==> 1.

Working with Information on Current Activity

To work in any view with information on current activity

1 On the File menu, click New to open a new settings file. Or, click Open for an existing settings file.
2 On the Edit menu, click Add To or Edit. The Add to dialog box or Edit dialog box appears (fig 2).
3 Select, change, and then save settings for one or more computers and the appropriate objects, counters, and instances.
4 On the File menu, click Save Settings As to save selections in a new settings file. Or click Save Settings to update the current settings file.
5 On the View menu, click Chart, Alert, Log, or Report to change settings for another window; then repeat steps 2 through 4 until you have the settings you want.

• If you have related information in all four windows, click Save Workspace on the File menu to save the current settings for all four windows.
• You can open a separate chart (.pmc), alert (.pma), log (.pml), or report (.pmr) settings file, or a workspace (.pmw) file that contains settings for all four windows.

Charting Current activity

To view the Chart window

On the View menu, click Chart.

To open an existing chart settings file

1 On the File menu, click Open.
2 In the Performance Monitor - File Open dialog box, enter the path name for the .pmc file containing the selections that you want to reuse, and click Open.

To create a new blank chart

On the File menu, click New Chart.

For help understanding a selected counter, click Explain in the Add To Chart dialog box.

You can create custom charts to monitor the current performance of selected counters and instances, such as the following:

Investigating why a computer or application is slow or inefficient.
Continuously monitoring systems to find intermittent performance bottlenecks.
Discovering why you need to increase capacity.

If you switch to Chart from another view and have not created or opened a chart in your current session, the Chart window is blank.

Logging Current activity

To view the Log window

On the View menu, click Log.

If you are switching from another view, the Log window is blank unless you already created or opened a log file during that session or from the command prompt.

To open an existing log settings file

1 On the File menu, click Open.
2 In the Performance Monitor-File Open dialog box, enter the path name for the .pml file containing the selections that you want to reuse.
If there is a log filename associated with that log settings file, be aware that Performance Monitor will start logging data to that log upon opening that settings file.
3 Click Open.

To create a new blank log file

On the File menu, click New Log Settings.

If you switch to Log from another view and have not created or opened a log in your current session, the Log window is blank.

Add counters and objects to the log in the normal way, remembering you can combine data from several computers if you wish, then you are ready to start the log running. To do this, select option, then log. A window similar to the one in fig 3. will appear.

Collecting data from a server and using it to identify bottlenecks

1. Note: This uses the chart view for simplicity's sake. For longer-term analysis you would collect this data in a log.
2.  Start Performance Monitor (Start - Programs - Administrative Tools (Common) - Performance Monitor)
3.  Move into Chart Mode (Select Chart from the View menu or press Ctrl-C)
4. Add the following Counters (see key below to show what each one means)
   - Memory-Pages/sec
   - Memory-Available Bytes
   - PhysicalDisk-% Disk Time
   - PhysicalDisk-Current Disk Queue Length
   - Processor-% Processor Time
   - Processor-Interrupts/sec
   - System-Processor Queue Length
   These are added by selecting "Add to Chart" from the Edit menu (or click the big + on the toolbar). The first part, e.g. Memory is the Object, and the second part is the Counter. Click Done when all are added
5. Let the monitor run for a while and perform your normal day-to-day operations.

Having let the chart run for a while, you can then look at the values it produces. Use the key below to determine whether a system or a part of it appears to be overloaded. What would you do next to further investigate this area?

Object Key

• Memory-Pages/sec. Pages/sec is the number of pages read from the disk or written to the disk to resolve memory references to pages that were not in memory at the time of the reference. Regular high values under this counter indicate that the system is over using virtual memory and more physical memory may be required.
• Memory-Available Bytes. Available Bytes displays the size of the virtual memory currently on the Zeroed, Free, and Standby lists. Broadly speaking, this is the memory available for the system to use, and the higher this value, the better
• PhysicalDisk-% Disk Time. Disk Time is the percentage of elapsed time that the selected disk drive is busy dealing with I/O requests. The higher this value the more work the disk subsystem is doing.
• Processor-Interrupts/sec. Interrupts/sec is the number of device interrupts the processor is experiencing. A device interrupts the processor when it has completed a task or when it otherwise requires attention. Normal thread execution is suspended during interrupts.
• System-Processor Queue Length. Processor Queue Length is the instantaneous length of the processor queue in units of threads. This counter is always 0 unless you are also monitoring a thread counter. All processors use a single queue in which threads wait for processor cycles. This length does not include the threads that are currently executing. A sustained processor queue length greater than two generally indicates processor congestion.
• PhysicalDisk-Current Disk Queue Length. Current Disk Queue Length is the number of requests outstanding on the disk at the time the performance data is collected. Overly high numbers here may indicate the disk subsystem is overworked.
• Processor-% Processor Time. Processor Time is expressed as a percentage of the elapsed time the processor spends doing useful work. Constant high values (over 85% say) may indicate an overloaded processor if there are no other obvious bottlenecks.

Performance Monitor Hints and Tips

1. Remember that you may need to turn on the disk performance counters in order to use them.
   Log onto the machine you wish to work on with admin rights and from a command prompt type "diskperf" to see help on doing this, and whether or not disk counters are currently active. You will need to restart the system for these changes to take effect. Also note that the diskperf counters can make a real dent in disk performance so should be used sparingly and deactivated when not in use, especially on systems with high I/O congestion.
2. Get used to planning performance monitor sessions to capture the data you need with the minimum of logging sessions
   Remember that using performance monitor has a performance impact itself; it does slow the system down after all, and also the logs can use a fair amount of disk space.
3. Always log the minimum amount of data you need to achieve what you want.
   In addition to the points above, the more data samples you gather the greater the impact of performance monitor on the system. Therefore if you don't need it, don't sample it.
4. If you want a longer term survey of the load on a system remember to survey the system over at least a week, and at several different times a day to get an idea of peak and average loads
   For example a system that appears fine at 2:30 pm when nothing much is happening may be bursting at the seams trying to keep up with the start of day logins at 8:30 am. If you survey at just one of these times you will not have an accurate picture of the server's workload.

Top