Il server database open-source aggiunge il thread pooling nelle versioni 26.7.0 e 9.7.2
Il thread pool del database è arrivato nell'edizione community gratuita del server database relazionale open-source nella release di luglio, versioni 26.7.0 e 9.7.2. L'ingegnere software di Percona Bogdan Degtyariov scrive in un post del 5 ottobre 2026 che prima di questa release, il plugin ufficiale del thread pool del server esisteva solo per i clienti paganti dell'edizione enterprise dello stesso server database. Le principali alternative gratuite con thread pooling erano il server database di Percona, che lo distribuiva come plugin, un fork community dello stesso motore con thread pooling integrato nel server, e un plugin GitHub di terze parti. Questa prima parte dell'analisi di Degtyariov copre cos'è il thread pooling e come lo implementa il server database di Percona; un confronto delle prestazioni tra il server database di Percona e il server database open-source appare nella Parte 2.
Il thread pooling è una tecnica che riutilizza un numero fisso di thread pre-creati per gestire più connessioni client ed eseguire istruzioni all'interno di un database. In una configurazione predefinita del server database relazionale open-source, chiamata one-thread-per-connection, il server crea un thread dedicato ogni volta che un client si connette, esegue le query di quel client e poi distrugge il thread. Quando il numero di connessioni cresce molto, questo metodo predefinito causa un calo significativo delle prestazioni perché creare, distruggere e passare continuamente tra migliaia di thread, un processo chiamato context switching, spreca risorse di sistema e crea contesa, ovvero molti processi competono per la stessa CPU e memoria. Vadim Tkachenko di Percona ha usato un'analogia con il controllo del traffico per spiegare il thread pooling in un post separato, e la documentazione di Percona lo approfondisce ulteriormente. Degtyariov aggiunge un chiaro avvertimento: un thread pool non è un potenziatore universale del database. È uno strumento avanzato che deve essere usato con piena comprensione del carico di lavoro; altrimenti i risultati possono essere lontani dall'essere perfetti.
Il thread pooling organizza il lavoro in gruppi di thread. Ogni gruppo è assegnato a uno specifico core della CPU, quindi il numero di gruppi spesso corrisponde al numero di core fisici o logici. Le connessioni client in ingresso sono distribuite uniformemente tra questi gruppi con un metodo round-robin, il che significa che ogni nuova connessione viene inviata al gruppo successivo a turno. All'interno di ogni gruppo, un thread listener monitora le query in arrivo e le inserisce in una coda ad alta priorità, come le query all'interno di una transazione attiva, o in una normale coda a bassa priorità. I thread worker poi prelevano le query dalle code, gestendo sempre prima gli elementi ad alta priorità, le eseguono e aspettano la richiesta successiva invece di spegnersi. Questo riutilizzo elimina il sovraccarico di creare e distruggere un thread per ogni connessione.
Il benchmark descritto da Degtyariov esamina diverse impostazioni del thread pool. La baseline usa thread_handling=one-thread-per-connection, mentre le esecuzioni con pool usano thread_handling=pool-of-threads. Il parametro thread_pool_size è testato a 10, 20, 40, 80, 120 e 160; l'autore nota che è stato testato anche un valore di 5 ma le prestazioni erano insoddisfacenti e non è incluso. Una seconda coppia di parametri, thread_pool_max_threads / thread_pool_max_active_query_threads, è fissata a 12000 come numero massimo di thread nel pool. Una terza coppia, thread_pool_oversubscribe / thread_pool_query_threads_per_group, esamina i valori 2, 3 e 4, che stabiliscono quanti thread possono essere attivi contemporaneamente all'interno di un singolo gruppo.
Il carico di lavoro del test è Sysbench OLTP Read-Write, un comune strumento a riga di comando che genera carico di elaborazione transazionale online. Il server gira su un Intel Xeon Gold 6230 con due processori da 20 core, hyper-threading che fornisce 80 CPU logiche, 187 GiB di memoria DDR4 e un SSD NVMe Intel da 2,9 TB (modello SSDPE2KE032T8). Il sistema operativo è Ubuntu 24.04 con kernel 6.8.0-60-generic. I motori di database confrontati sono il server database di Percona 9.7.1-1 e il server database open-source 26.7.0, entrambi build di release. Il database di test contiene 24 GB di dati, ovvero 100 milioni di righe, distribuite su 20 tabelle in tutte le esecuzioni. Lo schema è disponibile come file SQL scaricabile all'indirizzo https://percona-lab-results.github.io/2026-interactive-metrics/schema_dump.sql.
La concorrenza è un'altra dimensione: il benchmark guida 40, 80, 120, 160, 320, 640, 1280, 2560 e 5120 thread concorrenti. Vengono usati tre rapporti buffer-dati: 1:12 per un carico di lavoro I/O-bound, 1:2 per un carico di lavoro parzialmente bufferizzato e 1:1 per un carico di lavoro completamente bufferizzato, che corrispondono a dimensioni del buffer pool di InnoDB di 2 GB, 12 GB e 32 GB. Prima di ogni misurazione, viene usata una fase di ramp-up di 600 secondi, ovvero 10 minuti, e il post dice che i tempi di ramp-up sono stati determinati sperimentalmente finché aumentarli ulteriormente non produceva cambiamenti significativi. La finestra di misurazione effettiva è di 900 secondi, ovvero 15 minuti, in base all'esperienza di benchmark precedente per mantenere ragionevole il tempo totale di test. Ogni configurazione viene eseguita una volta perché l'intera suite richiede già molto tempo.
Diverse altre impostazioni del database sono elencate come importanti. Il buffer pool di InnoDB, l'area di memoria in cui il server database relazionale open-source memorizza nella cache le pagine di dati e indici, è impostato a 2 GB, 12 GB o 32 GB a seconda del rapporto. Il caricamento del buffer pool all'avvio e lo scaricamento all'arresto sono entrambi impostati su OFF. Lo stack dei thread è 512K, la dimensione della cache dei thread è 256 e il backlog delle connessioni è 4096. La capacità I/O di InnoDB è impostata a 10000, con un massimo di 20000, e i thread di lettura I/O sono impostati a 16. Il post nota che i file di configurazione completi per ogni esecuzione possono essere scaricati dai suoi grafici interattivi.
La Parte 1 non contiene deliberatamente risultati di prestazioni. Stabilisce i meccanismi e il banco di prova in modo che i lettori capiscano esattamente cosa verrà misurato. Il confronto delle prestazioni tra il server database di Percona con il suo thread pool e il server database open-source appena capace è l'argomento della Parte 2. Per i team che gestiscono database in produzione, infrastrutture cloud e dati gestite come AEU Data offrono database gestiti, backup automatici, archiviazione crittografata, monitoraggio e blocchi di costruzione ad alta disponibilità, così un esperimento con il thread pool non deve mettere a rischio i backup o il tempo di attività.