Establishing performance baselines
Comprehensive performance monitoring
Resolving performance bottlenecks
Microsoft Windows Server 2012 R2 provides many tools to help you track performance. In the previous chapter, you looked at tuning performance through configuration settings; using Task Manager to track running processes, users, and network utilization; and using the event logs to track important occurrences the operating system records. Although these tools are excellent and do their jobs well, you might need to dig deeper to establish comprehensive performance baselines, diagnose complex system problems, and optimize system performance.
The key comprehensive monitoring and optimization tools and features available include the following:
Performance Monitor. Can be used to track and display performance information in real time. It gathers information on any performance parameters you configured for monitoring and presents it using a graphical display.
Reliability Monitor. Tracks changes to the system and compares them to changes in system stability, thus giving you a graphical representation of the relationship between changes in the system configuration and changes in system stability.
Resource Monitor. Displays detailed information about resource usage for the server so you can isolate resources that specific processes use.
Data Collector Sets and Reports. Can be considered the logging counterpart to Performance Monitor. By using data collector sets, you can record performance information in real time and store it in a log so that it can be analyzed in a report later.
Performance Counter Alerts. Can be used to notify users when certain events occur or when certain performance thresholds are reached. For example, you could configure a performance alert that lets you know when the C drive is running low on free space or the central processing unit (CPU) is operating at 95 percent or more of capacity.
Before discussing each of these tools in turn, let’s look at how you can establish performance baselines.
Resource Monitor, Reliability Monitor, and Performance Monitor are the tools of choice for monitoring a system’s reliability and performance. One of the key reasons for tracking performance information is to establish a baseline for a computer that enables you to compare past performance with current performance. There are several types of baselines you can use, including the following:
Postinstallation baselines. A postinstallation baseline is a performance level that is meant to represent the way a computer performs after installing all the roles, role services, features, and applications that will be used on the system.
Typical usage baselines. A typical usage baseline is a performance level that is meant to represent average usage conditions and serve as a starting point against which you can measure future performance.
Test baselines. A test baseline is a performance level that you use during testing of a system. In the test lab, you might want to simulate peak usage loads and test how the system performs under these conditions.
Although it is important to obtain postinstallation and typical usage baseline values, the more important of the two is the typical usage baseline. This is the baseline you get when you simulate user loads or when users actually start working with a server. Ideally, it represents typical or average loads. After you have a typical usage baseline, you can gather information in the future to try to determine how resource usage has changed and how the computer is performing comparatively.
To be able to establish a baseline, you must collect a representative set of performance statistics. By that, I mean collect the data that you actually need to determine resource usage and performance in future scenarios. If possible, you should also collect several data samples at the same time each day over a period of several days. This gives you a more meaningful data sample.
You must work to keep the baseline in sync with how the server is used. As you install new roles, role services, features, and applications, you must establish new baselines. This ensures that future comparisons with the baseline are accurate and that they use the most current system configuration to determine how resource usage has changed and how the computer is performing comparatively.
As discussed in Chapter 10 you can use Task Manager to determine the overall utilization of system resources. The Processes and Details tabs in Task Manager provide information about resources being used by running processes. What’s missing from Task Manager, however, is the ability to take a deep look at how processes are using resources, and this deep-look capability is exactly what Resource Monitor provides.
You can start Resource Monitor by selecting the related option on the Tools menu in Server Manager. Alternatively, type Resource Monitor in the Everywhere Search box and press Enter.
Note
As with any locally installed administrative tool, Resource Monitor can only be found in an Everywhere Search when you’ve selected the Show Administrative Tools option. If this option isn’t enabled, you can enable it from the Start screen. On Start, press the Windows key+C to display the Charm bar and then select Settings. On the Settings panel, select Tiles and then select Show Administrative Tools.
When you start Resource Monitor, shown in Figure 11-1, you see that the statistics provided are organized into five general categories:
Overview
CPU
Memory
Disk
Network
Each of these categories can be used for comprehensive performance analysis, and in the sections that follow, I show you how.
Figure 11-1. Use Resource Monitor to get detailed information about per-process resource utilization.
The Overview tab in Resource Monitor, shown in Figure 11-2, provides a detailed overview of resource utilization. Top-level utilization statistics are tracked in the graphs and on the panel bars. In accordance with the legend shown on the panel bars, the values are plotted in either green or blue on the corresponding graph. The statistics tracked include the following:
% CPU usage
CPU maximum frequency
Disk I/O bytes per second
Disk % highest active time
Network I/O bytes per second
% Network utilization
Memory hard faults per second
% Physical memory used
At first glance, the information provided seems similar to that available in Task Manager. What’s different, however, is that when you select one or more processes on the CPU panel, you see related utilization statistics for the processes on the Disk panel, Network panel, and Memory panel. You also see related activity plotted in orange on the CPU, Disk, Network, and Memory graphs.
Note
The CPU, Disk, Network, and Memory panels show a subset of the information available on the related tabs. Your process selections are applied globally so that you can determine exactly how the selected processes are using CPU, disk, network, and memory resources.
In the example, I selected three processes for tracking: sqlservr.exe, System, and sqlwriter.exe. I chose these processes because I already determined in Task Manager that these were some of the most active processes on the server, and I wanted to determine how these processes were affecting the server. I quickly learned that these processes weren’t affecting the CPU nearly as much as I thought. Although the processor utilization on the server was performing well at about 70 percent, these processes seemed to be using few actual CPU resources. However, they were high consumers of disk and network resources (and, in fact, accounted for nearly all the disk and network activity).
By examining the disk and network activity, I was able to identify exactly which activities were using these resources. Although some of the disk I/O activity was related to SQL Server, the bulk of the activity was related to large data transfers. One data transfer in particular involved a large data set that was being moved from another file server to the server I was analyzing. You can see this in the three entries under Disk and the first entry under Network. Under Disk, a large write is in progress for the C:Shares folder. Under Network, a large data set is being received from another server.
The CPU tab in Resource Monitor shows the current CPU utilization and the maximum CPU frequency. If you expand the Processes panel (by tapping or clicking the options button), as shown in Figure 11-3, you see a list of currently running executables. Each process is listed according to the following categories:
Average CPU. The average percentage of CPU utilization for the process in the last minute
CPU. The percentage of CPU utilization for the process (across all physical and logical processors)
Description. The name of the process (and sometimes other information as well)
Image. The name of the process or executable running the process
PID. The numeric identifier for the process
Status. The execution status of the process
Threads. The number of threads the process is using
Figure 11-3. The CPU tab in Resource Monitor provides detailed per-process information about CPU utilization.
If you press and hold or right-click any column header and then choose Select Columns, you see a dialog box that enables you to add columns to the CPU panel. The additional columns that are available include the following:
Average Cycle. The average percentage of CPU cycle time for the process (over a 60-second interval).
Cycle. The current percentage of CPU cycle time the process is using.
Elevated. The elevation status of the process. An entry of Yes indicates an elevated process.
Operating System Context. The operating system context in which the process is running, such as Windows Server 2012 R2 or Windows 8.1.
Platform. The platform on which the process is running, either 32-bit or 64-bit.
User Name. The name of the user or service that is running the process.
Select one or more processes on the Processes panel to get more detailed information about how those processes are using CPU resources. As you select processes for tracking, keep in mind that your selections are global. The same selections will appear in the other tabs in Resource Monitor.
When you select one or more processes for tracking, you see additional details on these panels:
Services. Shows the name of the service running a process or processes, along with process identifiers, the status, descriptions of the services, percentage of CPU utilization, and the average percentage of CPU utilization.
Associated Handles. Shows the names of the handles associated with the selected processes, listed by the executable name of the process, the process identifier, the handle type, and the handle file path.
Associated Modules. Shows the names of modules loaded by the selected processes, listed by the executable name of the process, the process identifier, the module name, the module version, and the module file path.
Use this information to help you identify which services are running processes and which handles and modules a process is using. No additional details can be added to the Services, Associated Handles, or Associated Modules panels.
The Memory tab in Resource Monitor shows how processes are using memory, focused primarily on physical memory. As shown in Figure 11-4, the percent utilization of physical memory, the current commit charge, and the hard memory faults are graphed over time. On the Processes panel, individual processes are listed by the following categories:
Image. The name of the process or executable running the process.
PID. The numeric identifier for the process.
Hard Faults/Sec. The average number of hard memory faults per second in the past minute.
Commit. The commit charge for the process, measured in kilobytes (KB). The commit charge represents the amount of virtual memory the operating system reserves for the process.
Working Set. The amount of physical memory the process is currently using.
Shareable. The nonprivate working set for the process, representing the amount of physical memory the process is using that can be shared with other processes.
Private. The private working set for the process, representing the amount of physical memory the process is using that cannot be shared with other processes.
Figure 11-4. The Memory tab in Resource Monitor provides detailed per-process information about CPU utilization.
On the Physical Memory panel, you see a graph showing the composition of in-use and available memory and related usage statistics. Although the details provided are similar to those provided in the Task Manager Performance tab, they are more precise, and you see specific values listed for the following:
Available Memory. The unallocated physical memory (which includes the system’s standby memory and free memory).
Cached Memory. Part of the available physical memory. This memory is used for system caching (and includes the system’s modified memory and standby memory).
Free Memory. Unallocated memory and part of the available memory. This memory doesn’t contain any valuable data and will be used first whenever more memory is needed.
Hardware Reserved Memory. Memory reserved for BIOS and some drivers for other peripherals.
In-Use Memory. Currently allocated physical memory. The size of the paging file is the difference between the current commit charge and the in-use memory.
Installed Memory. The total amount of physical memory installed on the system, including the hardware reserved memory.
Modified Memory. Part of the cached memory. This memory needs to be written to disk before becoming available.
Standby Memory. Part of the cached memory. This memory contains cached data and code not actively being used.
Total Memory. The total amount of physical memory installed on the system, not including hardware reserved memory.
Use this information to help you identify how processes are using memory and whether performance issues are related to memory. No additional details can be added regarding memory usage.
The Disk tab in Resource Monitor shows the number of kilobytes per second being read from or written to disk and the highest percentage usage. As shown in Figure 11-5, processes with disk activity are listed by name, process ID, number of bytes being read per second, number of bytes being written per second, and total read/write bytes per second.
Figure 11-5. The Disk tab in Resource Monitor provides detailed per-process information about CPU utilization.
Select one or more processes on the Processes With Disk Activity panel to get more detailed information about how those processes are using disk resources. As you select processes for tracking, keep in mind that your selections are global. The same selections will appear in the other tabs of Resource Monitor.
When you select one or more processes for tracking, you see additional details on the Disk Activity and Storage panels. To help you quickly identify disk-related performance issues, the Disk Activity panel identifies the files a particular process is reading or writing along with the bytes read per second, bytes written per second, and total read/write bytes per second for each file. Also shown are the I/O priority and the response time.
The Storage panel provides information about the underlying logical and physical disks. The Logical Disk column shows the drive letters of logical disks with I/O activity. The Physical Disk column identifies the specific physical disk where the logical disks were created. If there are performance issues with a server’s disks and files are being read from and written to multiple logical disks residing on the same physical disk (or relatively few physical disks as compared to the number of available physical disks), you might be able to improve performance by changing the storage configuration so that I/O activity is spread more evenly across the server’s physical disks. You also can try to balance the workload by moving applications and services from an over-utilized server to another, less-utilized server.
The Network tab in Resource Monitor shows the current network bandwidth utilization in kilobytes and the percentage of total bandwidth utilization. As shown in Figure 11-6, processes that are transferring or have transferred data on the network are listed by name, process ID, number of bytes being sent per second, number of bytes received per second, and total bytes sent or received per second.
Figure 11-6. The Network tab in Resource Monitor provides detailed per-process information about network utilization.
Select one or more processes on the Processes With Network Activity panel to get more detailed information about how those processes are using network resources. As you select processes for tracking, keep in mind that your selections are global. The same selections will appear on the other tabs of Resource Monitor.
When you select one or more processes for tracking, you see additional details on these panels:
Network Activity. Identifies the name or IP address of the computer to which a process is connected, along with the average number of bytes sent per second in the past minute, the average number of bytes received per second in the past minute, and the total number of bytes transferred per second in the past minute.
TCP Connections. Shows the TCP connections for processes with network activity according to the local addresses, local ports, remote addresses, and remote ports being used. Also shown are the percentage of packets lost during the connection and the roundtrip latency in milliseconds.
Listening Ports. Shows the specific listening ports processes are using with network activity, along with the firewall status.
If there are performance issues with a server’s network connections, you might be able to improve performance by installing multiple network adapters in the server and teaming the network cards. You configure network interface card (NIC) teaming by using Server Manager, either through a local logon or using a remote desktop connection. Either way, after you are logged on to the server, you can configure NIC teaming by selecting Local Server in the left pane of Server Manager and then tapping or clicking the link provided for NIC teaming. Next, tap or click Tasks under Teams and then select New Team. Enter a name for the teamed network adapters, such as Team Set 1, select the member adapters, and then tap or click OK.
If you can’t add or team network adapters, you can try to reduce the server’s network activity by moving applications and services from an over-utilized server to another, less-utilized server.
You can use Performance Monitor and Reliability Monitor to track the overall reliability of a server. Performance Monitor graphically displays statistics for the set of performance parameters you selected for display. These performance parameters are referred to as counters. When you install additional roles, role services, and features on a system, Performance Monitor might be updated with a set of counters for tracking performance of the related components. You also can update counters when you install additional services and applications.
Performance Monitor, shown in Figure 11-7, creates a graph depicting the counters you’re tracking. The update interval for this graph is configurable but is set to one second by default. Tracking information is most valuable when you record performance information in a log file so that it can be played back. When you create alerts, you can notify yourself or others anytime specific performance criteria are met.
You can start Performance Monitor by selecting the related option on the Server Manager Tools menu. Alternatively, type Performance Monitor in the Everywhere Search box and press Enter.
Reliability Monitor, shown in Figure 11-8, tracks changes to the server and compares them to changes in system stability. In this way, you can see a graphical representation of the relationship between changes in the system configuration and changes in system stability. By recording software installation, software removal, application failure, hardware failure, and Windows failure events, in addition to key events regarding the configuration of the server, you can see a timeline of changes in both the server and its reliability and then use this information to pinpoint changes that are causing problems with stability. For example, if you see a sudden drop in stability, you can tap or click a data point and then expand the related data set, such as Application Failure or Windows Failure, to find the specific event that caused the drop in stability.
Important
Use Save Reliability History to save complete details about the server’s stability for future reference. The information is saved as a Reliability Monitor report and is formatted as XML. Tap or click Save Reliability History and then use the dialog box provided to select a save location and file name for the report. You can view the report in Internet Explorer by double-tapping or double-clicking the file.
You can access Reliability Monitor from Action Center. On the desktop, tap or click the Action Center icon on the Task bar and then tap or click Open Action Center. In Action Center, expand the Maintenance panel and then tap or click View Reliability History. Alternatively, you can open Reliability Monitor by entering perfmon /rel at a command prompt or in the Everywhere Search box.
Although reliability monitoring is enabled by default for Windows clients, it might be disabled for Windows servers. When you open Reliability Monitor on a server where reliability monitoring is disabled, you see that no reliability updates or history details are available. To enable reliability tracking, you must allow the Microsoft Reliability Analysis task, RacTask, to process system reliability data.
RacTask is a scheduled task that runs in the background to collect reliability data. You can find RacTask in the Task Scheduler Library under Microsoft, Windows, RAC. On servers, this task is best used as part of troubleshooting. If RacTask is disabled, you can enable and configure the task by completing the following steps:
In Server Manager, on the Tools menu, select Task Scheduler. In the left pane of Task Scheduler, expand Task Scheduler LibraryMicrosoftWindows and then select the RAC node.
By default, RacTask runs whenever the system is started, daily at approximately 5:00 P.M. (a random delay of up to 15 minutes is added each scheduled run-time) and when Customer Experience Improvement Program events are logged. Because performing reliability analysis and collection daily at around 5:00 P.M. might not be an optimal time, select RacTask in the main pane and then select Properties on the Action menu.
In the Properties dialog box, on the Triggers tab, select the One Time trigger and then select Edit. Use the options provided to specify an optimal time to run this task. Select OK twice to close the open dialog boxes.
With RacTask still selected in Task Scheduler, select Enable on the Action menu. To run the task once now, select Run on the Action menu.
If you enable the task for troubleshooting, review and modify the default triggers as appropriate for your environment. By default, the task is triggered at startup, once a day at 5:00 P.M., and whenever event 1007 is written to the application log. Event 1007 tracks Customer Experience Improvement Program events, which Microsoft tracks to help improve the overall stability of Windows and Windows Server. Don’t enable RacTask without considering the possible performance impact.
Performance Monitor is a tool designed to track and display performance information in real time. It gathers information on any performance parameters you configured for monitoring and presents it using a graphical display.
When you are working with Performance Monitor, the main pane graphs any performance items you configured for monitoring, as shown in Figure 11-7. Each performance item you want to monitor is defined by the following three components:
Performance objects. Represent any system component that has a set of measurable properties. A performance object can be a physical part of the operating system such as the memory, the processor, or the paging file; a logical component such as a logical disk or print queue; or a software element such as a process or a thread.
Performance object instances. Represent single occurrences of performance objects. If a particular object has multiple instances, such as when a computer has multiple processors, you can use an object instance to track a specific occurrence of that object. You could also elect to track all instances of an object, such as if you want to monitor all processors on a system.
Performance counters. Represent measurable properties of performance objects. For example, with a processor, you can measure the percentage of processor utilization by using the % Processor Time counter.
In a standard installation of Windows Server 2012 R2, many performance objects are available for monitoring. As you add services, applications, and components, additional performance objects can become available. For example, when you install the Domain Name System (DNS), the DNS object becomes available for monitoring on that computer.
The most common performance objects you want to monitor are summarized in Table 11-1. Like all performance objects, each performance object listed here has a set of counters that can be tracked.
Table 11-1. Commonly tracked performance objects
Performance Object | Description |
|---|---|
Cache | Monitors the file system cache, which is an area of physical memory that indicates application I/O activity |
Database ==> Instances | Monitors performance for instances of the embedded database management system Windows Server 2012 R2 uses |
DFS Replicated Folders | Monitors conflicts, deletions, replication, and other performance factors related to DFS replication folders |
DFS Replication Connections | Monitors the data sent and received and other performance statistics for DFS replication connections |
DHCPv6 Server | Monitors DHCPv6 message broadcasts and other types of DHCPv6 activities |
DirectoryServices | Monitors performance statistics related to Active Directory Domain Services (AD DS) |
DNS | Monitors DNS message traffic and other types of DNS activities |
IPv4 | Monitors IPv4 communications and related activities |
IPv6 | Monitors IPv6 communications and related activities |
LogicalDisk | Monitors the logical volumes on a computer |
Monitors memory performance for system cache (including pooled, paged memory and pooled, nonpaged memory), physical memory, and virtual memory | |
Network Interface | Monitors the network adapters configured on the computer |
Objects | Monitors the number of events, mutexes, processes, sections, semaphores, and threads on the computer |
Paging File | Monitors page file current and peak usage |
PhysicalDisk | Monitors hard disk read/write activity and data transfers, hard faults, and soft faults |
Print Queue | Monitors print jobs, spooling, and print queue activity |
Process | Monitors all processes running on a computer |
Processor | Monitors processor idle time, idle states, usage, deferred procedure calls, and interrupts |
Server | Monitors current server activity and important server usage statistics, including logon errors, access errors, and sessions |
Server Work Queues | Monitors server threading and client requests |
System | Monitors system-level counters, including processes, threads, context switching of threads, file system control operations, system calls, and system uptime |
TCPv4 | Monitors TCPv4 communications and related activities |
TCPv6 | Monitors TCPv6 communications and related activities |
Thread | Monitors all running threads and enables you to examine usage statistics for individual threads by process ID |
UDPv4 | Monitors UDPv4 communications and related activities |
UDPv6 | Monitors UDPv6 communications and related activities |
The most commonly tracked performance objects are Memory, PhysicalDisk, and Processor. When you first open Performance Monitor, it is configured to graph only the % Processor Time counter. Many other performance counters are available for tracking. To track additional counters, you use the Add Counters dialog box, as shown in Figure 11-9. With the Performance Monitor node selected in the Performance console or Computer Management, you open this dialog box by pressing Ctrl+I or selecting the Add Counters button on the toolbar.
After you open the Add Counters dialog box, you can select objects and counters to track by completing these steps:
In the Select Counters From Computer box, enter the Universal Naming Convention (UNC) name of the server you want to work with, such as \CorpServer62, or choose <Local computer> to work with the local computer. You need to be at least a member of the Performance Monitor Users group in the domain or the local computer to perform remote monitoring.
Adding counters to track is easy. Select the type of object you want to work with, such as Memory. When you select an object entry by tapping or clicking it, all related counters are selected. If you expand an object entry, you can see all the related counters and then select individual counters by tapping or clicking them. With a keyboard, use Ctrl+click or Shift+click to select multiple counters.
When you select an object or any of its counters, in most cases you see the related instances. Choose _Total to work with a summary view of all counter instances. Choose All Instances to select all counter instances for monitoring or select one or more individual counter instances to monitor.
When you select an object or a group of counters for an object in addition to the object instances, tap or click Add to add the counters to the graph. Repeat steps 2 and 3 to add other performance parameters. You can then repeat this process, as necessary, to add counters for other performance objects. Tap or click OK when you’re finished adding counters.
As you’ve seen, it’s easy to add counters to track. What isn’t so easy is determining which counters you should track. While you are working with the Add Counters dialog box, you can get a detailed explanation of a counter by selecting a counter and then selecting the Show Description check box. If you add too many counters or track the wrong counters, don’t worry. In the Performance Monitor view, you can delete counters later by selecting their entries in the lower portion of the details pane and then tapping or clicking Delete on the toolbar or pressing the Delete key on your keyboard. You can also delete all counters being tracked and start over with a clean graph by selecting an entry in the lower portion of the details pane, pressing Ctrl+A, and then pressing the Delete key.
Performance Monitor displays each counter that you are tracking in a different color and line thickness. You can use the legend in the lower portion of the details pane to help you determine which counter is being graphed where. If you are unsure, tap or click a line in the graph to select the corresponding counter in the legend list. To highlight a specific counter so that it is easy to pick out in the graph, select the counter in the legend list and then press Ctrl+H.
Performance Monitor can present counter statistics in several ways. By default, it graphs the statistics. A graph is useful when you are tracking a limited number of counters because you can view historical data for each counter that you are working with. By default, Performance Monitor samples the counters once every second and updates the graph over a 100-second duration. This means that at any given time, up to 100 seconds’ worth of data can be on the graph. If you change the sample interval and duration, you can get more information into the chart. For example, if you set the sample interval to once every 10 seconds and the duration to 1000 seconds, you can get up to 1000 seconds’ (or about 17 minutes’) worth of data on the graph.
You can set the sample interval by using the General tab of the Performance Monitor Properties dialog box, as shown in Figure 11-10. To open this dialog box, press and hold or right-click the Performance Monitor node and select Properties. Set the sample interval and duration by using the Sample Every and Duration text boxes.
The options on the Display Elements panel on the General tab of the Performance Monitor Properties dialog box control the availability of the Legend, Value Bar, and Toolbar. The Legend is displayed at the bottom of the details pane, and it shows the color and line style that are used for each counter. The Value Bar is displayed between the graph and the legend. It shows values related to the counter you selected in the graph or in the legend. The Toolbar is displayed above the graph and provides the basic toolbar functions for working with Performance Monitor. You might find that it is much easier to use the shortcut keys than to tap or click the Toolbar buttons. The Toolbar buttons and their shortcut keys are as follows:
View Current Activity. Ctrl+T; switches the view so that current activity being logged is displayed.
View Log Data. Ctrl+L; switches the view so that data from a performance log can be replayed.
Change Graph Type. Ctrl+G; switches the view to toggle among bar graph, report list, and graph format.
Add. Ctrl+I; opens the Add Counter dialog box, in which you can add counters to track.
Delete. Delete key; removes the counter so that it is no longer tracked.
Highlight. Ctrl+H; highlights the counter by using a white line so that it is easier to see. Highlighting works best with graphs. If you want to turn off the Highlight function, press Ctrl+H again.
Copy Properties. Ctrl+C; creates a copy of the counter list along with the individual configuration of each counter and puts it on the Clipboard. The information is formatted as an Extensible Markup Language (XML) file. If you open a text editor, you could paste in this information and save it for later use.
Paste Counter List. Ctrl+V; pastes a copied counter list into Performance Monitor so that it is used as the current counter set. If you saved a counter list to a file, you just open the file, copy the contents of the file to the Clipboard, and then press Ctrl+V in Performance Monitor to use that counter list.
Properties. Ctrl+Q; displays the Properties dialog box for a select item.
Freeze Display. Ctrl+F; freezes the display so that Performance Monitor no longer updates the performance information. Press Ctrl+F a second time to resume sampling.
Update Data. Ctrl+U; updates the display by one sampling interval. When you freeze the display, Performance Monitor still gathers performance information; it just doesn’t update the display by using the new information. If you want to update the display while it is frozen, use this option.
Help. F1; displays the Performance Monitor Help information.
The Histogram Bar and Report views deserve a bit of additional discussion. In the Histogram Bar view, Performance Monitor represents the performance information by using a bar graph with the last sampling value for each counter displayed on an individual bar within the graph. The sizes of the bars within the graph are adjusted automatically based on the number of performance counters being tracked and can be adjusted to accommodate hundreds of counters. That is, in fact, the biggest advantage of the histogram—it enables you to track a lot of counters more easily. In Figure 11-11, approximately 100 counters are being tracked, and it is easy to pick out which counter is which.
In the Report view, shown in Figure 11-12, Performance Monitor represents the performance information by using a report list format. In this view, objects and their counters are listed in alphabetical order. Current values are displayed rather than being graphed. If you are trying to determine specific performance values for many counters, this is the best view to use because the actual values are always shown.
Monitoring performance on the computer for which you are trying to establish a baseline can skew the results. The reason for this is that Performance Monitor uses resources when it is running, particularly when you are graphing performance information, taking frequent samples, or tracking many performance counters. To remove the resource burden (or at least most of it), you should consider monitoring performance remotely. Here, you use one computer to monitor the performance of another computer. Although this does generate some extra network traffic, you get more accurate results for the monitored computer because you’re not using its resources for monitoring.
Note
By default, only administrators can monitor performance remotely. You need to be at least a member of the Performance Monitor Users group in the domain or on the local computer to perform remote monitoring. When you use performance logging, you need to be at least a member of the Performance Log Users group in the domain or on the local computer to work with performance logs on remote computers.
To begin remote monitoring, select the Performance Monitor node in the Performance Monitor console or in Computer Management. To start with a new counter set and clear out any existing counters, select a counter entry in the lower portion of the details pane, press Ctrl+A, and press the Delete key. Press Ctrl+I to open the Add Counters dialog box. In the Add Counters dialog box, type the UNC name or Internet Protocol (IP) address of the computer you want to monitor remotely in the Select Counters From Computer text box. A UNC computer name or IP address begins with two back slashes (\). So, for instance, you could type \CorpServer03 or \192.168.1.56.
After you type the UNC computer name or IP address, press Tab or tap or click the Performance Object list. When you do this, Performance Monitor attempts to connect to the remote computer and retrieve a list of available performance objects to monitor. You can then choose performance objects and counters to track just as you would for a local computer.
Generally, a bottleneck is any condition that keeps a computer from performing at its best. Bottlenecks can also apply when one resource is preventing another resource from performing optimally. For example, if a system doesn’t have enough physical memory, it doesn’t matter whether it has a fast processor or a slow processor. The system will still perform poorly because it doesn’t have enough available physical memory and must rely heavily on the paging file, reading and writing to disk frequently.
Memory is usually the main bottleneck on both workstations and servers. It is the resource you should examine first to determine why a system isn’t performing as expected. But memory isn’t the only bottleneck. The processor, disk subsystem, and networking components are also sources of potential performance bottlenecks.
Windows applications use a lot of memory. If you install a server with the minimum amount of memory required, it won’t perform at its optimal level because a server’s memory requirements depend on many factors, including the services, components, and applications that are installed on it and the server’s configuration.
Computers use both physical and virtual memory. Physical memory is represented by the amount of random access memory (RAM) installed. Virtual memory is memory written to a paging file on disk. Reading from and writing to the paging file involve the disk subsystem, and it is much slower than accessing physical memory. Because of this, you don’t want a system to have to use the paging file too frequently.
Before you set out to monitor memory usage, you should check to ensure that the computer has the recommended amount of memory for the operating system and the applications it is running. After you’ve done this, you can determine how the system is using memory and check for problems. Look closely at the amount of memory available and the amount of virtual memory being used. If the server has very little available memory, you might need to add memory to the system. In general, you want the available memory to be no less than 5 percent of the total physical memory on the server. If the server is using a high ratio of virtual memory to total physical memory on the system, you might need to add physical memory as well.
Look at the way the system is using the paged pool and nonpaged pool memory. The paged pool is an area of system memory for objects that can be written to disk when they aren’t used. The nonpaged pool is an area of system memory for objects that can’t be written to disk. If the size of the paged pool is large relative to the total amount of physical memory on the system, you might need to add memory to the system. If the size of the nonpaged pool is large relative to the total amount of virtual memory allocated to the server, you might want to increase the virtual memory size.
Look at the way the system is using the paging file. A page fault occurs when a process requests a page in memory and the system can’t find it at the requested location. If the requested page is elsewhere in memory, the fault is called a soft page fault. If the requested page must be retrieved from the paging file on disk, the fault is called a hard page fault. Most processors can handle large numbers of soft faults. Hard faults, however, can cause significant delays. If there are a high number of hard page faults, you might need to increase the amount of memory or reduce the size of the system cache.
Counters you can use to check for memory bottlenecks include the following:
MemoryAvailable Bytes. Records the number of bytes of physical memory available to processes running on the server. When less than 5 percent of memory is free, the system is low on memory, and performance can suffer. The server might page excessively to disk to try to keep up with resource demands. Memory is critically short if 128 megabytes (MBs) or less of memory is free; in this case, the system might page excessively to disk and try to borrow memory from running processes to keep up with resource demands. If the system is very low on memory, it could also point to a possible memory leak.
MemoryCommitted Bytes. Records the number of bytes of committed virtual memory. This represents memory that has been paged to disk and is in use. If a server is using too much virtual memory relative to the total physical memory on the system, you might need to add physical memory.
MemoryCommit Limit. Shows the total available physical and virtual memory. As the number of committed bytes grows, the paging file is allowed to grow up to its maximum size, which can be determined by subtracting the total physical memory on the system from the commit limit. If you set the initial paging file size too small, the system will repeatedly extend the paging file, and this requires system resources. It is better to set the initial paging file size as appropriate for typical usage or just use a fixed paging file size. For a fixed paging file, set the size to at least two times the size of RAM.
MemoryPage Faults/Sec. Records the average number of page faults per second. It includes both hard and soft page faults. Soft faults result in memory lookups. Hard faults require access to disk.
MemoryPages/Sec. Records the number of memory pages that are read from disk or written to disk to resolve hard page faults. It is the sum of MemoryPages Input/Sec and MemoryPages Output/Sec.
MemoryPages Input/Sec. Records the rate at which pages are read from disk to resolve hard page faults. Hard page faults occur when a requested page isn’t in memory and the computer has to go to disk to get it. Too many hard faults can cause significant delays and hurt performance.
MemoryPages Output/Sec. Records the rate at which pages are written to disk to free up space in physical memory. If the server has to free up memory too often, it indicates that not enough physical memory (RAM) is on the system.
MemoryPool Paged Bytes. Represents the size in bytes of the paged pool. The paged pool is an area of system memory for objects that can be written to disk when they aren’t used. If the size of the paged pool is large relative to the total amount of physical memory on the system, you might need to add memory to the system. If this value slowly increases in size over time, a kernel-mode process might have a memory leak.
MemoryPool Nonpaged Bytes. Represents the size in bytes of the nonpaged pool. The nonpaged pool is an area of system memory for objects that can’t be written to disk. If the size of the nonpaged pool is large relative to the total amount of virtual memory allocated to the server, you might want to increase the virtual memory size. If this value slowly increases in size over time, a kernel-mode process might have a memory leak.
Paging File\%Usage. Records the percentage of the paging file currently in use. If this value approaches 100 percent for all instances, you should consider either increasing the virtual memory size or adding physical memory to the system. This ensures that the server has additional memory if it needs it, such as when the server load grows.
Paging File\%Usage Peak. Records the peak size of the paging file as a percentage of the total paging file size available. A high value can mean that the paging file isn’t large enough to handle increased load conditions.
Physical Disk\%Disk Time. Records the percentage of time that the selected disk spent servicing read and write requests. Keep track of this value for the physical disks that have paging files. If you see this value increasing over several monitoring periods, you should monitor paging-file usage more closely and consider adding physical memory to the system.
Physical DiskAvg. Disk Queue Length. Records the average number of read and write requests that were waiting for the selected disk during the sample interval. Keep track of this value for the physical disks that have paging files. If you see this value increasing over time and the MemoryPage Reads/Sec is also increasing, the system is performing a lot of paging-file reads.
Physical DiskAvg. Disk Sec/Transfer. Records the length in seconds of the average disk transfer. Track this value for the physical disks that have paging files in conjunction with MemoryPages/Sec. MemoryPages/Sec tracks the number of reads and writes for the paging file. If you multiply the Physical DiskAvg. Disk Sec/Transfer by the MemoryPages/Sec value, you have an excellent indicator of how much of the disk access time paging is using. Use the result to help you decide whether to move the paging files to faster disks or add physical memory to the system.
After you’ve eliminated memory as a potential bottleneck, you should examine the system’s processor usage to determine whether there are any potential bottlenecks. Processor bottlenecks can occur if a process’s threads need more processing time than is available. This, in turn, causes the processor queue to grow because threads have to wait to get processing time. As a result, the system response suffers, and the system appears sluggish or nonresponsive.
Excess interrupts are another common reason for processor bottlenecks. Each time drivers or disk subsystem components, such as hard disk drives or network components, generate an interrupt, the processor has to stop what it is doing to handle the request because requests from hardware take priority. However, poorly designed drivers and components can generate false interrupts, which tie up the processor for no reason. System boards or components that are failing can generate false interrupts as well.
If a system’s processors are the performance bottleneck, adding memory, drives, or network connections won’t overcome the problem. Instead, you might need to upgrade the processors to faster clock speeds or add processors to increase the server’s upper capacity. You could also move processor-intensive applications, such as Microsoft Exchange Server, to another server.
Counters you can use to check for processor bottlenecks include the following:
SystemProcessor Queue Length. Records the number of threads waiting to be executed. These threads are queued in an area shared by all processors on the system. If this counter has a sustained value of 10 or more threads, you might need to upgrade the processors to faster clock speeds or add processors to increase the server’s upper capacity.
Processor\%Processor Time. Records the percentage of time the selected processor is executing a nonidle thread. You should track this counter separately for all processor instances on the server. If the %Processor Time values for all instances are high (above 75 percent) while the network interface and disk input/output (I/O) throughput rates are relatively low, you might need to upgrade the processors to faster clock speeds or add processors to increase the server’s upper capacity.
Processor\%User Time. Records the percentage of time the selected processor is executing a nonidle thread in User mode. User mode is a processing mode for applications and user-level subsystems. A high value for all process instances might indicate that you need to upgrade the processors to faster clock speeds or add processors to increase the server’s upper capacity.
Processor\%Privileged Time. Records the percentage of time the selected processor is executing a nonidle thread in Privileged mode. Privileged mode is a processing mode for operating system components and services, allowing direct access to hardware and memory. A high value for all processor instances might indicate that you need to upgrade the processors to faster clock speeds or add processors to increase the server’s upper capacity.
ProcessorInterrupts/Sec. Records the average rate, in incidents per second, that the processor received and serviced hardware interrupts. Compare this value to your baselines. If this value changes substantially (I mean by thousands of interrupts) without a corresponding increase in activity, the system might have a hardware problem. To resolve this problem, you must identify the device or component that is causing the problem. Start with devices that have drivers you’ve updated recently.
With the high-speed disks available today, a system’s hard disks are rarely the primary reason for a bottleneck. It is more likely that a system is having to do a lot of disk reads and writes because there isn’t enough physical memory available, and the system has to page to disk. Because reading from and writing to disk is much slower than reading and writing memory, excessive paging can degrade the server’s overall performance. To reduce the amount of disk activity, you want the system to manage memory as efficiently as possible and page to disk only when necessary.
That said, you can do several things with a system’s hard disks to improve performance. If the system has faster drives than the ones used for the paging file, you might consider moving the paging file to those disks. If the system has one or more drives that are doing most of the work and other drives that are mostly idle, you might be able to improve performance by balancing the load across the drives more efficiently.
To help you gauge disk I/O activity better, use the following counters:
PhysicalDisk\%Disk Time. Records the percentage of time the physical disk is busy. Track this value for all hard disk drives on the system in conjunction with Processor\%Processor Time and Network Interface ConnectionBytes Total/Sec. If the %Disk Time value is high and the processor and network connection values aren’t high, the system’s hard disk drives might be creating a bottleneck. You might be able to improve performance by balancing the load across the drives more efficiently or adding drives and configuring the system so that they are used.
PhysicalDiskCurrent Disk Queue Length. Records the number of system requests that are waiting for disk access. A high value indicates that the disk waits are affecting system performance. In general, you want to have very few waiting requests.
Note
Physical disk queue lengths are relative to the number of physical disks on the system and proportional to the length of the queue minus the number of drives. For example, if a system has two drives and there are six waiting requests, that could be considered a proportionally large number of queued requests; but if a system has eight drives and there are 10 waiting requests, that is considered a proportionally small number of queued requests.
PhysicalDiskAvg. Disk Write Queue Length. Records the number of write requests that are waiting to be processed.
PhysicalDiskAvg. Disk Read Queue Length. Records the number of read requests that are waiting to be processed.
PhysicalDiskDisk Writes/Sec. Records the number of disk writes per second. It indicates how much disk I/O activity there is. By tracking the number of writes per second and the size of the write queue, you can determine how write operations are affecting disk performance. If lots of write operations are queuing and you are using RAID 5, it could indicate that you would get better performance by using RAID 1. Remember that by using RAID 5, you typically get better read performance than with RAID 1. So, there’s a tradeoff to be made by using either RAID configuration.
PhysicalDiskDisk Reads/Sec. Records the number of disk reads per second. It indicates how much disk I/O activity there is. By tracking the number of reads per second and the size of the read queue, you can determine how read operations are affecting disk performance. If lots of read operations are queuing and you are using RAID 1, you might get better performance by using RAID 5. Remember that by using RAID 1, you typically get better write performance than with RAID 5. So, as mentioned, there’s a tradeoff to be made by using either RAID configuration.
The network that connects your computers is critically important. Its responsiveness, or lack thereof, weighs heavily on the way users perceive the responsiveness of their computers and any computers to which they connect. It doesn’t matter how fast their computers are or how fast your servers are. If there’s a big delay (and big network delays are measured in tens of milliseconds) between when a request is made and the time it’s received, users might think systems are slow or nonresponsive.
Unfortunately, in most cases, the delay (latency) users experience is beyond your control. It’s a function of the type of connection the user has and the route the request takes to your server. The total capacity of your server to handle requests and the amount of bandwidth available to your servers are factors you can control, however. Network capacity is a function of the network cards and interfaces configured on the servers. Network bandwidth availability is a function of your organization’s network infrastructure and how much traffic is on it when a request is made.
Because modern servers often ship with multiple network cards, be sure to check all enabled network adapters. If a server has multiple adapters, you might want to enable and configure NIC teaming to ensure that the available bandwidth is used optimally. When NIC teaming is being used, you also want to ensure that the configuration is optimized for the way the server is currently being used. In Server Manager, you can configure NIC teaming as a Local Server option, which means you must log on locally to the server you want to configure or access the server through a Remote Desktop Connection.
When hosting virtual machines (VMs) on a hypervisor, such as Hyper-V, NIC teaming is not required. A common hypervisor configuration has trunked network connections that carry multiple virtual LANs (VLANs), or logical networks. Using NIC teaming on a VM running Windows Server 2012 that has a physical uplink through a hypervisor trunked network connection does not provide any load balancing or redundancy capabilities. Physical trunked network connections to a hypervisor are often teamed and connected to a redundant pair of physical switches, providing load balancing and redundancy to all VMs hosted on the hypervisor.
Counters you can use to check network activity and look for bottlenecks include the following:
Network InterfaceBytes Total/Sec. Records the rate at which bytes are sent and received over a network adapter. Track this value separately for each network adapter configured on the system. If the Bytes Total/Sec for a particular adapter is substantially slower than you’d expect, given the speed of the network and the speed of the network card, you might want to check the network card configuration. Check to see whether the link speed is set for half duplex or full duplex. In most cases, you want to use full duplex.
Network InterfaceCurrent Bandwidth. Estimates the current bandwidth for the selected network adapter in bits per second. Track this value separately for each network adapter configured on the system. Most servers use 100 Mbps, 1 Gbps, or 10 Gbps network cards, which can be configured in many ways. Someone might have configured a 1 Gbps card for 100 megabits per second (Mbps). If that is the case, the current bandwidth might be off by a factor of 10.
Network InterfaceBytes Received/Sec. Records the rate at which bytes are received over a network adapter. Track this value separately for each network adapter configured on the system.
Network InterfaceBytes Sent/Sec. Records the rate at which bytes are sent over a network adapter. Track this value separately for each network adapter configured on the system.
You might be able to improve network performance by installing multiple network adapters and teaming the network cards. You configure NIC teaming by using Server Manager, selecting Local Server in the left pane, and then tapping or clicking the link provided for NIC teaming. You can then create and configure NIC teams.
Windows Server 2012 R2 uses data collector sets and reports. Data collector sets enable you to specify sets of performance objects and counters that you want to track. When you create a data collector set, you can easily start or stop monitoring the performance objects and counters included in the set. In a way, this makes data collector sets similar to the performance logs used in earlier releases of Windows. However, data collector sets are much more sophisticated. You can use them in the following ways:
Use a single data set to generate multiple performance counter and trace logs.
Assign access controls to manage who can access collected data.
Create multiple run schedules and stop conditions for monitoring.
Use data managers to control the size of collected data and reporting.
Generate reports based on collected data.
In Performance Monitor, you can review currently configured data collector sets and reports under the Data Collector Sets and Reports nodes, respectively. As shown in Figure 11-13, you find data sets and reports that are user-defined and system-defined. User-defined data sets are created by users for general monitoring and performance tuning. System-defined data sets are created by the operating system to aid in automated diagnostics.
In Performance Monitor, you can view the currently configured data collector sets by expanding the Data Collector Sets node and then expanding the User Defined and System nodes. When you select a data collector set in the left pane, you see a list of the related data collectors in the main pane listed by name and type.
Data collector set types include the following:
Configuration. The Configuration type is for data collectors that record changes to particular registry paths.
Trace. The Trace type is for data collectors that record performance data whenever related events occur.
Performance Counter. The Performance Counter type is for data collectors that record data on selected counters when a predetermined interval has elapsed.
Windows Server 2012 R2 uses event traces to track a wide variety of performance statistics. You can view running event traces by selecting Event Trace Sessions. You can then stop a data collector running a trace by pressing and holding or right-clicking it and selecting Stop.
Some event traces are configured to start automatically with the operating system. These event traces are called startup event traces. You can view the enabled or disabled status of event traces configured to run automatically when you start the computer by selecting Startup Event Trace Sessions. You can start a trace by pressing and holding or right-clicking a startup data collector and selecting Start As Event Trace Session. You can delete a startup data collector by pressing and holding or right-clicking it and then selecting Delete.
You can save a data collector as a template that can be used as the basis of other data collectors by pressing and holding or right-clicking the data collector and selecting Save Template. In the Save As dialog box, select a directory, type a name for the template, and then tap or click Save. The data collector template is saved as an XML file that can be copied to other systems.
You can delete a user-defined data collector by pressing and holding or right-clicking it and then selecting Delete. If a data collector is running, you need to stop collecting data first and then delete the collector. Deleting a collector deletes the related reports as well.
Performance Monitor includes several preconfigured templates for gathering general diagnostics information, which can include information about the system configuration and performance:
Basic. Generates a report that includes basic information about the computer, CPU and disk utilization, and active network adapters. After you create a data collector set based on this template, you can add or remove counters and change the scheduling by editing the properties of the data collector set. When you are reviewing the data, be sure to drill down into the details. For example, under disks, examine the hot files, which are the files causing the most disk I/O activity. Also, be sure to examine the resource overview closely; it provides a summary analysis of CPU, network, disk, and memory usage. Note that this basic data is included in the reports for the other predefined collector sets. Default run-time: 60 seconds.
Active Directory Diagnostics. Generates a report that provides detailed diagnostics data for Active Directory, which includes registry keys, performance counters, and trace events. On domain controllers, you can use this data to help troubleshoot Active Directory performance issues. Pay particular attention to the Active Directory diagnostics and tuning data provided in the report. For example, with searches, be sure to examine the detailed data provided for unique searches, directory search by object, search status codes, searches with the most CPU utilization, and clients with the most CPU usage. Also, don’t overlook the tuning parameters for the registry. Default run-time: 300 seconds.
System Performance. Generates a report that provides detailed performance data regarding local hardware resources, system response times, and processes on the local computer. Use this information to identify the possible causes of performance issues. Note that the system performance data is included in the report for system diagnostics. Default run-time: 60 seconds.
System Diagnostics. Generates a report that provides detailed diagnostics data, which includes the status of local hardware resources, system response times, and processes on the local computer along with system information and configuration data. Suggests ways to maximize performance and streamline system operation. Be sure to examine the entries under basic system checks closely, particularly those for hardware devices and drivers. Default run-time: 60 seconds.
On member servers, system data collector sets are created automatically for system diagnostics and system performance. On domain controllers, a system data collector set for Active Directory diagnostics is also created. If you press and hold or right-click the related entry under Data Collector Sets and then select Start, Performance Monitor generates a report that you can review to evaluate performance and begin diagnostics for troubleshooting.
Although you can’t modify the system data collector sets that were created automatically, you can create new collector sets based on the predefined templates and then modify their settings. To do this, follow these steps:
In Performance Monitor, under the Data Collector Sets node, press and hold or right-click the User Defined node in the left pane, point to New, and then choose Data Collector Set.
In the Create New Data Collector Set Wizard, type a name for the data collector, such as Custom System Diagnostics. Create From A Template (Recommended) is selected by default, as shown in Figure 11-14. Tap or click Next.
On the Which Template Would You Like To Use page, shown in Figure 11-15, select the template to use or click Browse to search for a saved template. When you are ready to continue, tap or click Next.
On the Where Would You Like The Data To Be Saved page, type the root path to use for logging collected data. Alternatively, tap or click Browse and then use the Browse For Folder dialog box to select the logging directory. Tap or click Next when you are ready to continue.
On the Create The Data Collector Set page, the Run As box lists <Default> as the user to indicate that the log will run under the privileges and permissions of the default system account. To run the log with the privileges and permissions of another user, tap or click Change. Type the user name and password for the desired account and then tap or click OK. User names can be entered in DOMAINUSERNAME format, such as CPANDLWilliamS for the WilliamS account in the CPANDL domain.
Select Open Properties For This Data Collector Set and then tap or click Finish. This saves the data collector set, closes the wizard, and then opens the related Properties dialog box.
By default, logging is configured to start manually. To configure a logging schedule, tap or click the Schedule tab and then tap or click Add. You can now set the active range, start time, and run days for data collection. Figure 11-16 shows an example.
By default, logging stops only if you set an expiration date as part of the logging schedule. Using the options on the Stop Condition tab, you can configure the log file to stop manually after a specified period of time, such as seven days, or when the log file is full (if you set a maximum size limit).
Tap or click OK when you finish setting the logging schedule and stop conditions. You can manage the data collector as explained in “Creating and managing data collector sets” earlier in this chapter. If you want Windows to run a scheduled task when data collection stops, configure the tasks on the Task tab in the Properties dialog box.
Data collectors can be used to record performance data on the selected counters at a specific sampling interval. For example, you could sample performance data for the CPU every 15 minutes. The default location for logging is %SystemDrive%PerfLogsAdmin. Log files can grow in size very quickly. If you plan to log data for an extended period, be sure to place the log file on a drive with lots of free space. Remember, the more frequently you update the log file, the greater the drive space and CPU resource usage on the system.
To collect performance counter data, follow these steps:
In Performance Monitor, under the Data Collector Sets node, press and hold or right-click the User Defined node in the left pane, point to New, and then choose Data Collector Set.
In the Create New Data Collector Set Wizard, shown in Figure 11-17, type a name for the data collector, such as Memory Monitor or Physical Disk Monitor. Afterward, select Create Manually (Advanced) and then tap or click Next.
On the What Type Of Data Do You Want To Include page, Create Data Logs is selected by default. Select the Performance Counter check box and then tap or click Next.
On the Which Performance Counters Would You Like To Log page, tap or click Add. This opens the Add Counters dialog box, which you can use as previously discussed to select the performance counters to track. When you are finished selecting counters, tap or click OK.
On the Which Performance Counters Would You Like To Log page, type in a sample interval and select a time unit in seconds, minutes, hours, days, or weeks. The sample interval specifies when new data is collected. For example, if you sample every 15 minutes, the data log is updated every 15 minutes. Tap or click Next when you are ready to continue.
On the Where Would You Like The Data To Be Saved page, type the root path to use for logging collected data. Alternatively, tap or click Browse and then use the Browse For Folder dialog box to select the logging directory. Tap or click Next when you are ready to continue.
On the Create The Data Collector Set page, the Run As box lists <Default> as the user to indicate that the log will run under the privileges and permissions of the default system account. To run the log with the privileges and permissions of another user, tap or click Change. Type the user name and password for the desired account and then tap or click OK. User names can be entered in DOMAINUSERNAME format, such as CPANDLWilliamS for the WilliamS account in the CPANDL domain.
Select Open Properties For This Data Collector Set and then tap or click Finish. This saves the data collector set, closes the wizard, and then opens the related Properties dialog box.
By default, logging is configured to start manually. To configure a logging schedule, tap or click the Schedule tab and then tap or click Add. You can now set the active range, start time, and run days for data collection.
By default, logging stops only if you set an expiration date as part of the logging schedule. By using the options on the Stop Condition tab, you can configure the log file to stop manually after a specified period of time, such as seven days, or when the log file is full (if you set a maximum size limit).
Tap or click OK when you finish setting the logging schedule and stop conditions. You can manage the data collector as explained in “Creating and managing data collector sets” earlier in this chapter. If you want Windows to run a scheduled task when data collection stops, configure the tasks on the Task tab in the Properties dialog box.
You can use data collectors to record performance trace data whenever events related to their source providers occur. A source provider is an application or operating system service that has traceable events.
To collect performance trace data, follow these steps:
In Performance Monitor, under the Data Collector Sets node, press and hold or right-click the User-Defined node in the left pane, point to New, and then choose Data Collector Set.
In the Create New Data Collector Set Wizard, type a name for the data collector, such as Disk IO Trace or Logon Trace. Afterward, select Create Manually (Advanced) and then tap or click Next.
On the What Type Of Data Do You Want To Include page, Create Data Logs is selected by default. Select the Event Trace Data check box and then tap or click Next.
On the Which Event Trace Providers Would You Like To Enable page, tap or click Add.
In the Event Trace Providers dialog box, shown in Figure 11-18, select an event trace provider to track, such as Active Directory: NetLogon, and then tap or click OK.
On the Which Event Trace Providers Would You Like To Enable page, you can configure property values to track. By selecting individual properties in the Properties list and tapping or clicking Edit, you can track particular property values rather than all values for the provider. Repeat this process to select other event trace providers to track. Tap or click Next when you are ready to continue.
On the Where Would You Like The Data To Be Saved page, type the root path to use for logging collected data. Alternatively, tap or click Browse and then use the Browse For Folder dialog box to select the logging directory. Tap or click Next when you are ready to continue.
On the Create The Data Collector Set page, the Run As box lists <Default> as the user to indicate that the log will run under the privileges and permissions of the default system account. To run the log with the privileges and permissions of another user, tap or click Change. Type the user name and password for the desired account and then tap or click OK. User names can be entered in DOMAINUSERNAME format, such as CPANDLWilliamS for the WilliamS account in the CPANDL domain.
Select Open Properties For This Data Collector Set, and then tap or click Finish. This saves the data collector set, closes the wizard, and then opens the related Properties dialog box.
By default, logging is configured to start manually. To configure a logging schedule, tap or click the Schedule tab and then tap or click Add. You can now set the active range, start time, and run days for data collection.
By default, logging stops only if you set an expiration date as part of the logging schedule. Using the options on the Stop Condition tab, you can configure the log file to stop manually after a specified period of time, such as seven days, or when the log file is full (if you set a maximum size limit).
Tap or click OK when you finish setting the logging schedule and stop conditions. You can manage the data collector as explained in “Creating and managing data collector sets” earlier in this chapter. If you want Windows to run a scheduled task when data collection stops, configure the tasks on the Task tab in the Properties dialog box.
You can use data collectors to record changes in registry configuration. To collect configuration data, follow these steps:
In Performance Monitor, under the Data Collector Sets node, press and hold or right-click the User-Defined node in the left pane, point to New, and then choose Data Collector Set.
In the Create New Data Collector Set Wizard, type a name for the data collector, such as System Registry Info or Current User Registry Info. Afterward, select Create Manually (Advanced) and then tap or click Next.
On the What Type Of Data Do You Want To Include page, Create Data Logs is selected by default. Select the System Configuration Information check box and then tap or click Next.
On the Which Registry Keys Would You Like To Record page, tap or click Add. Type the registry path to track. Repeat this process to add other registry paths to track. Tap or click Next when you are ready to continue.
On the Where Would You Like The Data To Be Saved page, type the root path to use for logging collected data. Alternatively, tap or click Browse and then use the Browse For Folder dialog box to select the logging directory. Tap or click Next when you are ready to continue.
On the Create The Data Collector Set page, the Run As box lists <Default> as the user to indicate that the log will run under the privileges and permissions of the default system account. To run the log with the privileges and permissions of another user, tap or click Change. Type the user name and password for the desired account and then tap or click OK. User names can be entered in DOMAINUSERNAME format, such as CPANDLWilliamS for the WilliamS account in the CPANDL domain.
Select Open Properties For This Data Collector Set and then tap or click Finish. This saves the data collector set, closes the wizard, and then opens the related Properties dialog box.
By default, logging is configured to start manually. To configure a logging schedule, tap or click the Schedule tab and then tap or click Add. You can now set the active range, start time, and run days for data collection.
By default, logging stops only if you set an expiration date as part of the logging schedule. By using the options on the Stop Condition tab, you can configure the log file to stop manually after a specified period of time, such as seven days, or when the log file is full (if you set a maximum size limit).
Tap or click OK when you finish setting the logging schedule and stop conditions. You can manage the data collector as explained in “Creating and managing data collector sets” earlier in this chapter. If you want Windows to run a scheduled task when data collection stops, configure the tasks on the Task tab in the Properties dialog box.
When you’re troubleshooting problems, you’ll often want to log performance data over an extended period of time and then review the data to analyze the results. For each data collector that has been or is currently active, you’ll find related data collector reports. As with data collector sets themselves, data collector reports are usually organized into two general categories: user-defined and system-defined.
To view data collector reports in Performance Monitor, expand the Reports node and then expand the individual report node for the data collector you want to analyze. Under the data collector’s report node, you find individual reports for each logging session, as shown in Figure 11-19. A logging session begins when logging starts and ends when logging is stopped.
The most recent log is the one with the highest log number. To view a log and analyze its related data graphically, double-tap or double-click it. Keep in mind that if a data collector is actively logging, you won’t be able to view the most recent log. You can stop collecting data by pressing and holding or right-clicking a data collector set and selecting Stop. Collected data is shown by default in a graph view from the start of data collection to the end of data collection. Only counters that you selected for logging will be available. If a report doesn’t have a counter that you want to work with, you need to modify the data collector properties, restart the logging process, and then check the logs again.
Note
Open the most recent report for a data collector set directly by pressing and holding or right-clicking a data collector set and then selecting Latest Report. This shortcut works only if reports are available.
Save a data collector set as a template that can be used on the current server and other servers by pressing and holding or right-clicking a data collector set and then selecting Save Template. Next, in the Save As dialog box, select a save location, type a name for the template, and then tap or click Save.
You can modify the report details by using the following techniques:
In Performance Monitor, press and hold or right-click the Performance Monitor node and then select Properties. In the Performance Monitor Properties dialog box, tap or click the Source tab.
Specify data sources to analyze. Under Data Source, select Log Files and then tap or click Add to open the Select Log File dialog box. You can now select an additional log file to analyze.
Specify the time window that you want to analyze. Tap or click Time Range and then drag the Total Range bar to specify the appropriate starting and ending times. Drag the left edge to the right to move up the start time. Drag the right edge to the left to move down the end time.
Tap or click the Data tab. You can now select counters to view. Select a counter and then tap or click Remove to remove it from the graph view. Tap or click Add to open the Add Counters dialog box, which you can use to select the counters that you want to analyze.
Tap or click OK. In the monitor pane, tap or click the Change Graph Type button to select the type of graphing.
You can configure alerts to notify you when certain events occur or when certain performance thresholds are reached. You can send these alerts as network messages and as events that are logged in the application event log. You can also configure alerts to start applications and performance logs.
To configure an alert, follow these steps:
In Performance Monitor, under the Data Collector Sets node, press and hold or right-click the User-Defined node in the left pane, point to New, and then choose Data Collector Set.
In the Create New Data Collector Set Wizard, type a name for the data collector, such as Memory Alert or Full Disk Alert. Afterward, select Create Manually (Advanced) and then tap or click Next.
On the What Type Of Data Do You Want To Include page, select Performance Counter Alert and then tap or click Next.
On the Which Performance Counters Would You Like To Monitor page, shown in Figure 11-20, tap or click Add to open the Add Counters dialog box. This dialog box is identical to the Add Counters dialog box discussed previously. Use the Add Counters dialog box to add counters that trigger the alert. Tap or click OK when you’re finished.
In the Performance Counters panel, select the first counter and then use the Alert When text box to set the occasion when an alert for this counter is triggered. Alerts can be triggered when the counter is above or below a specific value. Select Above or Below and then set the trigger value. The unit of measurement is whatever makes sense for the currently selected counter or counters. For example, to alert if processor time is over 95 percent, you select Above and then type 95. Repeat this process to configure other counters you’ve selected and then tap or click Next.
On the Create The Data Collector Set page, the Run As box lists <Default> as the user to indicate that the log will run under the privileges and permissions of the default system account. To run the log with the privileges and permissions of another user, tap or click Change. Type the user name and password for the desired account and then tap or click OK. User names can be entered in DOMAINUSERNAME format, such as CPANDLWilliamS for the WilliamS account in the CPANDL domain.
Select Open Properties For This Data Collector Set and then tap or click Finish. This saves the data collector set, closes the wizard, and then opens the related Properties dialog box.
By default, logging is configured to start manually. To configure a logging schedule, tap or click the Schedule tab and then tap or click Add. You can now set the active range, start time, and run days for data collection.
By default, logging stops only if you set an expiration date as part of the logging schedule. Using the options on the Stop Condition tab, you can configure the log file to stop manually after a specified period of time, such as seven days, or when the log file is full (if you set a maximum size limit).
Tap or click OK when you finish setting the logging schedule and stop conditions. You can manage the data collector as explained in “Creating and managing data collector sets” earlier in this chapter. If you want Windows to run a scheduled task when data collection stops, configure the tasks on the Task tab in the Properties dialog box.
Windows Server 2012 R2 includes a command-line utility called Typeperf for writing performance data to the command line. You can use it to monitor the performance of both local and remote computers. The available parameters for Typeperf are summarized in Table 11-2.
Table 11-2. Parameters for Typeperf
Parameter | Description |
|---|---|
Specifies a file containing a list of performance counters to monitor. | |
–config <filename> | Specifies the settings file containing command options. |
–f <CSV|TSV|BIN|SQL> | Sets the output file format. The default is .csv for comma-separated values. |
–o <filename> | Sets the path of an output file or SQL database. |
–q [object] | Lists installed counters for the specified object. |
–qx [object] | Lists installed counters with instances. |
–s <ComputerName> | Sets the server to monitor if no server is specified in the counter path. |
–sc <samples> | Sets the number of samples to collect. |
–si <[[hh:]mm:]ss> | Sets the time between samples. The default is 1 second. |
–y | Answers Yes to all questions without prompting. |
It looks complicated, I know, but Typeperf is fairly easy to use after you get started. In fact, all you really need to provide to get basic monitoring information is the path to the performance counter you want to track. The performance counter path has the following syntax:
\ComputerNameObjectNameObjectCounter
Here, the path starts with the UNC computer name or IP address of the local or remote computer you are working with and includes the object name and the object counter to use. If you want to track SystemProcessor Queue Length on CORPSVR02, you type
typeperf "\corpsvr02SystemProcessor Queue Length"
Note
You might have noticed that I enclosed the counter path in double quotation marks. Although this is good form for all counter paths, it is required in this example because the counter path includes spaces.
You can also easily track all counters for an object by using an asterisk (*) as the counter name, such as in the following:
typeperf "\corpsvr02Memory*"
Here, you track all counters for the Memory object.
A slight problem is introduced for objects that have multiple instances. For these objects, such as the Processor object, you must specify the object instance you want to work with. The syntax for this is as follows:
\ComputerNameObjectName(ObjectInstance)ObjectCounter
Here, you follow the object name with the object instance in parentheses. To work with all instances of an object that has multiple instances, you use _Total as the instance name. To work with a specific instance of an object, use its instance identifier. For example, if you want to examine the Processor\%Processor Time counter, you must use either the following to work with all processor instances:
typeperf "\corpsvr02Processor(_Total)\%Processor Time"
or the code shown next to work with a specific processor instance:
typeperf "\corpsvr02Processor(0)\%Processor Time"
In this case, that is the first processor on the system.
By default, Typeperf writes its output to the command line in a comma-delimited list. You can redirect the output to a file by using the –o parameter and set the output format by using the –f parameter. The output format indicators are CSV for a comma-delimited text file, TSV for a tab-delimited text file, BIN for a binary file, and SQL for a SQL binary file. Consider the following example:
typeperf "\corpsvr02Memory*" -o perf.bin -f bin
Here, you track all counters for the Memory object and write the output to a binary file called Perf.bin in the current directory.
If you need help determining the available counters, type typeperf –q followed by the object name for which you want to view counters, such as in the following:
typeperf -q Memory
If an object has multiple instances, you can list the installed counters with instances by using the –qx parameter, such as in the following:
typeperf -qx PhysicalDisk
You can use this counter information as input to Typeperf as well. Add the –o parameter and write the output to a text file, such as in the following:
typeperf -qx PhysicalDisk -o perf.txt
Then, edit the text file so that only the counters you want to track are included. You can then use the file to determine which performance counters are tracked by specifying the –cf parameter followed by the file path to this counter file. Consider the following example:
typeperf -cf perf.txt -o c:perflogsperf.bin -f bin
Here, Typeperf reads the list of counters to track from Perf.txt and then writes the performance data in binary format to a file in the C:PerfLogs directory.
The one problem with Typeperf is that it will sample data once every second until you tell it to stop by pressing Ctrl+C. This is fine when you are working at the command line and monitoring the output. It doesn’t work so well, however, if you have other things to do—and most administrators do. To control the sampling interval and set how long to sample, you can use the –si and –sc parameters, respectively. For example, if you want Typeperf to sample every 60 seconds and stop logging after 120 samples, you could type this:
typeperf -cf perf.txt -o C:perflogsperf.bin -f bin -si 60 -sc 120
You can examine trace log data by using the Tracerpt command-line utility. Tracerpt processes trace logs, and you can use it to generate trace analysis reports and dump files for the events generated. Commonly used parameters for Tracerpt are summarized in Table 11-3.
Table 11-3. Parameters for Tracerpt
Parameter | Description |
|---|---|
–o [filename] | Sets the text output file to which the parsed data should be written. The default is Dumpfile.xml. |
–summary [filename] | Sets the name of the text file to which a summary report of the data should be written. The default is Summary.txt. |
–report [filename] | Sets the name of the text file to which a detailed report of the data should be written. The default is Workload.xml. |
–rt <session_name [session_name …]> | Sets the real-time event trace session data source to use instead of a converted log file. |
–config <filename> | Specifies a settings file containing command options. |
–y | Answers Yes to all questions without prompting. |
-of <CSV|EVTX|XML> | Sets the dump file format. |
-f <XML|HTML> | Sets the report file format. |
–export <filename> | Sets the name of the event schema export file. The default is schema.man. |
The most basic way to use Tracerpt is to specify the name of the trace log to use. By default, 1trace logs are written to C:PerfLogs. So, if a log in this directory was named SysP_000002.etl, you could analyze it by typing the following:
tracerpt C:PerflogsSysP_000002.etl
Here, four files are created in the current directory. The parsed output is written to Dumpfile.xml, a summary report is written to Summary.txt, a detailed report is written to Workload.xml, and an event schema report file is written to schema.man.
You could also specify the exact files to use for output as shown in the following example:
tracerpt C:Perflogs SysP_000002.etl -o c:sysp.csv -summary c:sysp-summary.txt -report sysp-report-.txt