Perfmon which counters to use

Here comes the secret sauce: we want formulas across the top to quickly summarize our findings. In the B column, put in the formulas. Finally, the icing on the cake: hit Control-Home, then move your cursor to cell B9, which should be your first cell with data. Now for the detective work! There are a lot of smart people out there who have some great ways of interpreting Perfmon results.

There are more in-depth Perfmon metrics that you can add to your capture if you see the Processor Queue Length showing up, but for junior DBAs, the first thing I would recommend is simply remote desktop into the SQL Server. Right-click on the taskbar, click Task Manager, and click on the Processes tab.

Check the box that shows processes for all users, and then click on the CPU column to sort the CPU percentage from high to low. Sit and watch it for a minute or two.

Which processes are using CPU power? Generally speaking, enabling hyperthreading on a SQL Server is not going to fix that kind of a problem. On the Memory — Available MBytes statistic, look for fluctuations of a couple hundred megabytes or more. Correlate these fluctuations with disk activity: when available memory drops, is disk activity also increasing?

Is this disk activity affecting the page file drive? Windows may be paging out your application to disk in order to keep some breathing room free for the OS.

As we examine the disk numbers, make a mental note of which drive has the page file — and there may be multiple page files as well. Also, find out if one physical drive array is shared by multiple drive letters. This is especially important for servers that boot from SAN: the boot drive may contain the page file, and that boot drive may be on a shared set of spindles with several drive letters.

Heavy page file activity will slow down access to all of the affected drive letters in Windows. Another caveat: mount points. If the shop uses mount points, a drive letter may be broken up into several sets of physical drive arrays.

Learn more, see sample deliverables, and book a free minute call with Brent. Want to advertise here and reach my savvy readers? To describe this simply, it's really the amount of time the processor spent executing any user application code.

On single core machines a sustained value greater than can mean that you have some CPU pressure. Similarly, for a multicore machine divide the queue length by the number of cores and if that is continuously greater than there might be CPU pressure. If this value is lower than this then it's not necessarily an issue provided the system is not doing a lot of paging.

If you are paging then further troubleshooting can be done to see which individual processes are using most of the memory. Small spikes with this value do not mean there is an issue but sustained values of greater than 50 can mean that system memory is a bottleneck. This is not directly related to performance, but you can run into serious application issues if the page file does become completely full and additional memory is still being requested by applications.

Best regards,. This can be beneficial to other community members reading this thread. Office Office Exchange Server. Not an IT pro? The only general exception to this rule occurs during system backup periods because this is usually performed in a mode that is charged to the Windows overhead work category.

Expect this value to be higher on the processor s that handle network connections. The most consistent example of deferred interrupts involves network packets. A system that is handling an enormous amount of network traffic will always exhibit high numbers of deferred interrupts. Beginning with Windows Server , network packets are handled my multiple processors, although only a single processor handles any given network connection. Although this metric can be captured for the entire processor complex or for an individual processor, it is best to collect for each processor, and if its value is consistently greater than 25 percent for any single processor , deferred interrupt handling activities are unusually high and should be investigated using Resource Monitor or Event Tracing for Windows ETW.

The only general exception to this rule occurs during system backup periods because this is usually performed in a mode that is charged to the Windows overhead work category and the network is generally utilized extensively. This metric measures the amount of time that one or more physical or logical depending upon the object disk LUNs are NOT busy performing any kind of work.

This metric is only useful when applied to a specific disk LUN; the aggregate value is meaningless except in a capacity planning context. If this value is LESS than 40 percent for long periods, the physical or logical disk LUN is struggling to keep up with the presented workload. Disk response times often increase exponentially as this value approaches zero. In this situation, either the workload should be reduced or the hardware should be upgraded.

If this value is greater than 0. This value can be especially useful in RAID 5 environments because it will indicate clearly when the disk LUN is asked to handle too many writes. If this occurs, the write workload should be reduced or a different level of RAID should be used, if appropriate. This metric measures the amount of memory available to Windows. Note: this value often includes memory that has been allocated to the Windows cache, so you may observe values that appear to be double-counted as shown in the picture below.