Management Statistics Reference
On this page
This topic describes the statistics columns present in the workload profiling management views.
As detailed in Management View Reference, each row of a given view profiles a particular set of tasks over a particular interval of time.
Extended Statistics
The statistics listed in the table below are present in the following management views found in the information_
database:
-
mv_
activities_ extended -
mv_
activities_ extended_ cumulative -
mv_
finished_ tasks -
mv_
tasks
Column name |
Description |
---|---|
|
Wall clock milliseconds elapsed during execution. |
|
Milliseconds spent running on all the CPUs across the cluster. |
|
Milliseconds spent waiting for a CPU to become available. |
|
Bytes read from the filesystem. |
|
Bytes written to the filesystem. |
|
Bytes actually read from physical disk. |
|
Bytes actually written to physical disk. |
|
Milliseconds spent waiting for physical disk I/O to complete. |
|
Milliseconds spent waiting on table row locks. |
|
Milliseconds spent waiting on locks and condition variables, excluding row locks. |
|
Milliseconds spent waiting for transaction log records to be flushed to disk. |
|
Milliseconds spent waiting for space in the transaction log buffer. |
|
Bytes written to the transaction log buffer. |
|
|
|
Number of page faults which required disk I/O to resolve. |
|
Bytes received from a socket. |
|
Bytes written to a socket. |
|
Milliseconds spent waiting for sockets to be ready to send or receive data. |
Simplified Statistics
The statistics listed in the table below are present in the following management views in the information_
database:
-
mv_
activities -
mv_
activities_ cumulative
Column name |
Description |
---|---|
|
Wall clock milliseconds elapsed during execution. |
|
Milliseconds spent running on all the CPUs across the cluster. |
|
Milliseconds spent waiting for a CPU to become available. |
|
Milliseconds spent waiting for physical disk I/O to complete. |
|
Number of bytes that SingleStore read and wrote to the filesystem or the in memory transaction log. |
|
Milliseconds spent waiting on locks and condition variables, excluding row locks. |
|
|
|
Number of bytes SingleStore sent and received to sockets. |
|
Milliseconds spent waiting for sockets to be ready to send or receive data. |
Note
For simple statistics, elapsed_
is aggregated over aggregators only, whereas all other statistics show total usage over both aggregators and leaves.elapsed_
to cpu_
.
Statistics Availability
Some workload profiling statistic will be unavailable at certain times, on certain platforms.
Advanced Statistics
The following advanced statistics require operating system support to collect:
-
cpu_
wait_ time_ ms -
disk_
time_ ms -
disk_
physical_ read_ b -
disk_
physical_ write_ b -
memory_
major_ faults
If SingleStore failed to collect an advanced statistic, the corresponding column in workload profiling views will contain NULL values and warnings will be returned by queries against the views.
In particular, cpu_
requires a Linux kernel compiled with CONFIG_
enabled.
Caution
Advanced statistics are not collected by default in SingleStore.select 1
.
You may enable collection by setting the global variable read_
to on
on all nodes in the cluster.
In order to generate these statistics, SingleStore reads: /proc/[tid]/stat/
, /proc/[pid]/io
, /proc/[pid]/schedstat
, and /proc/[pid]/sched
-- if any of those are missing, some columns in the information schema tables may be null, even with @@read_
set to on
.
Understanding memory_ bs
When reporting memory usage by activities, we report a metric that represents the memory requirements of that activity.
In this chart of memory usage over a time, the connection runs many small short lived queries.
![](https://images.contentstack.io/v3/assets/bltac01ee6daa3a1e14/blta11b29520c0053f0/66db60faa171f1948beea61e/16083b579d8442-RitYxZ.png?width=850&disable=upscale&auto=webp)
We want to report the memory used by these queries in an interval, for example during the grey interval:
![](https://images.contentstack.io/v3/assets/bltac01ee6daa3a1e14/blt1bb78abf3bb189cf/66db60e36aa93d4c7be3784b/16083b579df0a8-iYSvk8.png?width=850&disable=upscale&auto=webp)
The following figure shows a different connection, with a single long running query that consumes a moderate amount of memory.
![](https://images.contentstack.io/v3/assets/bltac01ee6daa3a1e14/blt31c1bf656e4addb2/66db6086101d913b7a59d6e9/16083b579e6b92-dCP3TU.png?width=850&disable=upscale&auto=webp)
Here is a last connection, with a single expensive but short lived query that uses a large amount of memory.
![](https://images.contentstack.io/v3/assets/bltac01ee6daa3a1e14/blt4b2411d4004e481b/66db60b47268c66b61ee2f89/16083b579eea0f-umsEsm.png?width=850&disable=upscale&auto=webp)
The last query is substantially less expensive than the previous query because it released its memory quickly.byte seconds
and is calculated by multiplying the maximum memory used by a query by the elapsed time (i.
Sample Query for memory_ bs
To find the average memory used by a query, execute a query similar to the following:
memsql> use information_schema;memsql> select 1000*memory_bs/elapsed_time_ms as avg_memory_used_b,activity_name from mv_activities;+-------------------+------------------------------------------------------------------+| avg_memory_used_b | activity_name |+-------------------+------------------------------------------------------------------+| 0.0000 | registrationRunner || 0.0000 | ReplicaHandler_StreamFiles || 0.0000 | ShardingPartition::WorkerThread || 26192.8233 | ReadAndExecuteLoop || 0.0000 | LogFlusherThreadFunc || 0.0000 | SecondaryReplayThread::Run || 0.0000 | LogFlusher || 1143400.0000 | Select_MV_ACTIVITIES_EXTENDED_CUMULATIVE__et_al_23409c29b9e1dd98 | |+-------------------+------------------------------------------------------------------+
Last modified: September 30, 2022