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

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

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

Who am I? Independent Experts, Real World Answers Board of Directors 2003 - 2011

Thank You Sponsors!!!

About the Presenter Rick HeigesSQL Server MVP MCP, MCSE, MCDBA, MCTS: SQL2005, MCITP: DBA MBA, MS-MIS, BSCS PASS – Director 2003 - 2011 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

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

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

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

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

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. 300 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.

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.

Methods Manually Add Counters Logman Powershell

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

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

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_2013-03-13_16-03-43.htm

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

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

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

Thank You! Rick Heiges, SQL Server MVP