Database performance metrics
Summarize
Summary of Database performance metrics
The database performance metrics in the ServiceNow AI Platform® provide a snapshot of database activity and responsiveness. These metrics help customers monitor and understand database behavior to ensure optimal application performance and identify potential issues.
Show less
Key Metrics
- SQL Response Time: Measures the average time from when a query is sent to the database until a response is received, including network and application layer delays. It is a secondary indicator and should not be used alone for troubleshooting. Sudden, sustained increases over 15 minutes may signal performance problems that require deeper investigation.
- Database Response Time by Type: Breaks down average response times by transaction types such as SELECT, INSERT, UPDATE, and DELETE, enabling granular identification of slow query categories.
- Database Throughput: Tracks the total count of database transactions per type over time, helping to spot unusual volume changes that may affect performance.
- Database Size: Measures the total database size and shard sizes every 4 hours to visualize growth trends and plan capacity.
- History List Length: Reflects the length of InnoDB undo logs, which maintain old row versions for transactional consistency. Excessively large values (over 1 million for small DBs, 5-10 million for large DBs) indicate potential issues.
- Threads Running: Shows the count of active CPU-consuming threads, indicating database workload intensity.
- Slow Queries: Captures the maximum execution time of slow database queries, which often result from missing indexes or inefficient design.
- InnoDB Row Lock: Measures the time InnoDB waits to acquire row locks before timing out, impacting concurrency and transaction performance.
Practical Use for ServiceNow Customers
These metrics enable customers to monitor database health, identify transaction types causing delays, and detect abnormal growth or locking issues. While SQL Response Time provides a general performance context, detailed breakdowns by transaction type and throughput allow targeted troubleshooting. Tracking history list length and thread activity helps anticipate and prevent database contention and capacity problems.
Customers should use these metrics in conjunction with primary performance indicators and ServiceNow’s diagnostic tools for effective performance management and to mitigate potential service impacts.
The metrics provide the database performance snapshot within the ServiceNow AI Platform®.
SQL Response Time
Reported mean of database response time. This is measured at the application layer with a timer that starts when a query is sent to the database and finishes when the response has been received.
Since this is measured at the application layer, it is therefore inclusive of time spent on the network between application server and database server as well as being susceptible to misleading increases during periods of application layer resource contention (for example, CPU or JVM memory shortages).
Most database queries in ServiceNow are extremely fast (a few milliseconds or less). When interpreting the mean SQL response time metric this is very important to understand because individual slow queries, that typically cause most ServiceNow performance issues, will likely not have an impact on this graph. Conversely, things that do have an impact on this graph are very not likely to signify actual business impacting issues — particularly things that cause it to jump for very short periods of time or things that cause it to grow slowly over time.
If the SQL response time quickly jumps up multiple times its normal rate and stays elevated for more than 15 minutes this might correlate to a service impacting issue, but must be validated with a primary performance indicator for further troubleshooting.
Database Response Time by Type
The average response time of individual database transaction types. The database transaction types are stacked individually to give a granular breakdown. Database transaction types such as selects, inserts, updates and deletes are tracked individually. In case of a response time issue, the breakdown of individual statement types allows the user to narrow down the impacting query type.
Database Throughput
The total number of database transaction types performed per data point. The database transaction types are stacked individually to give a granular breakdown. Database transaction types such as selects, inserts, updates and deletes are tracked individually. The breakdown of counts per type allows the user to identify any deviation in volume at the more granular level.
Database Size
otal DBI Size (based on sum of all tables) along with any primary shard(s) size (based on sum of all tables on shards), this is calculated every 4 hours and can be used to visualize database growth over time.
History List Length
The InnoDB history list is the undo logs which are used to store these modifications. This is a fundamental part of InnoDB's transactional architecture. InnoDB is an MVCC storage engine, which means you can start a transaction and continue to see a consistent snapshot even as the data changes. This is implemented by keeping old versions of rows as they're modified. They're kept in a linked list. The most recent version points to the previous one, which points to the previous one, and others.
Threads Running
This metric represents the number of process threads running at the given point in time on the instance. When a thread is in the "running" state, it is actively using CPU resources to execute its code.
Slow Queries
This metric represents the max time taken by slow queries. Slow queries refer to database queries that take longer to execute, typically due to lack of indexes, design, and others.
InnoDBrowLock
This metric represents the duration InnoDB waits to acquire a row lock before timing out, specified in seconds. Adjusting it affects concurrency and performance in database transactions.