[SQL Server] Analyse compteurs performance via LogMan

  • Imprimer
Commonly used Performance Objects
for SQL Server analysis    
Performance Object SQL2000 SQL2005 SQL2008 (RC0)
Memory * * *  
Network Interface * * *  
Paging File * * *  
LogicalDisk * * *  
PhysicalDisk * * *  
Process * * *  
Processor * * *  
System * * *  
SQL Server:Access Methods * * *  
SQL Server:Backup Device - * *  
SQL Server:Broker Activation - * *  
SQL Server:Broker Statistics - * *  
SQL Server:Broker TO Statistics - - *  
SQL Server:Broker /DBM Transport - * *  
SQL Server:Buffer Manager * * *  
SQL Server:Buffer Node - * *  
SQL Server:Buffer Partition - * *  
SQL Server:Cache Manager * ? *  
SQL Server:Catalog Metadata - * *  
SQL Server:CLR - * *  
SQL Server:Cursor Manager by Type - * *  
SQL Server:Cursor Manager Total - * *  
SQL Server:Database Mirroring - * *  
SQL Server:Databases * * *  
SQL Deprecated Features - - *  
SQL Server:Exec Statistics ? * *  
SQL Server:General Statistics * * *  
SQL Server:Latches * * *  
SQL Server:Locks * * *  
SQL Server:Memory Manager * * *  
SQL Server:Plan Cache - * *  
SQL Server:Replication Agents ? * *  
SQL Server:Replication Dist. ? * *  
SQL Server:Replication LogReader ? * *  
SQL Server:Replication Merge ? * *  
SQL Server:Replication Snapshot ? * *  
SQL Server:Resource Pool - - *  
SQL Server:SQL Errors * * *  
SQL Server:SQL Statistics * * *  
SQL Server:SSIS Service - * *  
SQL Server:Transactions * * *  
SQL Server:User Settable * * *  
SQL Server:Wait Statistics - * *  
SQL Server:Workload Group Stats - - *  
     
SQL Server 2000 Performance Objects    
SQLServer:Access Methods    
SQLServer:Buffer Manager    
SQLServer:Buffer Partition    
SQLServer:Cache Manager    
SQLServer:Databases    
SQLServer:General Statistics    
SQLServer:Latches    
SQLServer:Locks    
SQLServer:Memory Manager    
SQLServer:SQL Statistics    
SQLServer:User Settable    
SQL Server 2005 Performance Objects    
MSSQL$SQL1:Access Methods    
MSSQL$SQL1:Broker Activation    
MSSQL$SQL1:Broker Statistics    
MSSQL$SQL1:Broker/DBM Transport    
MSSQL$SQL1:Buffer Manager    
MSSQL$SQL1:Buffer Node    
MSSQL$SQL1:Buffer Partition    
MSSQL$SQL1:Catalog Metadata    
MSSQL$SQL1:CLR    
MSSQL$SQL1:Cursor Manager by Type    
MSSQL$SQL1:Cursor Manager Total    
MSSQL$SQL1:Database Mirroring    
MSSQL$SQL1:Databases    
MSSQL$SQL1:Exec Statistics    
MSSQL$SQL1:General Statistics    
MSSQL$SQL1:Latches    
MSSQL$SQL1:Locks    
MSSQL$SQL1:Memory Manager    
MSSQL$SQL1:Plan Cache    
MSSQL$SQL1:SQL Errors    
MSSQL$SQL1:SQL Statistics    
MSSQL$SQL1:Transactions    
MSSQL$SQL1:User Settable    
MSSQL$SQL1:Wait Statistics    
SQL Server 2008 Performance Objects (pending)    
 

 

LogMan :

'start a perfmon counter log from the command line                                                                                                                                                                      
logman start dbPerfLog  
   
'stop a perfmon counter log from the command line  
logman stop dbPerfLog  
   
'defining perfmon counter logs  
' options  
' -si 05 sample interval of 5s  
' -v nnnn append file version info  
' -max max size of log file  
' -o path  
' -c perf counters  
' for more info, execute logman -?  
   
'define a perfmon counter log for a SQL Server 2005 service named "SQLServer"  
call Logman create counter "dbPerfLog" -si 05 -v nnnnnn -max 100 -o "C:\perflogs\dbPerf" -c "\LogicalDisk(*)\*" "\PhysicalDisk(*)\*" "\Process(*)\*" "\Processor(*)\*" "\System\*" "\Network Interface(*)\*" "\Memory(*)\*" "\Paging File(*)\*" "\SQLServer:Access Methods(*)\*" "\SQLServer:Buffer Manager(*)\*" "\SQLServer:Buffer Node(*)\*" "\SQLServer:Buffer Partition(*)\*" "\SQLServer:Cursor Manager by Type(*)\*" "\SQLServer:Cursor Manager Total(*)\*" "\SQLServer:Databases(*)\*" "\SQLServer:Exec Statistics(*)\*" "\SQLServer:General Statistics(*)\*" "\SQLServer:Latches(*)\*" "\SQLServer:Locks(*)\*" "\SQLServer:Memory Manager(*)\*" "\SQLServer:Plan Cache(*)\*" "\SQLServer:SQL Errors(*)\*" "\SQLServer:SQL Statistics(*)\*" "\SQLServer:Wait Statistics(*)\*" [1]  
   
'define a perfmon counter log for a Katmai service named "MSSQL$KATMAI"  
call Logman create counter "dbPerfLogSQL10" -si 05 -v nnnnnn -max 100 -o "U:\perflogs\dbPerf" -c "\LogicalDisk(*)\*" "\PhysicalDisk(*)\*" "\Process(*)\*" "\Processor(*)\*" "\System\*" "\Network Interface(*)\*" "\Memory(*)\*" "\Paging File(*)\*" "\MSSQL$KATMAI:Access Methods(*)\*" "\MSSQL$KATMAI:Buffer Manager(*)\*" "\MSSQL$KATMAI:Buffer Node(*)\*" "\MSSQL$KATMAI:Buffer Partition(*)\*" "\MSSQL$KATMAI:Cursor Manager by Type(*)\*" "\MSSQL$KATMAI:Cursor Manager Total(*)\*" "\MSSQL$KATMAI:Databases(*)\*" "\MSSQL$KATMAI:Exec Statistics(*)\*" "\MSSQL$KATMAI:General Statistics(*)\*" "\MSSQL$KATMAI:Latches(*)\*" "\MSSQL$KATMAI:Locks(*)\*" "\MSSQL$KATMAI:Memory Manager(*)\*" "\MSSQL$KATMAI:Plan Cache(*)\*" "\MSSQL$KATMAI:SQL Errors(*)\*" "\MSSQL$KATMAI:SQL Statistics(*)\*" "\MSSQL$KATMAI:Wait Statistics(*)\*"
   
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 Tools  
http://support.microsoft.com/kb/303133  
 
Logman.exe  
You 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.  
Example  
If Sample_Log is the name of an existing performance log on the local computer, this command starts the log:  
logman start Sample_Log  
 
Relog.exe  
You 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.  
Example  
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:  
relog Win2k_log.blg -f CSV -o Win2k_log.csv  
 
Typeperf.exe  
You 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.  
Example  
To output the Memory counter, Available Bytes, from a remote computer that is named "XPPRO", every 5 seconds, you would use:  
typeperf "Memory\Available Bytes" -s XPPRO -si 00:05  
 
Logman cmd ref  
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/nt_command_logman.mspx  
 
Relog cmd ref  
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/nt_command_relog.mspx  
 
Typeperf cmd ref  
http://technet.microsoft.com/en-us/library/bb490960.aspx  

[1]
Execute this from the command line to create a PerfMon counter log containing the necessary performance objects, counters, & instances for most performance needs; it doesn't include counters for e.g., replication, service broker, etc.
 
My Counter List :
 
Counter
Source		 My
Status		 Vital
Signs		 Performance Object Counter Instance Threshold                                    
Hardware 1° X Kernel Available MBytes   <10MB fatal, <100MB cause for concern      
Hardware 2° X Kernel Cache Bytes          
Hardware     Kernel Commit Limit          
Hardware     Kernel Committed Bytes   > Physical Bytes is bad      
Hardware 1° X Kernel Free System Page Table Entries   <5,000 bad, <3,000 very bad; <7,000 threshold to removed /3GB (per Uttam Parui)      
Hardware 2°   Kernel Page Faults/sec   < a few hundred is desirable, in the thousands acceptable if other memory counters are OK (see Process object)      
Hardware 1° X Kernel Pages/sec   >2500/s bad for modern servers; much less for older servers; avg/sustained <25% of HDD or <10% RAM; MUCH less for SQL Server      
Hardware 2° X Kernel Pool NonPaged Bytes   32-bit: 100MB-260MB; 64-bit: 1GB-128GB (depends on total physical RAM; is it close to being consumed)      
Hardware 2° X Kernel Pool Paged Bytes   32-bit: 120MB-480MB; 64-bit: 1GB-128GB (depends on total physical RAM; is it close to being consumed)      
Hardware 2° X Kernel System Cache Resident Bytes          
Hardware 2° X Network Interface Bytes total/sec * <40% good; 40%-65% caution; 65%-100% critical Machine-Specific  
Hardware 2° X Network Interface Current Bandwith * <80%      
Hardware 2° X Network Interface Output Queue Length * 0 healthy; 1-2 caution; >2 critical      
Hardware     Paging File % Usage * >70%      
Hardware     Paging File % Usage Peak *        
Hardware     PhysicalDisk/LogicalDisk % Disk Time * >85% (consider spindle count)      
Hardware     PhysicalDisk/LogicalDisk % Free Space * 10-30%      
Hardware 2° X PhysicalDisk/LogicalDisk % Idle Time * 50% good; 15%-50% warning; 0%-15% busy      
Hardware     PhysicalDisk/LogicalDisk Avg. Disk Bytes/Read *        
Hardware     PhysicalDisk/LogicalDisk Avg. Disk Bytes/Transfer * Avg. I/O size; theoretical ~90-100MB/s sequential; reality significantly less      
Hardware     PhysicalDisk/LogicalDisk Avg. Disk Bytes/Write *        
Hardware     PhysicalDisk/LogicalDisk Avg. Disk Queue Length * 1.5 x # of spindles      
Hardware     PhysicalDisk/LogicalDisk Avg. Disk Read Queue Length * 1.5 x # of spindles Standards for Disk Latency for Data Files  
Hardware 1° X PhysicalDisk/LogicalDisk Avg. Disk sec/Read * Disk Latency <=5 ms Excellent Spikes<50 Ruling out Disk-Bound Problems  
Hardware 1°   PhysicalDisk/LogicalDisk Avg. Disk sec/Transfer * Disk Latency 5-10 ms Good   <http://www.microsoft.com/technet/prodtechnol/exchange/Guides/TrblshtE2k3Perf/5bcdd349-dcc6-43eb-9dc3-54175f7061ad.mspx>
Hardware 1° X PhysicalDisk/LogicalDisk Avg. Disk sec/Write * Disk Latency 10-20 ms Reasonable  
Hardware     PhysicalDisk/LogicalDisk Avg. Disk Queue/sec *   20-50 ms Busy  
Hardware     PhysicalDisk/LogicalDisk Avg. Disk Write Queue Length * 1.5 x # of spindles >50 ms Poor  
Hardware     PhysicalDisk/LogicalDisk Current Disk Queue Length * 1.5 x # of spindles Note: Latency for Log Files must be < 2ms  
Hardware 3°   PhysicalDisk/LogicalDisk Disk Bytes/sec *   Disk Latency is a great metric because it is independent of spindle count  
Hardware 3°   PhysicalDisk/LogicalDisk Disk Read Bytes/sec *   Note: Recent thinking (Greg Moss) is that Disk Queues for SQL Server must be zero  
Hardware 3°   PhysicalDisk/LogicalDisk Disk Write Bytes/sec *        
Hardware 2° X PhysicalDisk/LogicalDisk Disk Reads/sec * }~150 (for random) Source: readme.txt sqlio v1.5 11/17/99  
Hardware 2° X PhysicalDisk/LogicalDisk Disk Transfers/sec * }      
Hardware 2° X PhysicalDisk/LogicalDisk Disk Writes/sec * }      
Hardware 3°   PhysicalDisk/LogicalDisk Split IO/sec * Fewer the better      
Hardware 2°   Process % Processor Time _Total,<sqlservr>        
Hardware 2°   Process Page Faults/sec _Total,<sqlservr> < a few hundred is desirable, in the thousands acceptable if other memory counters are OK      
Hardware 1° X Process Handle Count _Total,<sqlservr>        
Hardware 1° X Process IO Data Operations/sec _Total,<sqlservr>        
Hardware 1° X Process IO Other Operations/sec _Total,<sqlservr>        
Hardware 1° X Process Private Bytes _Total,<sqlservr>        
Hardware 1° X Process Thread Count _Total,<sqlservr>        
Hardware     Process Virtual Bytes _Total,<sqlservr>        
Hardware 1° X Process Working Set _Total,<sqlservr>        
Hardware     Processor % Idle     User+Priv>80% CPU bottleneck  
Hardware 1° X Processor % Privileged Time          
Hardware 1° X Processor % Processor Time          
Hardware 1° X Processor % User   SQL Server is a USER MODE app!      
Hardware     Processor Interrupts/sec          
Hardware 1°   System Context Switches/sec   5,000/s x # of CPUs; somewhat flexible if other CPU-related counters are good--including low SQL compiles/s   http://www.sql-server-performance.com/sql_server_performance_audit2.asp  
Hardware     System Processor Queue Length   2 x # of CPUs; threads waiting to be executed; >2 means CPU bottleneck      
SQL Server 1°   Access Methods Full Scans/sec   (Index Searches/sec)/(Full Scans/sec) > 1000 http://www.grumpyolddba.co.uk/monitoring/Performance%20Counter%20Guidance%20-%20SQL%20Server.htm  
SQL Server 1°   Access Methods Index Searches/sec   (Index Searches/sec)/(Full Scans/sec) > 1000 http://www.grumpyolddba.co.uk/monitoring/Performance%20Counter%20Guidance%20-%20SQL%20Server.htm  
SQL Server     Access Methods Mixed Page Allocations/sec   baseline      
SQL Server     Access Methods Page Splits/sec   baseline or < 20 per 100 Batch Requests/Sec      
SQL Server     Access Methods Mixed Page Allocations/sec   baseline tempdb/snapshot  
SQL Server     Access Methods Workfiles Created/sec   baseline tempdb/snapshot  
SQL Server     Access Methods Worktables Created/sec   baseline tempdb/snapshot  
SQL Server     Access Methods Worktables from Cache Ratio   baseline tempdb/snapshot  
SQL Server     General Statistics Temp Tables Creation Rate   baseline tempdb/snapshot  
SQL Server     General Statistics Temp Tables for Destruction   baseline tempdb/snapshot  
SQL Server 1°   Buffer Manager Buffer Cache Hit Ratio   98% OK, 99% better, 99.8% desirable      
SQL Server     Buffer Manager Checkpoint pages/sec   baseline      
SQL Server     Buffer Manager Database Pages   < 300s [<1000s]      
SQL Server 2°   Buffer Manager Lazy writes/sec   baseline      
SQL Server 1°   Buffer Manager Page Life Expectancy   <300s "official" threshold; >1,000 or >10,000s much better Memory Matters http://www.sqlmag.com/Articles/Print.cfm?ArticleID=44556  
SQL Server 1°   Buffer Manager Procedure Cache Pages   (2000) prefer stable values, otherwise cache thrash may be occurring Memory Matters http://www.sqlmag.com/Articles/Print.cfm?ArticleID=44556  
SQL Server 2°   Plan Cache Cache Pages   (2005) prefer stable values, otherwise cache thrash may be occurring      
SQL Server 2°   Buffer Manager Total pages   baseline      
SQL Server 2°   Cache Manager Cache Hit Ratio   <99.9 excellent; <99 good; >98 not optimal      
SQL Server     Databases Data File(s) Size (kb)          
SQL Server 2°   Databases Log Flushes/sec   baseline      
SQL Server     Databases Percent Log Used          
SQL Server 2°   Databases Transactions/sec   baseline      
SQL Server     General Statistics Logins/sec & Logouts/sec   baseline; >2/sec suggests app's implementation of connection pooling may be flawed http://www.grumpyolddba.co.uk/monitoring/Performance%20Counter%20Guidance%20-%20SQL%20Server.htm  
SQL Server     General Statistics User Connections   ~      
SQL Server 2°   Latches Average Latch Wait Time (ms)   ~      
SQL Server 1°   Latches Latch Waits/sec   (Total Latch Wait Time) / (Latch Waits/Sec) < 10 http://www.grumpyolddba.co.uk/monitoring/Performance%20Counter%20Guidance%20-%20SQL%20Server.htm  
SQL Server 1°   Latches Total Latch Wait Time (ms)   (Total Latch Wait Time) / (Latch Waits/Sec) < 10 http://www.grumpyolddba.co.uk/monitoring/Performance%20Counter%20Guidance%20-%20SQL%20Server.htm  
SQL Server     Locks Avg. Wait Time (ms)   ~      
SQL Server     Locks Lock Timeouts/sec   >0      
SQL Server     Locks Lock Wait Time (ms)     http://www.grumpyolddba.co.uk/monitoring/Performance%20Counter%20Guidance%20-%20SQL%20Server.htm[1]  
SQL Server     Locks Lock Waits/sec   >0 http://www.grumpyolddba.co.uk/monitoring/Performance%20Counter%20Guidance%20-%20SQL%20Server.htm[2]  
SQL Server     Locks Number of Deadlocks/sec   >0      
SQL Server     Memory Manager Granted Workspace Memory (KB)   baseline if Total>=Target, then memory pressure possible  
SQL Server 1°   Memory Manager Memory Grants Pending   >0 is cause for concern Memory Matters http://www.sqlmag.com/Articles/Print.cfm?ArticleID=44556  
SQL Server     Memory Manager Memory Grants Outstanding     Memory Matters  
SQL Server 1°   Memory Manager Target Server Memory   high or rising value indicates insufficient memory Memory Matters  
SQL Server 1°   Memory Manager Total Server Memory   ~=Physical Ram Memory Matters  
SQL Server 1°   SQL Statistics Batch Requests/sec   OLTP workloads: server should support ~2,500/s/core      
SQL Server 1°   SQL Statistics SQL Compilations/sec   if compiles > 10% of Batch Requests, then app may not be caching effectively      
SQL Server 1°   SQL Statistics SQL Recompilations/sec   Recompiles > 10% of Compilations should be investigated CACHING WhitePaper    
         
     
Counters pending review:  
SQL Server:Buffer Manager     Free list stalls/sec < 2   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.  
SQL Server:Buffer Manager     Free pages > 640   Total number of pages on all free lists.  
SQL Server:Buffer Manager     Lazy Writes/Sec < 20   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.  
SQLServer:Buffer Manager     Page lookups/sec (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.  
SQL Server:Buffer Manager     Page reads/sec < 90   Number of physical database page reads issued. 80 – 90 per second is normal, anything that is above indicates indexing or memory constraint.  
SQL Server:Buffer Manager     Page writes/sec < 90   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.  
[1]
Per Grumpy Old DBA: For “Lock Wait Time” it is recommended to look beyond the Avg value. Look for any peaks that are close to (or exceed) 60 sec. Though this counter counts how many total milliseconds SQL Server is waiting on locks during the last second, the counter actually records the end of locking event. So most probably the peaks represent one huge locking event. If those events exceed more than 60 seconds then they may have extended blocking. In such cases, thoroughly analyze blocking script output. Some applications are written for timing out after 60 seconds and that’s not acceptable response for those applications.
[2]
Per Grumpy Old DBA: The "Lock Waits/sec" counter reports how many times users waited to acquire a lock over the past second. Note that while you are actually waiting on the lock that this is not reflected in this counter—it gets incremented only when you “wake up” after waiting on the lock. If this value is nonzero then it is an indication that there is at least some level of blocking occurring. If you combine this with the Lock Wait Time counter, you can get some idea of how long the blocking lasted. A zero value for this counter can definitively prove out blocking as a potential cause; a nonzero value will require looking at other information to determine whether it is significant. 
 
IO Notes & Refs :
 
                             
Performance Objects & Counters  
Performance Object
(see Notes below regarding Logical Disk)		 Performance Counter JWM Troubleshooting Performance Problems in SQL Server 2005 I/O Predeployment Best Practices Inside SQL 2005: Query Tuning & Optimization Vital Signs (Shane Creamer)  
Physical Disk % Idle Time 3°       X  
Physical Disk % Disk Time 3°            
Physical Disk Avg. Disk Bytes/Read 3°   X      
Physical Disk Avg. Disk Bytes/Transfer 3°          
Physical Disk Avg. Disk Bytes/Write 3°   X      
Physical Disk Avg. Disk Queue Length 3° X   X    
Physical Disk Avg. Disk sec/Read 1° X X X X  
Physical Disk Avg. Disk sec/Transfer 1°          
Physical Disk Avg. Disk sec/Write 1° X X X X  
Physical Disk Disk Bytes/sec 2°          
Physical Disk Disk Read Bytes/sec 2°   X      
Physical Disk Disk Write Bytess/sec 2°   X   X  
Physical Disk Disk Reads/sec 2° X X X X  
Physical Disk Disk Transfers/sec 2°       X  
Physical Disk Disk Writes/sec 3° X 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.  
 
   
References  
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
http://www.microsoft.com/MSPress/books/8565.aspx  
Troubleshooting Performance Problems in SQL Server 2005  
http://www.microsoft.com/technet/prodtechnol/sql/2005/tsprfprb.mspx  
Sunil Agarwal, Boris Baryshnikov, Tom Davidson, Keith Elmore, Denzil Ribeiro, Juergen Thomas  
Predeployment I/O Best Practices  
http://www.microsoft.com/technet/prodtechnol/sql/bestpractice/pdpliobp.mspx  
SQL Server Best Practices Article  
Writer: Mike Ruthruff  
Contributors: Michael Thomassy, Prem Mehra  
Technical Reviewers: Robert Dorr, Stuart Ozer, Juergen Thomas, Lindsey Allen, Burzin Patel, Bill Emmert, Bruce Worthington, Sanjay Mishra
 
Vital Signs :
 
                           
Vital Signs is a 3-day Microsoft workshop authored & offered by  
PFE Shane Creamer  
Cette adresse e-mail est protégée contre les robots spammeurs. Vous devez activer le JavaScript pour la visualiser.  
 
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.
 
Stay tuned for updates & URLs.