MV_ACTIVITIES

This view provides a high-level summary profile of all tasks which ran recently on any node in the cluster.

It holds a row per high-level activity H. Each row describes the set of tasks which have run over a recent interval of time and which are either instances of the high level activity H, or else instances of an activity L whose aggregator activity name is the name of H. It reports the sum of the profiling statistics of each task in the set, as collected over the recent interval. Activities can include tasks such as garbage collection and backups, in addition to queries.

The effect of grouping the instances of multiple activities together is mainly to group all tasks associated with a query, across all partitions, into a single row.

mv_activities determines recent resource use by computing the change in mv_activities_cumulative over an interval of time. This interval is controlled by the value of the activities_delta_sleep_s session variable.

mv_activities may only be queried while connected to an aggregator node.

SingleStore recommends using this view to begin a performance investigation, as it is the most concise.

However, SingleStore recommends against the use of mv_activities to compute the average latency or resource usage of a query. This is because its statistics include the latency and resource usage of currently running tasks, which will skew attempted average calculations. SingleStore recommends mv_finished_tasks for this purpose instead.

Column name

Description

activity_type

The type of the high-level activity.

activity_name

The name of the high-level activity. This column is often human-readable, but does not include the full query text for query tasks. Join with mv_queries for the query text.

database_name

The name of the database associated with the activity, or NULL if none could be assigned.

run_count

The number of instances which were running at the end of the interval.

success_count

The number of instances which completed successfully during the interval. For most query shapes, success_count is the number of times the query was executed, not the number of rows inserted (see mv_plancache for that information).

For multi inserts (INSERT ... VALUES ...) the plan is executed once for each tuple in the VALUES clause, so the number of times the plan was executed would be the same as the number of tuples.

failure_count

The number of instances which completed unsuccessfully during the interval.

SIMPLIFIED STATISTICS

This view contains all simplified statistics columns, including: cpu_time_ms, cpu_wait_time_ms, disk_b, disk_time_ms, elapsed_time_ms, lock_time_ms, memory_bs, network_b, and network_time_ms.

BLOB_CACHE_MISS_B

A query sometimes cannot find its input data in blob cache, referred to as a cache miss. The blob cache will download the missing data from the unlimited storage. This new field tells us the number of bytes downloaded from the unlimited storage.

BLOB_CACHE_WAIT_TIME_MS

The time (milliseconds) that were spent on waiting for blob cache data. This is a sum of waiting time from all query execution threads, not to be compared with end-to-end running time.

Last modified: October 18, 2024

Was this article helpful?