If you take a closer look at the performance monitoring areas depicted in Figure 1,
you can see that SQL Server spans them all. SQL Server must process
requests submitted to it via the network, service those requests with
one or more processors, and rely on accessing a request’s data from both
memory/cache and the disk system. If you maximize utilization on these
resources from the point of view of SQL Server and the operating system,
you end up with a well-tuned database server. However, an optimally
tuned system doesn’t guarantee good performance. It’s still important to
have a good database design and to implement optimal index strategies.
One area of interest is the amount of network traffic
handled by SQL Server and the size of these network requests. Another
area of interest is the capability of the available processors to
service the load presented to them by SQL Server without exceeding the
CPU capacity of the system. This section also looks at SQL Server memory
utilization of the available system memory and how effectively SQL
Server is utilizing the disk system.
In general, you want to start from the bottom, with
the network, and work your way up into the SQL Server–specific elements.
This allows you to quickly isolate certain issues that are paramount in
performance tuning. In each of these areas, this section provides a
list of minimum detail performance handles or counters that can be
examined. This approach can be summarized into the following steps:
1. | Understand
and monitor network request characteristics as they relate to SQL
Server and the machine on which SQL Server has been installed. This
means a complete profile of what is coming into and being sent back out over the network from SQL Server.
|
2. | Understand
processor utilization. Processing power might be the biggest issue
affecting performance. You need to get a handle on this aspect of
performance early.
|
3. | Understand
and monitor memory and cache utilization. This is the next step,
monitoring the overall memory usage from the operating system level
point of view and monitoring the memory that SQL Server is using for
data buffers, plan cache, and so on.
|
4. | Understand
and monitor disk system utilization. You are often rewarded for
implementing a simple (and less expensive) disk configuration or data
storage approach. However, a simple configuration may not provide the
best performance for your system. And you often don’t know you have a
problem unless you look for it. Techniques that are often used to
alleviate disk performance issues include disk striping, isolation of
logs from data, and so on.
|
You need to repeat steps 1 through 4 on a regular
basis. Your continued success (and, it is hoped, salary increases) will
reflect your diligence here. For each step, certain tools and facilities
are available for you to use that gather the information needed to
identify and monitor performance issues. Let’s look now at how to use
these tools to monitor and analyze the network, processor, memory, and
disk utilization and performance.
1. Monitoring the Network Interface
One area of possible congestion is the network card
or network interface; it does not matter how fast the server’s work is
if it has to queue up to go out through a small pipe. Remember that any
activity on the server machine might be consuming some of the bandwidth
of the network interface card. With the increasing implementations of
gigabit networks and the increases in network bandwidth over wide area
networks (WANs), network throughput is not as much of a bottleneck as it
used to be. That’s not to say network performance issues do not arise.
For example, a bad or misconfigured router can cause all sorts of
network performance issues, especially if your users and your SQL Server
are on different sides of the router. If you are not detecting query
performance issues in SQL Server but users are still complaining about
slow query performance, the network is a likely culprit.
You can monitor network activity via Performance Monitor. Table 1 shows the typical network performance object and counters you can use to monitor network interface activity.
Table 1. Network Interface Performance Objects and Counters
| Performance Monitor Object | Description |
|---|
| Network Interface: Bytes Received | The rate at which bytes are received on the interface. |
| Network Interface: Bytes Sent | The rate at which bytes are sent on the interface. |
| Network Interface: Bytes Total | The rate at which all bytes are sent and received on the interface. |
| Network Interface: Current Bandwidth | The bits per second (bps) of the interface card. |
| Network Interface: Output Queue Length | The length of the output packet queue (in packets). If this is longer than two, delays are occurring, and a bottleneck exists. |
| Network Interface: Packets Received | The rate at which packets are received on the network interface. |
| Network Interface: Packets Sent | The rate at which packets are sent on the network interface. |
| Network Interface: Packets | The rate at which packets are sent and received on the network interface. |
| Server: Bytes Received | The number of bytes the server has received from the network. This is the big-picture indicator of how busy the server is. |
| Server: Bytes Transmitted | The
number of bytes the server has sent/transmitted to the network. Again,
this is a good overall picture of how busy the server is. |
In general, if the SQL Server
packet sends or receives are grossly lower than the overall server’s
packet sends and receives, other activity on the server is occurring
that is potentially bogging down this server or not allowing SQL Server
to be used optimally. The rule of thumb here is to isolate all other
functionality to other servers if you can and let SQL Server be the main
application on a machine.
The sp_monitor system stored procedure, as
well as several SQL Server system variables, can be used to see how many
requests are queuing up, waiting to make use of the network interface.
The following SELECT statement retrieves a current picture of what is being handled by SQL Server from a network packet’s point of view:
SELECT @@connections as Connections,
@@pack_received as Packets_Received,
@@pack_sent as Packets_Sent,
getdate() as 'As of datetime'
go
Connections Packets_Received Packets_Sent As of datetime
----------- ---------------- ------------ -----------------------
39407 395569 487258 2010-05-16 22:34:19.650
The sp_monitor system
stored procedure provides packets sent and received as a running total
and since the last time it was run (difference in seconds). Here’s an
example of what would result (the network- and packets-related results):
EXEC sp_monitor
GO
last_run current_run seconds
----------------------- ----------------------- -----------
2010-04-02 17:34:58.817 2010-05-16 22:35:08.940 3819610
cpu_busy io_busy idle
------------ ---------- ------------------
318(318)-0% 62(62)-0% 182952(182928)-4%
packets_received packets_sent packet_errors
---------------- --------------- --------------
395781(395753) 487483(487455) 1(1)
total_read total_write total_errors connections
------------ ------------- ------------ -------------
8084(8084) 69921(69921) 0(0) 39432(39418)
The values within the parentheses are the amounts since the last time sp_monitor was run, and the seconds column shows how long that period was. You can actually see the rate at which traffic is coming into and out of SQL Server.
