This page shows the selected system's daily stats for the selected date.
Using the navigation tools on the top right of the page, you can quickly go to this system's Current, Hourly, Weekly or Monthly stats. You can also quickly jump to a specific day to display stats for, or do the same for another system.
You can also use the "Navigate To" menu to quickly jump down the page to the specific stats you want. Also, under each statistic there are links that will allow you to jump to that specific hour, as well as "<" and ">" navigation points that allow you to jump to the previous/next day's stats.
For graphs that show only the Min, Max and Avg values for a single performance counter, the red line displays the Average value, while the light blue represents the range between the Mininum and Maximum values.
These performance counters were selected to allow you to easily check each system's subsytem (CPU, Memory, Disk, Network) for any possible bottlenecks. We also selected counters that allow you to see how much user load the system is under.
To get a full description / explanation of the Performance Counters listed, simply click on the section's title for more information.
This section provides the daily Windows System, Application and Security Logs. Click the corresponding button to show the relevant data.
This shows all Warning and Critical Windows Application Log events during the collected period. If the button is not shown, then either there were no Events detected, or the Application Log Entries were not collected due to lack of Operating System functionality.
This shows all Warning and Critical Windows System Log events during the collected period. If the button is not shown, then either there were no Events detected, or the System Log Entries were not collected due to lack of Operating System functionality.
This shows all Security Failures from the Windows Security Log during the collected period. If the button is not shown, then either there were no Events detected, or the Security Log Entries were not collected due to configuration or lack of Operating System functionality.
The Processor % Usage graph shows how much the processor(s) is being utilized. This is one of the primary indicators of a possible processor bottleneck. If the Total Processor CPU Usage is constantly high, it is recommended to take corrective action, such as moving applications or upgrading the Processor(s) or add additional Processor(s).
If the CPU % Usage is high, to confirm that there could be a processor bottleneck, check the CPU Queue Length Stats.
On multi-core/CPU systems it is generally a good idea to first look at the Total CPU usage since having 8, 16 or 32 graph points can be distracting and can cause some less than technical people to think there is a CPU issue if there are quite a few spikes on individual CPUs. With the Total % Processor Time stats it is also quite a bit easier to locate "patterns" where single threaded processes consume 100% of a thread (for instance, constant 25% usage on a 4 core system).
Microsoft® Description: % Processor Time is the percentage of elapsed time that the processor spends to execute a non-Idle thread. It is calculated by measuring the percentage of time that the processor spends executing the idle thread and then subtracting that value from 100%. (Each processor has an idle thread that consumes cycles when no other threads are ready to run). This counter is the primary indicator of processor activity, and displays the average percentage of busy time observed during the sample interval. It should be noted that the accounting calculation of whether the processor is idle is performed at an internal sampling interval of the system clock (10ms). On today’s fast processors, % Processor Time can therefore underestimate the processor utilization as the processor may be spending a lot of time servicing threads between the system clock sampling interval. Workload based timer applications are one example of applications which are more likely to be measured inaccurately as timers are signaled just after the sample is taken.
Even though it is easier to see patterns in the combined CPU graph, there are times when it is recommended to also view the individual CPU stats in a multi-cpu/core system, especially when a program is written to take full control of the processor(s).
The Physical Memory Statistics show the available Performance Counters for everything that consumes "Physical Memory" on a Windows® Server. In theory, adding all of these counters together should equal the amount of RAM installed, but in practice this does not work. This is the result of Windows® using shared DLLs and some RAM allocations that are not counted anywhere (such as trimmed working set pages that have yet to be written to disk).
The Available Bytes counter is the pool size of available pages in RAM that the system uses to satisfy requests for new pages. There are multiple counters available for convenience that provide this information, such as Available Mbytes, but this program uses the Available Bytes counter and does the calculation when generating the graphs.
Usually when this value is approximately at least 10% of total system memory, the system has an adequate amount of memory. However when this value is below 10% you must use additional counters, such as Pages/sec to determine if System memory is adequate for the workload.
Note that the "\Memory\Available Bytes" counter is an instantaneous counter (sampled once during the measurement period).
Microsoft® Description: Available Bytes is the amount of physical memory, in bytes, immediately available for allocation to a process or for system use. It is equal to the sum of memory assigned to the standby (cached), free and zero page lists.
The Working Set counter is the total amount of resident pages allocated in RAM that all the processes that are running on the system can address without causing a Page Fault. The value of this counter is in bytes, but this program does the calculation to MB when it creates the graphs.
Note that the "\Process(_Total)\Working Set" counter is an instantaneous counter (sampled once during the measurement period).
Microsoft® Description: Working Set is the current size, in bytes, of the Working Set of this process. The Working Set is the set of memory pages touched recently by the threads in the process. If free memory in the computer is above a threshold, pages are left in the Working Set of a process even if they are not in use. When free memory falls below a threshold, pages are trimmed from Working Sets. If they are needed they will then be soft-faulted back into the Working Set before leaving main memory.
The Memory pages that the System uses are counted in two main counters, Cache Bytes and Pool Nonpaged Bytes.
The Cache Bytes counter is the amount of resident pages allocated in RAM that the Kernel threads can address without causing a Page Fault. This counter includes the Pool Paged Resident Bytes, the System Cache Resident Bytes, the System Code Resident Bytes and the System Driver Resident Bytes.
Note that the "\Memory\Cache Bytes" counter is an instantaneous counter (sampled once during the measurement period).
Microsoft® Descripton: Cache Bytes the size, in bytes, of the portion of the system file cache which is currently resident and active in physical memory. The Cache Bytes and Memory\\System Cache Resident Bytes counters are equivalent. This counter displays the last observed value only; it is not an average.
The Pool Nonpaged Bytes counter is the amount of resident pages in RAM that the Kernel is using that cannot be paged out. This memory cannot be accessed by user processes, thus troubleshooting Non-Paged Pool Memory issues can be extremely difficult.
Note that the "\Memory\Pool Nonpaged Bytes" counter is an instantaneous counter (sampled once during the measurement period).
Microsoft® Description: Pool Nonpaged Bytes is the size, in bytes, of the nonpaged pool, an area of the system virtual memory that is used for objects that cannot be written to disk, but must remain in physical memory as long as they are allocated. Memory\\Pool Nonpaged Bytes is calculated differently than Process\\Pool Nonpaged Bytes, so it might not equal Process(_Total)\\Pool Nonpaged Bytes. This counter displays the last observed value only; it is not an average.
In addition to the Processor and Memory counters above, there are additional counters that can detect how the System is being worked and if the Processor or Memory Subsystems could potentially be bottlenecks.
The Processor(_total)\% Privileged Time counter shows the percent of time that the processor is spent executing in Kernel (or Privileged) mode. Privileged mode includes services interrupts inside Interrupt Service Routines (ISRs), executing Deferred Procedure Calls (DPCs), Device Driver calls and other kernel-mode functions of the Windows® Operating System.
Most of the time a processor should be executing User mode operations, a high % privileged time might indicate a poorly written device driver or a faulty piece of hardware.
Microsoft® Description: % Privileged Time is the percentage of elapsed time that the process threads spent executing code in privileged mode. When a Windows system service in called, the service will often run in privileged mode to gain access to system-private data. Such data is protected from access by threads executing in user mode. Calls to the system can be explicit or implicit, such as page faults or interrupts. Unlike some early operating systems, Windows uses process boundaries for subsystem protection in addition to the traditional protection of user and privileged modes. Some work done by Windows on behalf of the application might appear in other subsystem processes in addition to the privileged time in the process.
The Processor(_total)\% User Time counter shows the percent of time that the processor(s) is spent executing in User mode.
Microsoft® Description: % User Time is the percentage of elapsed time the processor spends in the user mode. User mode is a restricted processing mode designed for applications, environment subsystems, and integral subsystems. The alternative, privileged mode, is designed for operating system components and allows direct access to hardware and all memory. The operating system switches application threads to privileged mode to access operating system services. This counter displays the average busy time as a percentage of the sample time.
The Processor Queue Length shows the number of threads that are observed as delayed in the processor Ready Queue and are waiting to be executed.
On single core machines, a sustained value over 5-10 or so may indicate that the workload on the system is more than the processor can handle. On multi-core systems, a good rule of thumb is to divide the Queue Length by the number of cores in the system and use the same indication above with that calculated value.
Note that the Processor Queue Length is an instantaneous counter, whereas the % Processor Usage counters are continuously measured counters that are averaged. There could be some disconnect between these counters because of this.
Microsoft® Description: Processor Queue Length is the number of threads in the processor queue. Unlike the disk counters, this counter counters, this counter shows ready threads only, not threads that are running. There is a single queue for processor time even on computers with multiple processors. Therefore, if a computer has multiple processors, you need to divide this value by the number of processors servicing the workload. A sustained processor queue of less than 10 threads per processor is normally acceptable, dependent of the workload.
The PageFile Percent Usage counter shows what percent of the current pagefile is being used. Although not truly related to Performance, it is highly recommended to keep an eye on the Pagefile % Usage counter to ensure it does not reach 100%, which could cause severe system and application issues.
Using this counter, you could potentially identify memory issues that are not noticeable from the Memory counters. Many Applications with memory leaks tend to show themselves more in the Pagefile than in Physical Memory
Note that if you allow Windows® to manage the pagefile, this counter may not be beneifical.
Microsoft® Description: The amount of the Page File instance in use in percent. See also Process\\Page File Bytes.
Memory shortages on Windows® can be identified by using the Paging counters available in Performance Monitor. The key counters that this program provides stats for are described below. When dealing with Windows® Paging you have to keep in mind that paging occurs for various operations within Windows® and excessive paging doesn’t automatically indicate a memory shortage. For instance, many network card drivers utilize the Pagefile (sometimes excessively) and this can be misread as a memory shortage.
The Pages/sec counter is a primary indicator to determine if the system’s memory is a bottleneck. The Pages/sec counter is the sum of both the Pages Input/sec and Pages Output/sec, some performance guides reference these directly, but we have decided to just graph the combined value.
A System that is showing possible memory constraints with the Physical Memory Counters and with a sustained value over 20 should be closely monitored. Again, it is normal for this to spike occasionally, especially if the other Memory counters do not show a lack of System Memory.
Microsoft® Description: Pages/sec is the rate at which pages are read from or written to disk to resolve hard page faults. This counter is a primary indicator of the kinds of faults that cause system-wide delays. It is the sum of Memory\\Pages Input/sec and Memory\\Pages Output/sec. It is counted in numbers of pages, so it can be compared to other counts of pages, such as Memory\\Page Faults/sec, without conversion. It includes pages retrieved to satisfy faults in the file system cache (usually requested by applications) non-cached mapped memory files.
The Page Reads/sec is another counter to watch for memory issues. This counter is a complement to the Pages/sec counter since it is directly related to how much the disk is affected from paging operations. In some systems, this (along with Page Writes/sec) might be a better indicator of possible memory/paging issues than just the Pages/sec counter.
Microsoft® Description: Page Reads/sec is the rate at which the disk was read to resolve hard page faults. It shows the number of reads operations, without regard to the number of pages retrieved in each operation. Hard page faults occur when a process references a page in virtual memory that is not in working set or elsewhere in physical memory, and must be retrieved from disk. This counter is a primary indicator of the kinds of faults that cause system-wide delays. It includes read operations to satisfy faults in the file system cache (usually requested by applications) and in non-cached mapped memory files. Compare the value of Memory\\Pages Reads/sec to the value of Memory\\Pages Input/sec to determine the average number of pages read during each operation.
The Page Writes/sec is another counter to watch for memory issues. This counter is a complement to the Pages/sec counter since it is directly related to how much the disk is affected from paging operations.
Microsoft® Description: Page Writes/sec is the rate at which pages are written to disk to free up space in physical memory. Pages are written to disk only if they are changed while in physical memory, so they are likely to hold data, not code. This counter shows write operations, without regard to the number of pages written in each operation. This counter displays the difference between the values observed in the last two samples, divided by the duration of the sample interval.
The Avg. Disk sec/Write counter displays how long in milliseconds it takes for a write operation to the Disk. Watch this counter during times of heavy disk utilization to see if your system would benefit from a more robust Disk Subsystem (such as advanced RAID or newer flash drive technologies).
Microsoft® Description: Avg. Disk sec/Write is the average time, in seconds, of a write of data to the disk.
The Avg. Disk sec/Read displays how long in milliseconds it takes for a read operation from the Disk. Watch this counter during times of heavy disk utilization to see if your system would benefit from a more robust Disk Subsystem (such as advanced RAID or newer flash drive technologies).
Microsoft® Description: Avg. Disk sec/Read is the average time, in seconds, of a read of data from the disk.
The Split IO/sec counter displays the physical disk requests that are split into multiple requests.
This counter is a primary indicator if a disk is fragmented and needs to be optimized.
Microsoft® Description: Split IO/Sec reports the rate at which I/Os to the disk were split into multiple I/Os. A split I/O may result from requesting data of a size that is too large to fit into a single I/O or that the disk is fragmented.
There are two main counters for the Disk Queue Length (number of requests waiting or being processed), the Average Disk Queue Length and the Current Disk Queue Length. There are arguments for only using either counter, so to stay out of the debate on which to use, we simply show values for both counters.
The Current Disk Queue Length counter is the actual number of requests that are either in process or waiting to be processed by the Disk at the time the counter is captured.
Sustained counters above 5 per Disk could indicate a disk subsystem bottleneck. Remember to also keep an eye on the Pages/sec counter for low memory issues since low memory could cause Disk performance issues if the disk subsystem has to continuously process paging operations.
Microsoft® Description: Current Disk Queue Length is the number of requests outstanding on the disk at the time the performance data is collected. It also includes requests in service at the time of the collection. This is a instantaneous snapshot, not an average over the time interval. Multi-spindle disk devices can have multiple requests that are active at one time, but other concurrent requests are awaiting service. This counter might reflect a transitory high or low queue length, but if there is a sustained load on the disk drive, it is likely that this will be consistently high. Requests experience delays proportional to the length of this queue minus the number of spindles on the disks. For good performance, this difference should average less than two.
The Avg. Disk Queue Length counter is the “estimated” average number of requests that are either in process or waiting to be processed by the Disk.
Microsoft® Description: Avg. Disk Queue Length is the average number of both read and write requests that were queued for the selected disk during the sample interval.
The Disk Read Bytes/sec shows the Disk Throughput of the Read Operation of the Disk. This is normally displayed in bytes, but we do the calculation when graphing the counter to display it in the standard MB/sec.
Microsoft® Description: Disk Read Bytes/sec is the rate at which bytes are transferred from the disk during read operations.
The Disk Write Bytes/sec shows the Disk Throughput of the Write Operation of the Disk. This is normally displayed in bytes, but we do the calculation when graphing the counter to display it in the standard MB/sec.
Microsoft® Description: Disk Write Bytes/sec is rate at which bytes are transferred to the disk during write operations.
The Network Interface Bytes Received/sec shows the Network Received Throughput of the NIC. This is normally displayed in bytes, but we do the calculation when graphing the counter to display it in the standard MB/sec.
Microsoft® Description: Bytes Received/sec is the rate at which bytes are received over each network adapter, including framing characters. Network Interface\Bytes Received/sec is a subset of Network Interface\Bytes Total/sec.
The Network Interface Bytes Sent/sec shows the Network Send Throughput of the NIC. This is normally displayed in bytes, but we do the calculation when graphing the counter to display it in the standard MB/sec.
Microsoft® Description: Bytes Sent/sec is the rate at which bytes are sent over each network adapter, including framing characters. Network Interface\Bytes Sent/sec is a subset of Network Interface\Bytes Total/sec.
The Application Connections counters show how many connections and unique ip addresses are connected at a specific time to a specific port(s). This data provides you with the user load of the specific application that is being monitored.
Note that this is not a Microsoft® Perfmon counter, but a custom counter developed for the SPASS product.
The Total Application Connections is the number of network connections that are connected to the server on a specific port(s).
The Total Unique Connections is the number of different IP addresses / hosts that are connected to the server on a specific port(s).
The IIS / Webservice stats allows you to monitor the user load on the server's web services. This data is beneficial for future sizing requirements. These counters are self-explanatory, so only Microsoft's Description is shown below:
Microsoft® Description: Current Connections is the current number of connections established with the Web service.
Microsoft® Description: Current Anonymous Users is the number of users who currently have an anonymous connection using the Web service.
Microsoft® Description: Current NonAnonymous Users is the number of users who currently have a non-anonymous connection using the Web service.
Microsoft® Description: The rate HTTP requests using the GET method are made. Get requests are the most common HTTP request.
Microsoft® Description: The rate HTTP requests using the PUT method are made.
Microsoft® Description: The rate HTTP requests using the POST method are made.
The SQLServer User Connections counter allows you to monitor the number of connected users.
Microsoft® Description: Number of users connected to the system.
The SQL Compilations/Sec counter displays the number of times SQL Server compiles an execution plan per second.
Microsoft® Description: Number of SQL compilations.
The SQL Re-Compilations/Sec counter displays the number of times SQL Server re-compiles an execution plan per second.
When the execution plan is invalidated due to some significant event, SQL Server will re-compile it. Re-compiles, like compiles, are expensive operations so you want to minimize the number of re-compiles.
Optimally, this counter should be less than 10% of the number of Compilations/Sec.
Microsoft® Description: Number of SQL re-compiles.
Batch Requests/Sec counter shows the number of batches SQL Server is receiving per second.
This counter is a good indicator of how much activity is being processed by your SQL Server box.
Microsoft® Description: Number of SQL batch requests received by server.
The SQLServer: Databases: Log Flushes/sec counter measures the number of log flushes per second. This graph shows the total Log Flushes across all Databases.
The log cache is a place in memory that SQL Server records data to be written to the log file. The log cache is used to roll back a transaction before it is committed, if the circumstances call for it. If this is a high value it may cause a disk bottleneck.
Every INSERT statement creates a Log Flush, if you are seeing a lot of Log Flushes it might be worthwhile to optimize your queries to reduce the amount of INSERT statements, which reduces Log Flushes, which will reduce Disk I/O
Microsoft® Description: Number of log flushes.
The SQLServer:Buffer Manage\Lazy Writes/Sec counter tracks how many time a second that the Lazy Writer process is moving dirty pages from the buffer to disk in order to free up buffer space.
Normally, this should not be a high value (less than 20/sec or so). Optimally, it should be close to zero. If this value is high, it might be an indication that more memory is needed.
Microsoft® Description: Number of buffers written by buffer manager's lazy writer.
The SQLServer:Access Methods\Page Splits/sec counter measures the number of times SQL Server had to split a page when updating or inserting data per second. Page splits are expensive, and cause your table to perform more poorly due to fragmentation. The fewer page splits you have the better your system will perform.
Optimally, this counter should be less than 10%-20% of the batch requests per second.
Microsoft® Description: Number of page splits per second that occur as a result of overflowing index pages.
The buffer cache hit ratio counter represents how often SQL Server is able to find data pages in its buffer cache when a query needs a data page.
You want this number to be as close to 100 as possible. A low buffer cache hit ratio could indicate a memory problem.
Microsoft® Description: Percentage of pages that were found in the buffer pool without having to incur a read from disk.
The SQLServer:Memory Manager\SQL Cache Memory (KB) counter specifies the total amount of dynamic memory the server is using for the dynamic SQL plan cache.
If you see sudden drops over time for this counter, it might be an indication that the instance is under memory pressure and SQL Server had to reclaim part of the plan cache for other use by SQL Server, which causes this counter to suddenly decrease.
If you see sudden increases in this counter, this may indicate that a large number of one-time use ad hoc queries may have been executed, causing plan cache pollution. If this is a long term condition, consider turning on the “optimize for ad hoc workloads” instance-level option to stop plan cache pollution.
Microsoft® Description: Total amount of dynamic memory the server is using for the dynamic SQL cache
The SQLServer:Memory Manager: Total Server Memory (KB) tells you how much the mssqlserver service is currently using. This includes the total of the buffers committed to the SQL Server BPool and the OS buffers of the type "OS in Use".
Microsoft® Description: Total amount of dynamic memory the server is currently consuming
The SQLServer:Memory Manager: Target Server Memory (KB) counter tells you how much memory SQL Server would like to have in order to operate efficiently. This is based on the number of buffers reserved by SQL Server when it is first started up.
If the SQLServer:Memory Manager: Total Server Memory (KB) counter is more than the SQLServer:Memory Manager: Target Server Memory (KB) counter, this may indicate that SQL Server may be under memory pressure and could use access to more physical memory.
Microsoft® Description: Ideal amount of memory the server is willing to consume
The processes blocked counter displays the number of blocked processes.
When one process is blocking another process, the blocked process cannot move forward with its execution plan until the resource that is causing it to wait is freed up. Optimally you don't want to see any blocked processes
Microsoft® Description: Number of currently blocked processes.
The SQLServer:Locks(_total)\Number of DeadLocks/sec counter displays the number of lock requests per second that resulted in a Deadlock. Since this number is per second, this number should not be high.
Use the Number of Deadlocks/sec counter on a regular basis to get an idea of what appears normal and if you discover deadlock problems use the Profiler to investigate further.
Microsoft® Description: Number of lock requests that resulted in a deadlock.
The SQL Server:Locks\Average Wait Time (ms) counter measures the average wait time of a variety of locks, including: database, extent, Key, Page, RID, and table.
You can use this counter to get a baseline value for the Average Wait Time on your servers, then investigate further if you see unexpected values.
Microsoft® Description: The average amount of wait time (milliseconds) for each lock request that resulted in a wait.
The SQLServer:Latches\Average Latch Wait Time (ms ) counter measures the wait time (in milliseconds) for latch requests that have to wait (A latch is basically a lightweight lock).
This is a measurement for only those latches whose requests had to wait, not all latches. In many cases, there is no wait.
Microsoft® Description: Average latch wait time (milliseconds) for latch requests that had to wait.
The Disk Space Statistics are useful for preventative and sizing requirements and can be beneficial for troubleshooting some issues, such as large SQL Queries that consume TempDB space, sudden Memory Dumps, etc.
We show 3 different stats for the Disk Usage:
This allows you to visually see the space usage of each drive in the system so you can take corrective action if needed.
This allows you to quickly see the space usage for each drive.
This allows you to quickly see how much space is available for each drive.