Performance Insight, provided by Database Autonomy Service (DAS), gives you instance-level visibility into load sources and performance bottlenecks for ApsaraDB RDS for SQL Server. With Performance Insight, you can:
-
Monitor key performance metrics and identify load trends over any time range
-
Pinpoint which SQL statements, users, hosts, or databases are driving the heaviest loads
-
Determine whether a performance issue stems from insufficient instance specifications or a database architecture problem
The feature uses average active sessions (AAS) as its core load metric. AAS measures the average number of sessions actively running in your RDS instance over a given period. When AAS rises, load is increasing; when it falls, load is easing.
Prerequisites
Your RDS instance must not run SQL Server 2008 R2 with cloud disks.
View Performance Insight data
-
Go to the Instances page. In the top navigation bar, select the region where your RDS instance resides. Find the instance and click its ID.
-
In the left-side navigation pane, choose Autonomy Services > Performance Optimization.
-
Click the Performance Insight tab and select a time range.
Performance Insight dashboard
The Performance Insight tab has three sections that work together: start with Performance Metrics to assess overall resource status, move to the Average Active Sessions (AAS) chart to locate load sources, then drill into the load source table to identify the exact SQL statements or users responsible.
Performance metrics
This section shows trend charts for key metrics over the selected time range, giving you a snapshot of resource utilization and load status. Select or customize the time range to zoom in on a specific period.
Average active sessions (AAS)
This section shows the AAS trend chart. After you identify a load spike from the performance metrics, use the AAS chart to trace where that load is coming from.
The AAS chart updates in real time and breaks load down by session activity. In the example above, the chart reveals three distinct load stages:
-
All load comes from User Sleep sessions.
-
User Sleep sessions decline as Sending Data sessions take over.
-
Sending Data sessions decline as Searching rows for update sessions become the dominant load source.
This progression shows how the AAS chart lets you trace load shifts across time without correlating multiple separate metrics.
Load sources from multiple dimensions
This section shows a table of load source details. Use it to identify which SQL statements, users, or infrastructure elements are responsible for the highest AAS values.
Slice load data by dimension
Select an AAS type from the AAS Type drop-down list in the upper-right corner of the Average Active Sessions (AAS) section to slice the load data by a specific dimension. Think of each dimension as a lens that answers a different diagnostic question about the same underlying load data:
| AAS type | What it shows | When to use it |
|---|---|---|
| SQL | AAS trends of the top 10 SQL statements | Identify which queries drive the most load |
| Waits | AAS trends of wait categories of the active sessions | Find where sessions are blocked or waiting for resources |
| Users | AAS trends of logged-on users | Determine which users generate the most activity |
| Hosts | AAS trends of client hostnames or IP addresses | Trace load back to specific client machines or applications |
| Commands | AAS trends of different SQL statement types | See whether SELECT, INSERT, UPDATE, or other command types dominate |
| Databases | AAS trends of databases where workloads run | Pinpoint which databases carry the heaviest load |
| Status | AAS trends of active session states | Understand how sessions spend their time (running, waiting, and so on) |
Start with Waits when sessions are stalling unexpectedly—wait events reveal where work is impeded. Use SQL when you suspect a specific query is causing a spike. Combine Users and Hosts to track down a noisy client or runaway application.