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.

MV_ACTIVITIES

Was this article helpful?

Was this article helpful?