ProxySQL Threads

Overview

ProxySQL operates as a multi-threaded daemon with specialised threads handling different functions. The main thread bootstraps core modules and initiates all other threads.

Thread Types

Admin Thread

Initializes the admin interface, loads configuration, manages the HTTP web UI, configures clustering, and handles admin connections.

MySQL Workers

Handle all MySQL traffic for client and backend connections. Multiple workers listen on the same port, with each client connection bound to a specific worker thread throughout its lifetime.

MySQL Auxiliary Threads

Also called "idle threads," these work alongside worker threads when started with --idle-threads. They manage idle connections while workers handle active ones, enabling ProxySQL to support hundreds of thousands of connections (up to 1 million tested).

HTTP Server

Built-in server using libmicrohttpd with internal polling thread capability (introduced in version 1.4.4).

Cluster Threads

One thread per ProxySQL cluster node, dynamically scaling as nodes are added or removed (introduced in version 1.4.2).

Query Cache Purge Thread

Acts as garbage collector for the query cache, operating outside the serving path to avoid client delays.

ClickHouse & SQLite3 Servers

Optional threads for handling connections to these databases when enabled via --clickhouse-server or --sqlite3-server.

Monitor Threads

Multiple threads managing connection checks, ping checks, read-only status, replication lag, and group replication monitoring with an auto-scaling thread pool.

CPU Considerations

MySQL worker threads consume the most CPU resources. Monitor module threads may expand significantly when managing hundreds or thousands of backend servers.