1. Rick Heiges, SQL Server MVP
Perfmon Basics
Rick Heiges, SQL Server MVP

2. Thank You to Our Sponsors Our Venue SQLPASS Richmond Chapter
Volunteers for SQL Saturday #381
Our Speakers

3. THANK YOU!!! For Giving Up Your Saturday
For Not Giving Up on that One Problem
For Wanting to Continue to Learn
For Not Wanting to Stagnate in Your Career

4. Who am I? Independent Experts, Real World Answers Board of Directors

5. Thank You Sponsors!!!

6. About the Presenter Rick HeigesSQL Server MVP
MCP, MCSE, MCDBA, MCTS: SQL2005, MCITP: DBA
MBA, MS-MIS, BSCS
PASS – Director
Founder – Triad SQL Server User Group
Presented at PASS, local user groups, SQL Server Road Shows, DevTeach (Top 5 SQL Track), SQL Connections, SQL Saturdays
BLOG on sqlblog.com Follow Me on Twitter: @heigesr2
Articles in SQL Server Standard, Windows IT Pro
Webcasts - SQL 2005/8/R2, 64-bit Computing, Consolidation
Ambassador at TechEd

7. Agenda The Perfmon Tool
Real-time Monitoring / Analysis of Selected Counters
Methods of Capturing a Log
Baselines
Reviewing a Log – Analysis
PAL – Free Tool
Relog

8. Perfmon Once referred to as Sysmon
Also called Performance and Reliability Monitor in Vista
Part of every Windows OS
Usually considered a “light-weight” process
Real-Time Monitor or view a log
Collect data from other systems

9. Demo 1
Perfmon Tool
Show getting into perfmon Tool and how to add/remove counters

10. Real-Time Monitoring Local or Remote System Scroll or Wrap
Duration – Properties
Freeze / Update / Resume
Pro: See what is Happening Now
Con: No Evidence

11. Selected Counters CPU Counters Memory \Processor\% Processor Time
\System\Processor Queue Length
\System\Context Switches/sec
Memory
\Memory\Pages/sec
\SQLServer:Buffer Manager\PageLifeExpectancy
\SQLServer:Buffer Manager\LazyWrites/Sec
\SQLServer:Cache Manager\Cache Hit Ratio
\SQLServer:Memory Manager\Memory Grants Pending
Perhaps the best known counter is \Processor\% Processor Time. This is one of the simplest to understand. The “_Total” counter is probably the most important. It is an average of all processors on the server. If this counter is above 80% for sustained periods of time, it is a good indicator of CPU pressure.
Another counter that is fairly simple to understand is \System\Processor Queue Length. This counter indicates how many tasks are currently waiting to be processed. The Total queue length is for all processors in the environment. If this value is 20 on a 4 core system, the result would be 5 as the queue length is divided by the number of cores. Any result of 2 or greater for this counter indicates a CPU bottleneck.
Another counter that is often interrogated is \System\Context Switches/sec. This value is the number of times that the CPUs have switched from privileged to user mode. This value should be less than 1000 per core. If the \Processor\% Processor Time counter is below 50%, the \System\Context Switches/sec counter value should not be considered as a sign of CPU pressure by itself. A high value of context switching with a low CPU utilization often indicates that another service (printing, network monitor, etc.) is the cause.
The cause of CPU pressure is most likely “bad code”. Application code that utilizes cursors and dynamic SQL are often the sources of this performance-robbing effect. Although there are many ways to eliminate this “bad code”, often the IT department is powerless to affect the change.
\Memory\Pages/sec is a counter which represents the number of pages that are read or written from SQL Server. This value should remain less than 5 or as close to 0 as possible. If this value is at 20 or more, there is pressure on the memory and possibly the IO subsystem.
\SQLServer:Buffer Manager\PageLifeExpectancy (PLE)represents how long a page read from disk can expect to stay in memory before being flushed out. With this counter, the smaller the value – the bigger the problem or below is considered serious pressure on memory. Any sustained PLE value of 1000 or less may be considered a leading indicator of memory pressure.
\SQLServer:Buffer Manager\LazyWrites/Sec measures the number of times the Lazy Writer process is called to move dirty pages from the Buffer Pool to Disk. Ideally, this value should be close to zero. Any sustained value of 20 or greater indicates that your Buffer Pool may be too small and memory pressure is possible.
\SQLServer:Cache Manager\Cache Hit Ratio indicates how often SQL Server reads from the cache instead of needing to read from disk. This value should ideally remain above 90%. There are subcategories of counters below this level that may be interrogated to reveal what segment of the buffer cache is having the difficulty.
\SQLServer:Memory Manager\Memory Grants Pending is an indicator of memory pressure when the value is greater than zero. This counter represents the number of processes waiting per second for workspace.
These counters are commonly referred to in order to reveal memory pressure. This is not an exhaustive list, but it is a solid base on which a determination may be made if memory pressure is likely.

12. Selected Counters (Cont.)
IO Counters
\PhysicalDisk(*)\Disk Transfers/sec
\PhysicalDisk(*)\Disk Read Bytes/sec
\PhysicalDisk(*)\Disk Write Bytes/sec
\Process(sqlservr)\IO Data Operations/sec
\SQLServer:Databases(*)\Transactions/sec
\PhysicalDisk\Avg Sec/Transfer
Network
\Network Interface(*)\Bytes Total/sec
There are Many Others!
\PhysicalDisk(*)\Disk Transfers/sec represents the number of reads/writes per second. This essentially can be used to determine the number of IO operations per second (IOPS) needed for the databases located on this system. This counter does not really have a value that represents good or bad; it just represents the number of IOPS that will be needed to be handled in the consolidated environment for this server. Summing up the “Max Average” for all systems in the scope of a consolidated effort will help to determine the IOPS required by the storage subsystem for the consolidated environment.
\PhysicalDisk(*)\Disk Read Bytes/sec represents the number of bytes read per second. This counter is another counter that really does not have a good or bad value as an indicator. This value in conjunction with \PhysicalDisk(*)\Disk Write Bytes/sec can help to determine the IO profile which will be helpful in configuring the storage subsystem for the consolidated environment. This is often illustrated when setting the cache memory on a storage subsystem to a certain percentage for Read vs. Write. The combination of these counters also reveals the throughput needed by a consolidated environment.
\Process(sqlservr)\IO Data Operations/sec counts the number of IOPS related directly to a process (in this case – sqlservr). If the server is one that has other processes besides SQL Server running on it, this counter will help determine the actual IO load that is caused by SQL Server.
\SQLServer:Databases(*)\Transactions/sec can reveal which databases on the server have the most transactions. Each SQL Server instance has 4 system databases; of these, TempDB is the one that you will most likely find a high transaction count. Even in comparison with user databases, TempDB often has the highest transaction count. If this is the case, it should be noted for consideration of the storage subsystem for the consolidated environment. It may lead to a design of the storage subsystem to have separate drives/LUNs for TempDB data and TempDB logs.
\PhysicalDisk\Avg Sec/Transfer is a counter that has become very important since the advent of SANs. This counter measures the number of seconds per IO. This counter is more useful than a traditional counter often cited for indicating disk pressure, \PhysicalDisk\Avg Queue Length. The Queue Length counter is often hard to know if the value is good or bad without knowing the underlying number of spindles. The Avg Sec/Transfer counter indicates how long it takes for an operation to complete. Good performance is indicated with this counter less than .010 seconds. Bad performance is indicated by values larger than .030 seconds.
\Network Interface(*)\Bytes Total/sec represents the amount of bytes going through the NIC. This counter has no good or bad values either. Summing up the Max Average of the servers within the scope of the consolidation effort will yield some information needed for configuration of the NICs in the servers for the consolidated environment and also the speed requirements of the network.

13. Methods
Manually Add Counters
Logman
Powershell

14. Demo 2 Manually Adding Counters Logman
logman create counter SQLSatXXX -cf C:\PerfTemplates\Example\RickWin7.template -si 00:00:10 -f csv
logman start SQLSatXXX
logman stop SQLSatXXX
logman create counter SQLSat277 -cf C:\PerfTemplates\Example\RickWin7.template -si 00:00:10 -f csv -u domain\user
logman start SQLSat277
logman stop SQLSat277

15. Baselines Zero Activity Baseline Typical Workload Baseline
End of Month/Etc Baseline

16. Reviewing a Log Different Views in Perfmon PAL Line Bar Report
Codeplex FREE Tool
Graphs! Explanations!
Demo - Sample
C:\Users\Rick\Documents\ScalabilityExperts\Clients\MassHousing\PAL Reports\MHDATABASE02_031209__2__PAL_ANALYSIS_ _ htm

17. Relog Allows you transform format of a perflog into another format
Extract out a specific time slice from a Perflog
Filter out specific counters of a Perflog

18. Beyond Basic Perfmon Powershell Relog Circular Data Collection
Creating your own Management Data Warehouse

19. Call To Action
Add / Remove Counters from the Line Graph View of Current Activity
Create a log capture of a few counters. Capture Data for a few days
View your log data in Line Graph View in Perfmon

20. Thank You!
Rick Heiges, SQL Server MVP