Performance Counter
Object
|
Counter
|
Preferred Value
|
Description
|
Memory
|
Available Mbytes
|
> 20MB
|
|
Memory
|
Free System Page Table Entries
|
> 7000
|
Free System Page Table Entries is the number of page table
entries not currently in use by the system. If < 7000, consider removing
/3GB.
|
Memory
|
Pages/Sec
|
< 50
|
Pages/sec is the rate at which pages are read from or written to
disk to resolve hard page faults. This counter is a primary indicator of the
kinds of faults that cause system-wide delays.
|
Memory
|
Pages Input/Sec
|
< 10
|
Pages Input/sec is the rate at which pages are read from disk to
resolve hard page faults.
|
Paging File
|
%Usage
|
< 70%
|
The amount of the Page File instance in use in percent.
|
Paging File
|
%Usage
|
< 70%
|
The peak usage of the Page File instance in percent.
|
SQL Server:
Buffer Manager
|
Page Life Expectancy
|
> 300
|
This performance monitor counter tells you, on average, how long
data pages are staying in the buffer. If this value gets below 300 seconds,
this is a potential indication that your SQL Server could use more memory in
order to boost performance.
|
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.
|
SQL Server:
Buffer Manager
|
Checkpoint Pages/Sec
|
This value is relative, it varies from server to server, we need
to compare the average to a base line capture to tell if the value is high or
low.
|
When a checkpoint occurs, all dirty pages are written to disk.
This is a normal procedure and will cause this counter to rise during the
checkpoint process. What you don't want to see is a high value for this
counter over time. This can indicate that the checkpoint process is running
more often than it should, which can use up valuable server resources. If
this has a high figure (and this will vary from server to server), consider
adding more RAM to reduce how often the checkpoint occurs, or consider
increasing the "recovery interval" SQL Server configuration
setting.
|
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.
|
SQL Server:
Buffer Manager
|
Free pages
|
> 640
|
Total number of pages on all free lists.
|
SQL Server:
Buffer Manager
|
Stolen pages
|
Varies. Compare with baseline
|
Number of pages used for miscellaneous server purposes
(including procedure cache).
|
SQL Server:
Buffer Manager
|
Buffer Cache hit ratio
|
> 90%
|
- Percentage of pages that were found in the buffer pool without
having to incur a read from disk.
|
SQL Server:
Buffer Manager
|
Target Server Memory(KB)
|
Total amount of dynamic memory the server can consume.
|
|
SQL Server:
Buffer Manager
|
Total Server Memory(KB)
|
Total amount of dynamic memory (in kilobytes) that the server is
using currently
|
|
PhysicalDisk
|
Avg. Disk Sec/Read
|
< 8ms
|
Measure of disk latgency. Avg. Disk sec/Read is the average
time, in seconds, of a read of data from the disk.
|
PhysicalDisk
|
Avg. Disk sec/Write
|
< 8ms (non cached) < 1ms (cached)
|
Measure of disk latency. Avg. Disk sec/Write is the average
time, in seconds, of a write of data to the disk.
|
PhysicalDisk
|
Avg. Disk Read Queue Length
|
< 2 * spindles
|
Avg. Disk Read Queue Length is the average number of read
requests that were queued for the selected disk during the sample interval.
|
PhysicalDisk
|
Avg. Disk Write Queue Length
|
< 2 * spindles
|
- Avg. Disk Write Queue Length is the average number of write
requests that were queued for the selected disk during the sample interval.
|
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.
|
SQL Server:
Buffer Manager
|
Free pages
|
> 640
|
Total number of pages on all free lists.
|
SQL Server:
Buffer Manager
|
Stolen pages
|
Varies. Compare with baseline
|
Number of pages used for miscellaneous server purposes
(including procedure cache).
|
SQL Server:
Buffer Manager
|
Buffer Cache hit ratio
|
> 90%
|
Percentage of pages that were found in the buffer pool without
having to incur a read from disk.
|
Processor
|
%Processor Time
|
< 80%
|
% Processor Time is the percentage of elapsed time that the
processor spends to execute a non-Idle thread.
|
Processor
|
%Privileged Time
|
< 30% of Total %Processor Time
|
% Privileged Time is the percentage of elapsed time that the
process threads spent executing code in privileged mode.
|
Process (sqlservr)
|
%Processor Time
|
< 80%
|
|
Process (sqlservr)
|
%Privileged Time
|
< 30% of %Processor Time (sqlservr)
|
Note: Divide the value by number of processors
|
System
|
Context Switches/sec
|
< 3000
|
1500 – 3000 per processor Excellent – Fair > 6000 per
processor Poor
Upper limit is about 40,000 at 90 % CPU per CPU NOTE: Remember to divide by number of processors |
System
|
Processor Queue Length
|
< 4 per CPU
|
For standard servers with long Quantums
<= 4 per CPU Excellent < 8 per CPU Good < 12 per CPU Fair |
SQLServer:
Access Methods
|
Full Scans / sec
|
< 1
|
If we see high CPU then we need to invistigate this counter,
otherwise if the full scan are on small tables we can ignore this counter.
Values greater than 1 or 2 indicates that we are having table / Index page
scans. We need to analyze how this can be avoided.
|
SQLServer:
Access Methods
|
Worktables Created/Sec
|
< 20
|
Number of worktables created in tempdb per second. Worktables
are used for queries that use various spools (table spool, index spool, etc).
|
SQLServer:
Access Methods
|
Workfiles Created/Sec
|
< 20
|
Number of work files created per second. Tempdb workfiles are
used in processing hash operations when the amount of data being processed is
too big to fit into the available memory. They may be able to reduce this
number by making the queries more efficient by adding/changing indexes,
adding additional memory, etc.
|
SQLServer:
Access Methods
|
Page Splits/sec
|
< 20
|
Interesting counter that can lead us to our table / index
design. This value needs to be low as possible. If you find out that the
number of page splits is high, consider increasing the fillfactor of your
indexes. An increased fillfactor helps to reduce page splits because there is
more room in data pages before it fills up and a page split has to occur.
|
SQLServer: General Statistics
|
User Connections
|
The number of users currently connected to the SQL Server.
|
|
SQLServer: General Statistics
|
Logins/sec
|
< 2
|
> 2 per second indicates that the application is not
correctly using connection pooling.
|
SQLServer: General Statistics
|
Logouts/sec
|
< 2
|
> 2 per second indicates that the application is not
correctly using connection pooling.
|
SQLServer:
SQL Statistics
|
Batch Requests/Sec
|
< 1000
|
Over 1000 batch requests per second indicate a very busy SQL
Server.
|
SQLServer:
SQL Statistics
|
SQL Compilations/sec
|
< 10% of the number of Batch Requests / sec
|
The number of times per second that SQL Server compilations have
occurred. This value needs to be as low as possible. If you see a high value
such as over 100, then it's an indication that there are lots or adhoc
queries that are running, might cause CPU.
|
SQLServer:
SQL Statistics
|
SQL Re-Compilations/sec
|
< 10% of the number of SQL Compilations/sec
|
This needs to be nil in our system as much as possible. A
recompile can cause deadlocks and compile locks that are not compatible with
any locking type.
|
SQL Server: Latches
|
Average Latch Wait Time (ms)
|
< 300
|
Average latch wait time (milliseconds) for latch requests that
had to wait.
|
SQL Server:
Locks
|
Number of Deadlocks/sec
|
< 1
|
The number of lock requests that resulted in a deadlock.
|
SQL Server:
Locks
|
Lock Requests/sec
|
< 1000
|
Number of requests for a type of lock per second. Lock
requests/sec > 1000 indicates that the queries are accessing large number
of rows, the next step is to review high read queries. If you also see high
Avg. Wait time, then it's an indication of blocking, then review the blocking
script output.
|
SQL Server:
Locks
|
Average Wait Time (ms)
|
< 500
|
This is the average wait time in milliseconds to acquire a lock.
Lower the value the better it is. If the value goes higher then 500, there
may be blocking going on; we need to run blocker script to identify blocking.
|
No comments:
Post a Comment