Database performance metrics
Summarize
Summary of Database performance metrics
The database performance metrics within the ServiceNow AI Platform® provide a detailed snapshot of database behavior and responsiveness. These metrics help ServiceNow customers monitor and understand various aspects of database performance, which is critical for maintaining efficient and reliable service operations.
Show less
Key Metrics and Their Practical Use
- SQL Response Time: Measures the average time taken for the database to respond to queries from the application layer, including network delays. While most queries are very fast, spikes or sustained increases beyond 15 minutes may indicate service issues, though this metric should be used as a secondary indicator alongside primary performance data.
- Database Response Time by Type: Breaks down response times by query type (selects, inserts, updates, deletes), allowing precise identification of which types of queries might be causing performance degradation.
- Database Throughput: Tracks the total number of each type of database transaction over time. This helps identify unusual changes in query volume that could impact performance.
- Database Size: Reports the total database size and shard sizes every four hours, enabling visualization of database growth trends and capacity planning.
- History List Length: Indicates the length of InnoDB's undo logs that support transactional consistency. High values (over 5-10 million for large DBs or over 1 million for smaller DBs) can be problematic and may affect performance.
- Threads Running: Shows the number of active process threads using CPU resources, useful for monitoring system load.
- Slow Queries: Highlights the maximum execution time of slow database queries, aiding identification of inefficient queries that may need optimization.
- InnoDBRowLock: Measures the time InnoDB waits for row locks before timing out, impacting database concurrency and transaction performance.
Why It Matters and What to Expect
By leveraging these metrics, ServiceNow customers can gain granular visibility into database operations and performance bottlenecks. This enables proactive troubleshooting, capacity planning, and optimization of database interactions, ultimately supporting smoother ServiceNow platform performance and enhanced user experience. Understanding these metrics helps differentiate between transient anomalies and sustained performance issues, guiding appropriate investigation and remediation efforts.
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.