MV_QUERY_ACTIVITIES

This view provides a high-level summary profile of all the queries that ran recently in the cluster.

Each row describes a query sent to the cluster, as well as queries sent between nodes.

Column name	Description
`activity_name`	An ID shared by all instances of the activity. This ID is often human-readable, but does not include the query text for query tasks. This will be the `activity_name` of all query tasks associated with the query. See `mv_queries`.
`query_text`	The de-parameterized text of the query.
`database_name`	The name of the database associated with the query, or `NULL` if none could be assigned.
`cpu_time_ms`	Milliseconds spent running on a CPU. If `elapsed_time_ms` of a leaf query task is equal to `cpu_time_ms`, you should PROFILE the query.
`cpu_wait_time_ms`	Milliseconds spent waiting for a CPU to become available. A non-zero value indicates that there were more concurrent tasks in the workload than there were CPUs on which to run them. If this value is a significant amount of elapsed time, the workload is likely issuing its queries faster than the hardware can handle. Investigate the tasks with the highest `cpu_time_ms` and optimize the relevant queries, reduce your workload, or provision more CPUs for your cluster.
`elapsed_time_ms`	Wall clock milliseconds elapsed during execution.
`lock_time_ms`	Milliseconds spent waiting on locks and condition variables, excluding row locks. This isn’t solely wait time due to contention on data structures because it also includes some time spent waiting for events in general.
`disk_time_ms`	Milliseconds spent waiting for physical disk I/O to complete. If this value is high, it may indicate excessive time to commit transactions to storage. You may need hardware which supports a faster write rate, or you may need to investigate whether other processes are issuing too much I/O and introducing unwanted variability. Check which other queries are using `disk_physical_read_b` or `disk_physical_write_b`.
`network_time_ms`	Milliseconds spent waiting for sockets to be ready to send or receive data. This may indicate that leaves are slow to respond to a query, or that a distributed join involves a large data transfer. If this counter has a noticeable delay, check what other queries are consuming `network_logical_recv_b` and `network_logical_send_b`.
`network_b`	Number of bytes SingleStore sent and received to sockets.
`disk_b`	Number of bytes that SingleStore read and wrote to the filesystem or the in memory transaction log.
`memory_bs`	Byte-seconds of memory used.
`memory_major_faults`	Number of page faults which required disk I/O to resolve.
`run_count`	The number of instances which were running at the end of the interval (where the workload profile was taken).
`success_count`	The number of instances which completed successfully during the interval (where the workload profile was taken).
`failure_count`	The number of instances which completed unsuccessfully during the interval (where the workload profile was taken).
`plan_warnings`	The number of warnings generated during query execution.
`plan_info`	A high-level information of the plan. `NULL` if no information was collected.

Last modified: June 1, 2023

Was this article helpful?

Verification instructions

Note: You must install cosign to verify the authenticity of the SingleStore file.

Use the following steps to verify the authenticity of singlestoredb-server, singlestoredb-toolbox, singlestoredb-studio, and singlestore-client SingleStore files that have been downloaded.

You may perform the following steps on any computer that can run cosign, such as the main deployment host of the cluster.

(Optional) Run the following command to view the associated signature files.
Shell
```
curl undefined
```
Download the signature file from the SingleStore release server.
- Option 1: Click the Download Signature button next to the SingleStore file.
- Option 2: Copy and paste the following URL into the address bar of your browser and save the signature file.
- Option 3: Run the following command to download the signature file.
  Shell
```
curl -O undefined
```

After the signature file has been downloaded, run the following command to verify the authenticity of the SingleStore file.

Shell

echo -n undefined |
    cosign verify-blob --certificate-oidc-issuer https://oidc.eks.us-east-1.amazonaws.com/id/CCDCDBA1379A5596AB5B2E46DCA385BC \
      --certificate-identity https://kubernetes.io/namespaces/freya-production/serviceaccounts/job-worker \
      --bundle undefined \
      --new-bundle-format -

Verified OK