Articles in this section

See more

Understanding Run Count, Success Count, and Failure Count in SingleStore Workload Monitoring

{question}

What do the Run Count, Success Count, and Failure Count in SingleStore Studio Workload Monitoring represent, and how should they be interpreted?

{question}

{answer}

Overview
SingleStores Workload Profiling uses metrics like run_count, success_count, and failure_count to measure query execution activity across nodes and partitions. These metrics help users analyze query behaviour and detect workload patterns or anomalies.

Definition of Metrics

  • Run Count: The number of execution threads started for a query across all partitions. It includes both successful and failed attempts.

  • Success Count: The number of threads that completed the query execution successfully.

  • Failure Count: The number of threads that failed during execution.

Each count reflects activity per partition and per node. Multiple threads may be created for a single query execution, particularly when the query interacts with multiple partitions.

How the Counts Are Calculated
When you start and stop a workload profile in Studio, two snapshots  INFORMATION_SCHEMA.MV_ACTIVITIES_EXTENDED_CUMULATIVE are captured. Studio calculates the delta between the two snapshots to derive the values for run, success, and failure counts.

Workload profiling internally uses the following logic:

SELECT
  RUN_COUNT, SUCCESS_COUNT, FAILURE_COUNT
FROM information_schema.mv_activities_extended_cumulative;

The final metric shown is:

Total Count = run_count + success_count + failure_count

The studio displays the maximum value across all partitions and nodes for a query, helping to highlight the worst-case performance impact.

Why Counts Differ Across Nodes or Partitions
Discrepancies in these counts can occur due to:

  • Uneven data distribution (data skew), causing certain partitions to be accessed more frequently.

  • A single query triggers multiple threads across partitions.

  • Retried executions contribute to higher failure or run counts.

  • Not all partitions are involved in every execution, depending on the query logic.

Example Behavior Observed

  • A SELECT * FROM tb_test query increased success_count only for partition 0.

  • An INSERT of 6 rows resulted in success_count = 1 and failure_count = 2 for each partition.

  • Re-running a simple query doubled the success count from 4 to 8, indicating thread-based tracking.

These examples highlight that the counts are thread-level metrics, not simple query submission counts.

Summary
These workload metrics provide insight into how queries behave at the execution level across the distributed system. Understanding them is essential for accurate workload profiling, troubleshooting, and performance optimization.

{answer}

Related articles