@Rocky in SHOW FULL PROCESSLIST; state - OK means the query is still running?

In StarRocks, when you run

SHOW FULL PROCESSLIST;

, a

State

of

OK

(with a

Command

of

Query

) generally indicates that the query is active and currently being processed by the Frontend (FE). Here are the key points to understand that status: 1. Still Running: If a query appears in the process list with the command

Query

, it has not finished. Once a query completes, it is typically removed from the list, or the connection's command changes to

Sleep

if the session remains open. 2. Execution vs. Queuing: To know if the query is actually executing on the backends or just waiting, check the

IsPending

column: * `IsPending = false`: The query is actively executing. * `IsPending = true`: The query is waiting in a resource group queue (Query Queue). 3. Limited Granularity: Unlike standard MySQL which might show states like "Sorting result" or "Sending data," StarRocks'

SHOW PROCESSLIST

often displays

OK

as a general indicator that the thread is active and healthy. More Detailed Alternatives If you need more specific information about query execution states, you should use these commands instead: *

SHOW RUNNING QUERIES;

(Available since v3.1.4): Provides a clearer

State

field showing either

RUNNING

or

PENDING

. *

SHOW PROC '/current_queries';

: Displays real-time resource consumption (CPU, Memory, Scan Rows) for queries currently running on the FE you are connected to. *

SHOW PROC '/global_current_queries';

(Available since v3.4): Shows running queries across the entire cluster. In summary: Yes, if you see

OK

and the command is

Query

, the query is still in progress. References • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.md • using_starrocks/running_queries.md • administration/management/resource_management/query_queues.md

@Rocky but in SHOW FULL PROCESSLIST; I see 10+ queries with Query and OK and in SHOW RUNNING QUERIES I see only 3

The discrepancy you are seeing between

SHOW FULL PROCESSLIST

and

SHOW RUNNING QUERIES

is common and usually stems from how StarRocks classifies "active" queries versus "queued" queries. Here are the primary reasons for the difference: 1.

SHOW RUNNING QUERIES

is Queue-Centric

SHOW RUNNING QUERIES

(introduced in v3.1.4) is specifically designed to monitor the Query Queue and Resource Groups. * It primarily shows queries that are managed by a resource group. * If query queues are not strictly configured or if certain types of queries (like very short-lived metadata queries or internal system tasks) bypass the resource group management, they may not appear here. * It explicitly distinguishes between

RUNNING

(executing on backends) and

PENDING

(waiting in the queue). 2.

SHOW PROCESSLIST

is Connection-Centric

SHOW FULL PROCESSLIST

shows the status of every active connection thread on the Frontend (FE). *

State = OK

&

Command = Query

: This means the FE thread is currently occupied with a query. * Why more results?

SHOW PROCESSLIST

often includes: * The command you just ran: You will always see at least one entry for the

SHOW FULL PROCESSLIST

query itself. * Metadata/Short queries: Very fast queries (like

SELECT 1

,

SHOW VARIABLES

, or internal heartbeats) appear in the process list because they occupy a connection thread, but they might finish so quickly or bypass the resource queue such that they don't appear in

SHOW RUNNING QUERIES

. * Ghost/Closing Queries: Sometimes a connection thread remains in the

Query

state for a fraction of a second while cleaning up or sending the final result packets to the client, even if the "execution" part on the backends is technically finished. 3. Local vs. Global Scope *

SHOW PROCESSLIST

: By default, this shows queries active on the specific FE node you are connected to. *

SHOW RUNNING QUERIES

: This is generally a cluster-wide view of the query queue. *

show proc '/current_queries'

: This is the most accurate way to see what is actually executing on your current FE. *

show proc '/global_current_queries'

(v3.4+): Use this to see every query running across the entire cluster (all FEs). Recommended Verification To get the most accurate "truth" of what is truly running and consuming resources right now, compare your findings with:

sql
-- See actual resource usage (CPU/Memory) for active queries on your FE
SHOW PROC '/current_queries';

If a query appears in

SHOW PROCESSLIST

with

OK

but has 0 ScanRows, 0 MemoryUsage, and 0 CPUTime in

SHOW PROC '/current_queries'

, it is likely a connection that is either just starting up, just finished, or is an idle internal task. Summary: If

SHOW RUNNING QUERIES

shows 3 and

PROCESSLIST

shows 10, trust the

RUNNING QUERIES

count for actual heavy execution. The extra 7 in

PROCESSLIST

are likely very brief metadata queries, your own monitoring commands, or threads in the middle of a state transition. References • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_RUNNING_QUERIES.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md • using_starrocks/running_queries.md

@Rocky but in show full processlist these queries are not light queries they have been running like 100 seconds +

This discrepancy usually occurs because

SHOW FULL PROCESSLIST

and

SHOW RUNNING QUERIES

track queries from two different perspectives: the Connection (FE) vs. the Execution Engine/Queue (MPP). If you see queries in the process list that have been in the

Query

/

OK

state for 100+ seconds, but they are missing from

SHOW RUNNING QUERIES

, it is typically due to one of the following reasons: 1. The Query Queue Scope

SHOW RUNNING QUERIES

is specifically designed to monitor queries that interact with the Query Queue and Resource Groups. * Manual Bypass: If a query does not hit a resource group or if the query queue is not enabled for that specific type of query (e.g.,

enable_query_queue_select

is false), it might not be registered in the queue system. * Non-Select Queries: In some versions,

SHOW RUNNING QUERIES

primarily tracks

SELECT

statements. If your 100s+ queries are

INSERT INTO...SELECT

,

STREAM LOAD

, or

ANALYZE

, they may appear in the process list but not in the running query queue view. 2. Connection "Zombies" or Client-Side Bottlenecks

SHOW FULL PROCESSLIST

tracks the state of the MySQL connection thread. * Result Sending: A query can show as

Query

/

OK

in the process list if the execution on the Backends (BEs) is finished, but the Frontend (FE) is still sending results to the client or waiting for the client to fetch them. If the client is slow to read data, the connection remains "busy" even though the execution engine is done with it. * Cleanup Phase: Sometimes a query completes, but the FE thread hangs briefly during metadata cleanup or session release. In this state, it is no longer in the "Running Queries" list but still occupies a connection slot. 3. Pre-Execution Wait (Locks) A query enters the

Query

state in

PROCESSLIST

as soon as the FE receives it. However, it only appears in

SHOW RUNNING QUERIES

once it passes the planning stage and enters the execution/queue phase. * If a query is waiting for a metadata lock (e.g., another process is performing an

ALTER

or

TRUNCATE

on the same table), it will sit in the process list for a long time but will not be considered "running" by the MPP engine yet. How to verify which are actually running To see what is truly consuming CPU and Memory right now, use the

PROC

commands: 1. Check Local FE:

SHOW PROC '/current_queries';

* This lists every query the current FE node thinks is active. If a query is here, it's actually running. 2. Check Global Cluster (v3.4+):

SHOW PROC '/global_current_queries';

* This is the most reliable "source of truth." If the 10+ queries from your process list aren't here, they are likely stalled connections or finished queries that haven't closed yet. 3. Check IsPending: In

SHOW FULL PROCESSLIST

, look at the

IsPending

column for those 10 queries. * If

IsPending = true

, they are queued and waiting for resources. Summary: Trust

SHOW PROC '/global_current_queries'

for actual resource usage. If queries are only in the

PROCESSLIST

, they are likely stuck "sending data" to a slow client or waiting on a metadata lock. References • using_starrocks/running_queries.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_RUNNING_QUERIES.md • administration/management/resource_management/query_queues.md References

@Rocky when I see the same query twice in the SHOW FULL PROCESSLIST and is started at the same time is that mean someone runs it simolteniuosly or there can be any other reason?

Seeing the same query twice in

SHOW FULL PROCESSLIST

with the exact same start time is almost always an indication of simultaneous executions from the client side, rather than a single internal query being listed twice. Here are the most common reasons why this happens: 1. Connection-Based View

SHOW FULL PROCESSLIST

is based on Connections (Threads), not just queries. * Different Connection IDs (

Id

column): Check the first column (

Id

). If the IDs are different, these are two separate physical connections from the client to the StarRocks Frontend (FE). * Reason: Many BI tools (like Tableau, Power BI) and JDBC drivers are designed to open multiple connections to "discover" metadata. They might send a schema check and the actual data query simultaneously, or send the same query twice if the first one doesn't return within a specific (often very short) timeout. 2. Retries by Load Balancers or Proxies If you have a load balancer (like ProxySQL, HAProxy, or a Kubernetes Service) between your client and StarRocks: * If the load balancer detects a slight delay or network hiccup, it may automatically retry the request on a different connection (or even a different FE node). * Because StarRocks is fast, these retries can happen within the same second, leading to two identical entries in the process list. 3. Application Design (Parallelism) Some applications are written to execute the same query in parallel to ensure high availability or to "race" for the fastest result (though this is rare). More commonly, a user might accidentally double-click a "Run" button in a SQL editor that doesn't disable the button during execution. How to distinguish "True" Duplicates To verify if these are actually the same execution or two separate ones, check these specific columns/commands: 1. Check `QueryId`: * In recent StarRocks versions,

SHOW FULL PROCESSLIST

includes a

QueryId

column. * If the

QueryId

is identical, it is likely an internal display artifact or a specific tracking of a multi-node query. * If the

QueryId

is different, they are two distinct executions consuming twice the resources. 2. Check

SHOW PROC '/current_queries';

: * This command is more accurate for the execution engine. If you see two entries here, StarRocks is definitely running the query twice, which means it received two distinct requests. 3. Check `Host`: * Look at the

Host

column (client IP and port). If the IP is the same but the port is different, it confirms the client opened two distinct sockets to send the same query. Summary: StarRocks does not internally duplicate a single user query in the process list. If you see two, your application, driver, or proxy has sent the request twice. You query twice. You should check the *Connection ID*; if they are different, it is definitely two separate requests. References • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.md • using_starrocks/running_queries.md • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_RUNNING_QUERIES.md • administration/management/load_balancing.md References • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROCESSLIST.md • administration/management/resource_management/query_queues.md • using_starrocks/running_queries.md