Session History
On the Session History screen, you can query past collected session information in chronological order. You can go back in time to analyze which session executed which SQL at a specific time period and how much resources it used. This helps when retracing the cause after an incident has passed.
Data is provided based on active session snapshots (db_singlestore_active_session).
Basic Options
Set query conditions in the top filter area.
| Item | Description |
|---|---|
| Time | Select the query time range |
| Instance | Select the target node (oname) to query |
| Filter | Add conditions per field; AND logic is applied for multiple conditions |
| Download | Export in CSV format |
Session Trend Chart
Displays the number of active sessions during the query period as a bar chart. The X-axis is time and the Y-axis is the number of sessions.
- Drag the chart area with the mouse to narrow down to that interval for detailed analysis.
- Click a bar in the chart to move to the Instance Monitoring screen for that point in time (±5 minutes). You can check the node status at the time when sessions were numerous.
Long-Running Sessions
Along with the session trend, a Long-Running Sessions area is provided. It collects and displays sessions that ran for a long time during the query period, so you can quickly pick out inefficient queries or stalled transactions.
Session List Table
Displays the collected session information in chronological order. You can apply conditions using the fields and filters at the top, and adjust the number of rows shown at once using the page size setting at the bottom.
The columns share the same distributed execution metrics as the active session table in Instance Monitoring (instance, node_id, session_id, state, elapsed(ms), cpu(ms), memory, aggregator_activity, etc.), and add the following columns for historical queries.
| Column | Description |
|---|---|
time | The time when the session was collected |
sql_hash | A hash value that groups identical SQL |
With sql_hash, you can group repeated executions of the same query, which helps determine whether a specific SQL repeatedly consumes a lot of resources.
Stopping Sessions
You can select a session and stop (Kill) it. The stop target is identified by the session ID (session_id), and the node identifier (node_id) is normalized to a number for processing.
Stopping a session forcibly terminates the running query. Use it carefully after checking the scope of impact.
Data Interpretation Guide
| Checkpoint | Description |
|---|---|
| Sessions with long execution time | Long-running sessions; suspect lock contention, inefficient queries, or incomplete transactions |
| Many sessions in waiting state | Contention for a specific resource has occurred; lock cause analysis needed |
| Sessions concentrated on a specific node | Suspect data skew or routing bias |