Per Burzin Patel: TIP: you can reduce the size of the command line by using the –config option and passing in a parameter file.
Description of the Windows XP Logman.exe, Relog.exe, and Typeperf.exe Toolshttp://support.microsoft.com/kb/303133
Logman.exeYou can use the Logman.exe tool to: • Remotely start and stop log file data collections from a central location by specifying the remote computer name. • Configure a data collection on one computer and then copy that configuration to multiple computers from a central location. • Query currently-running logs and traces. ExampleIf Sample_Log is the name of an existing performance log on the local computer, this command starts the log:
logman start Sample_Log
Relog.exeYou can use the Relog.exe tool to:• Convert a log from one type to another, such as a Microsoft Windows NT 4.0 log to a Windows XP log, or a binary log file (.blg) to a comma-separated values (.csv) file. • Resample a log file, and then create a new log file that is based on specified counters, a time period, or a sampling interval. ExampleTo convert a Windows 2000 log file that is named Win2k_log to a .csv log file that is named Win2k_log.csv, you would use:
relog Win2k_log.blg -f CSV -o Win2k_log.csv
Typeperf.exeYou can use the Typeperf.exe tool to: • Write performance data to the command window or to a supported log file format. • Display all of the counters that are currently available on a particular local or remote computer. ExampleTo output the Memory counter, Available Bytes, from a remote computer that is named "XPPRO", every 5 seconds, you would use:
Per Burzin Patel: TIP: you can reduce the size of the command line by using the –config option and passing in a parameter file.
• Remotely start and stop log file data collections from a central location by specifying the remote computer name. • Configure a data collection on one computer and then copy that configuration to multiple computers from a central location.
If Sample_Log is the name of an existing performance log on the local computer, this command starts the log:
• Convert a log from one type to another, such as a Microsoft Windows NT 4.0 log to a Windows XP log, or a binary log file (.blg) to a comma-separated values (.csv) file. • Resample a log file, and then create a new log file that is based on specified counters, a time period, or a sampling interval.
To convert a Windows 2000 log file that is named Win2k_log to a .csv log file that is named Win2k_log.csv, you would use:
• Display all of the counters that are currently available on a particular local or remote computer.
To output the Memory counter, Available Bytes, from a remote computer that is named "XPPRO", every 5 seconds, you would use:
Hardware 1° X Kernel Available MBytesHardware 2° X Kernel Cache BytesHardware 1° X Kernel Free System Page Table EntriesHardware 2° Kernel Page Faults/secHardware 1° X Kernel Pages/secHardware 2° X Kernel Pool NonPaged BytesHardware 2° X Kernel Pool Paged BytesHardware 2° X Kernel System Cache Resident Bytes
Hardware 2° X Network Interface Bytes total/secHardware 2° X Network Interface Current BandwithHardware 2° X Network Interface Output Queue LengthHardware 2° X PhysicalDisk/LogicalDisk % Idle TimeHardware 1° X PhysicalDisk/LogicalDisk Avg. Disk sec/ReadHardware 1° PhysicalDisk/LogicalDisk Avg. Disk sec/Transfer
Hardware 1° X PhysicalDisk/LogicalDisk Avg. Disk sec/WriteHardware 3° PhysicalDisk/LogicalDisk Disk Bytes/secHardware 3° PhysicalDisk/LogicalDisk Disk Read Bytes/secHardware 3° PhysicalDisk/LogicalDisk Disk Write Bytes/secHardware 2° X PhysicalDisk/LogicalDisk Disk Reads/secHardware 2° X PhysicalDisk/LogicalDisk Disk Transfers/secHardware 2° X PhysicalDisk/LogicalDisk Disk Writes/secHardware 3° PhysicalDisk/LogicalDisk Split IO/secHardware 2° Process % Processor TimeHardware 2° Process Page Faults/secHardware 1° X Process Handle CountHardware 1° X Process IO Data Operations/secHardware 1° X Process IO Other Operations/secHardware 1° X Process Private BytesHardware 1° X Process Thread CountHardware 1° X Process Working SetHardware 1° X Processor % Privileged TimeHardware 1° X Processor % Processor TimeHardware 1° X Processor % UserHardware 1° System Context Switches/secSQL Server 1° Access Methods Full Scans/secSQL Server 1° Access Methods Index Searches/sec
SQL Server 1° Buffer Manager Buffer Cache Hit RatioSQL Server 2° Buffer Manager Lazy writes/secSQL Server 1° Buffer Manager Page Life ExpectancySQL Server 1° Buffer Manager Procedure Cache PagesSQL Server 2° Plan Cache Cache Pages
SQL Server 2° Buffer Manager Total pagesSQL Server 2° Cache Manager Cache Hit RatioSQL Server 2° Databases Log Flushes/secSQL Server 2° Databases Transactions/secSQL Server 2° Latches Average Latch Wait Time (ms)SQL Server 1° Latches Latch Waits/secSQL Server 1° Latches Total Latch Wait Time (ms)SQL Server 1° Memory Manager Memory Grants Pending
SQL Server 1° Memory Manager Target Server MemorySQL Server 1° Memory Manager Total Server MemorySQL Server 1° SQL Statistics Batch Requests/secSQL Server 1° SQL Statistics SQL Compilations/secSQL Server 1° SQL Statistics SQL Recompilations/sec
<5,000 bad, <3,000 very bad; <7,000 threshold to removed /3GB (per Uttam Parui)< a few hundred is desirable, in the thousands acceptable if other memory counters are OK (see Process object)>2500/s bad for modern servers; much less for older servers; avg/sustained <25% of HDD or <10% RAM; MUCH less for SQL Server 32-bit: 100MB-260MB; 64-bit: 1GB-128GB (depends on total physical RAM; is it close to being consumed)32-bit: 120MB-480MB; 64-bit: 1GB-128GB (depends on total physical RAM; is it close to being consumed)
* <40% good; 40%-65% caution; 65%-100% critical Machine-Specific* <80%* 0 healthy; 1-2 caution; >2 critical* 50% good; 15%-50% warning; 0%-15% busy* Disk Latency <=5 ms Excellent* Disk Latency 5-10 ms Good
* Disk Latency 10-20 ms Reasonable* Disk Latency is a great metric because it is independent of spindle count* Note: Recent thinking (Greg Moss) is that Disk Queues for SQL Server must be zero** }~150 (for random) Source: readme.txt sqlio v1.5 11/17/99* }* }* Fewer the better_Total,<sqlservr>_Total,<sqlservr> < a few hundred is desirable, in the thousands acceptable if other memory counters are OK_Total,<sqlservr>_Total,<sqlservr>_Total,<sqlservr>_Total,<sqlservr>_Total,<sqlservr>_Total,<sqlservr>
SQL Server is a USER MODE app!5,000/s x # of CPUs; somewhat flexible if other CPU-related counters are good--including low SQL compiles/shttp://www.sql-server-performance.com/sql_server_performance_audit2.asp
98% OK, 99% better, 99.8% desirablebaseline<300s "official" threshold; >1,000 or >10,000s much betterMemory Mattershttp://www.sqlmag.com/Articles/Print.cfm?ArticleID=44556(2000) prefer stable values, otherwise cache thrash may be occurringMemory Mattershttp://www.sqlmag.com/Articles/Print.cfm?ArticleID=44556(2005) prefer stable values, otherwise cache thrash may be occurring
>0 is cause for concern Memory Mattershttp://www.sqlmag.com/Articles/Print.cfm?ArticleID=44556
high or rising value indicates insufficient memory Memory Matters~=Physical Ram Memory MattersOLTP workloads: server should support ~2,500/s/coreif compiles > 10% of Batch Requests, then app may not be caching effectivelyRecompiles > 10% of Compilations should be investigatedCACHING WhitePaper
Free list stalls/sec is the frequency with which requests for available database pages are suspended because no buffers are available. Free list stall rates of 3 or 4 per second indicate too little SQL memory available.Total number of pages on all free lists.This counter tracks how many times a second that the Lazy Writer process is moving dirty pages from the buffer to disk in order to free up buffer space. Generally speaking, this should not be a high value, say more than 20 per second or so. Ideally, it should be close to zero. If it is zero, this indicates that your SQL Server's buffer cache is plenty big and SQL Server doesn't have to free up dirty pages, instead waiting for this to occur during regular checkpoints. If this value is high, then a need for more memory is indicated.
(Page lookups/sec) / (Batch Requests/sec) < 100 Number of requests to find a page in the buffer pool. When the ratio of page lookups to batch requests is much greater than 100, this is an indication that while query plans are looking up data in the buffer pool, these plans are inefficient. Identify queries with the highest amount of logical I/O's and tune them. Number of physical database page reads issued. 80 – 90 per second is normal, anything that is above indicates indexing or memory constraint.Number of physical database page writes issued. 80 – 90 per second is normal, anything more we need to check the lazy writer/sec and checkpoint counters, if these counters are also relatively high then, it’s memory constraint.
< a few hundred is desirable, in the thousands acceptable if other memory counters are OK (see Process object)>2500/s bad for modern servers; much less for older servers; avg/sustained <25% of HDD or <10% RAM; MUCH less for SQL Server 32-bit: 100MB-260MB; 64-bit: 1GB-128GB (depends on total physical RAM; is it close to being consumed)32-bit: 120MB-480MB; 64-bit: 1GB-128GB (depends on total physical RAM; is it close to being consumed)
Spikes<50Ruling out Disk-Bound Problems<http://www.microsoft.com/technet/prodtechnol/exchange/Guides/TrblshtE2k3Perf/5bcdd349-dcc6-43eb-9dc3-54175f7061ad.mspx>
Disk Latency is a great metric because it is independent of spindle countNote: Recent thinking (Greg Moss) is that Disk Queues for SQL Server must be zero
Source: readme.txt sqlio v1.5 11/17/99
< a few hundred is desirable, in the thousands acceptable if other memory counters are OK
Free list stalls/sec is the frequency with which requests for available database pages are suspended because no buffers are available. Free list stall rates of 3 or 4 per second indicate too little SQL memory available.
This counter tracks how many times a second that the Lazy Writer process is moving dirty pages from the buffer to disk in order to free up buffer space. Generally speaking, this should not be a high value, say more than 20 per second or so. Ideally, it should be close to zero. If it is zero, this indicates that your SQL Server's buffer cache is plenty big and SQL Server doesn't have to free up dirty pages, instead waiting for this to occur during regular checkpoints. If this value is high, then a need for more memory is indicated.Number of requests to find a page in the buffer pool. When the ratio of page lookups to batch requests is much greater than 100, this is an indication that while query plans are looking up data in the buffer pool, these plans are inefficient. Identify queries with the highest amount of logical I/O's and tune them. Number of physical database page reads issued. 80 – 90 per second is normal, anything that is above indicates indexing or memory constraint.Number of physical database page writes issued. 80 – 90 per second is normal, anything more we need to check the lazy writer/sec and checkpoint counters, if these counters are also relatively high then, it’s memory constraint.
This counter tracks how many times a second that the Lazy Writer process is moving dirty pages from the buffer to disk in order to free up buffer space. Generally speaking, this should not be a high value, say more than 20 per second or so. Ideally, it should be close to zero. If it is zero, this indicates that your SQL Server's buffer cache is plenty big and SQL Server doesn't have to free up dirty pages, instead waiting for this to occur during regular checkpoints. If this value is high, then a need for more memory is indicated.Number of requests to find a page in the buffer pool. When the ratio of page lookups to batch requests is much greater than 100, this is an indication that while query plans are looking up data in the buffer pool, these plans are inefficient. Identify queries with the highest amount of logical I/O's and tune them.
Number of physical database page writes issued. 80 – 90 per second is normal, anything more we need to check the lazy writer/sec and checkpoint counters, if these counters are also relatively high then, it’s memory constraint.
This counter tracks how many times a second that the Lazy Writer process is moving dirty pages from the buffer to disk in order to free up buffer space. Generally speaking, this should not be a high value, say more than 20 per second or so. Ideally, it should be close to zero. If it is zero, this indicates that your SQL Server's buffer cache is plenty big and SQL Server doesn't have to free up dirty pages, instead waiting for this to occur during regular checkpoints. If this value is high, then a need for more memory is indicated.
This counter tracks how many times a second that the Lazy Writer process is moving dirty pages from the buffer to disk in order to free up buffer space. Generally speaking, this should not be a high value, say more than 20 per second or so. Ideally, it should be close to zero. If it is zero, this indicates that your SQL Server's buffer cache is plenty big and SQL Server doesn't have to free up dirty pages, instead waiting for this to occur during regular checkpoints. If this value is high, then a need for more memory is indicated.
Physical Disk % Idle Time 3°Physical Disk % Disk Time 3°Physical Disk Avg. Disk Bytes/Read 3° XPhysical Disk Avg. Disk 3°Physical Disk Avg. Disk Bytes/Write 3° XPhysical Disk Avg. Disk Queue Length 3° XPhysical Disk Avg. Disk sec/Read 1° X XPhysical Disk Avg. Disk sec/Transfer 1°Physical Disk Avg. Disk sec/Write 1° X XPhysical Disk Disk Bytes/sec 2°Physical Disk Disk Read Bytes/sec 2° XPhysical Disk Disk Write Bytess/sec 2° XPhysical Disk Disk Reads/sec 2° X XPhysical Disk Disk Transfers/sec 2°Physical Disk Disk Writes/sec 3° X X
Note: The I/O Predeployment article recommends either Physical Disk or Logical Disk, depending on "the specific storage configuration that is being tested".Note: I recommend capturing BOTH Physical Disk & Logical Disk to help discriminate challenges related, e.g., to shared disks.
ReferencesInside Microsoft SQL Server 2005: Query Tuning and Optimization , edited by Kalen Delaney, Chapter 1 authored by Sunil Agarwal, "A Performance Tuning Methodology", I/O Bottlenecks section, pp. 32-37, Microsoft Press, ISBN 0735621969
http://www.microsoft.com/MSPress/books/8565.aspx
Troubleshooting Performance Problems in SQL Server 2005http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx
Sunil Agarwal, Boris Baryshnikov, Tom Davidson, Keith Elmore, Denzil Ribeiro, Juergen ThomasPredeployment I/O Best Practices
SQL Server Best Practices ArticleWriter: Mike RuthruffContributors: Michael Thomassy, Prem MehraTechnical Reviewers: Robert Dorr, Stuart Ozer, Juergen Thomas, Lindsey Allen, Burzin Patel, Bill Emmert, Bruce Worthington, Sanjay Mishra
Note: The I/O Predeployment article recommends either Physical Disk or Logical Disk, depending on "the specific storage configuration that is being tested".Note: I recommend capturing BOTH Physical Disk & Logical Disk to help discriminate challenges related, e.g., to shared disks.
Inside Microsoft SQL Server 2005: Query Tuning and Optimization , edited by Kalen Delaney, Chapter 1 authored by Sunil Agarwal, "A Performance Tuning Methodology", I/O Bottlenecks section, pp. 32-37, Microsoft Press, ISBN 0735621969
Technical Reviewers: Robert Dorr, Stuart Ozer, Juergen Thomas, Lindsey Allen, Burzin Patel, Bill Emmert, Bruce Worthington, Sanjay Mishra
Inside Microsoft SQL Server 2005: Query Tuning and Optimization , edited by Kalen Delaney, Chapter 1 authored by Sunil Agarwal, "A Performance Tuning Methodology", I/O Bottlenecks section, pp. 32-37, Microsoft Press, ISBN 0735621969
Vital Signs is a 3-day Microsoft workshop authored & offered by PFE Shane [email protected]
There is no other workshop on the planet like it. I strongly encourage anyone interested in performance to take this class.Most of the counters & thresholds cited in this class reflect the values from this class.
Microsoft PFE Shane Cramer is the Yoda of PerfMon.He has created a workshop called Vital Signs.It is already available for public consumption, and he’s rumored to be updating it soon to a formal SKU.Whether you’re new to PerfMon or want to take your skills from Padawan to Jedi Master, the Vital Signs workshop is for you.
It is already available for public consumption, and he’s rumored to be updating it soon to a formal SKU.Whether you’re new to PerfMon or want to take your skills from Padawan to Jedi Master, the Vital Signs workshop is for you.
