Instance Monitoring
On the instance monitoring screen, you can check the key metrics of a single SingleStore node in real time. When CPU and memory usage suddenly rise or sessions pile up on a specific node, it helps you quickly grasp what is happening on which node. The intended readers are DBAs who operate SingleStore.
Basic screen guide
Select the node to view from the instance selector at the top of the screen. A node's role is reflected in its name. You can distinguish node roles by the MA (Master Aggregator), CA (Child Aggregator), and Leaf values in the ROLE column of the instance list. The time range is queried in a default 10-minute window based on LIVE, and metrics refresh every 5 seconds.
At the top of the screen are KPI tiles for a quick view of node state.
| Item | Description |
|---|---|
| Threads Running | Number of running threads |
| Connections | Number of connections |
| Queries | Query throughput |
| Successful Read Queries | Number of successful read queries |
| Failed Read Queries | Number of failed read queries |
| Failed Write Queries | Number of failed write queries |
Below the KPI tiles are resource usage chart widgets.
| Widget | Metric | View |
|---|---|---|
CPU | cpu_user_pct · cpu_system_pct · cpu_iowait_pct | MV_SYSINFO_CPU |
Memory | Host used / Physical or memsqld / Physical | MV_SYSINFO_MEM |
Disk Usage | Mount used / Capacity | MV_SYSINFO_DISK |
Network Bandwidth | IN (received) · OUT (sent) | MV_SYSINFO_NET |
In the Memory widget, you can switch the calculation basis with the Host and Node buttons in the header. The denominator is the same physical memory; only the numerator changes. Host is the usage of the whole machine (host_used_mb), and Node is this node's memsqld usage within it (memsql_used_mb). The widget title also changes to Host Memory or Node Memory according to your choice, so the title alone tells you what you are looking at.
The Idle item is no longer shown in the CPU widget, because the gauge already represents the usage rate.
Hover over a widget to see the description icon, which tells you which system view each value was read from. Metrics with the same name can have different values depending on the view, so this is the reference when reconciling on-screen values with MXQL or other tools.
At the bottom of the screen is an area that switches between active sessions and the lock tree by tabs, along with a Lock Wait sessions widget.
Active session area
In the active session table at the bottom of the screen, you can check the sessions currently running on the cluster. Because SingleStore splits a single query across multiple nodes, it groups active sessions by aggregator activity. This lets you grasp what work the cluster is currently performing at the level of each task.
The table columns are as follows.
| Column | Description |
|---|---|
instance | Node where the session is running |
node_id | Node identifier |
database | Target database |
session_id | Session identifier |
user | Session user |
state | Session state (for example, executing) |
command | Type of command being run (for example, Query) |
activity | Activity name |
raw_task | Raw text of the running SQL |
sql_param | SQL parameter |
aggregator_activity | Aggregator activity name used as the grouping key |
elapsed(ms) · avg elapsed(ms) | Execution time (max and average) |
cpu(ms) · cpu wait(ms) | CPU usage and wait time |
lock wait(ms) | Lock wait time |
network(ms) | Network time |
disk i/o(ms) | Disk I/O time |
disk spilling · avg spilling | Disk spilling amount (max and average) |
part rows | Number of partition rows processed |
conn | Number of connections |
memory · avg memory | Memory usage (max and average) |
node_id, aggregator_activity, part rows, and disk spilling are SingleStore-specific columns that are meaningful only in a distributed execution environment.
When you click the SQL of a specific session in the active sessions, a detail window opens. For the SQL detail window, see the SQL detail view description in the Top SQL document.
Stopping a session
In SingleStore, you can select an active session and stop (Kill) it. The stop target is identified by its session ID (session_id).
Stopping a session forcibly terminates the running query. Check the scope of impact before using it with care.