Pour offrir des performances optimales avec PolarDB for MySQL, PolarDB propose la fonctionnalité Thread Pool, qui dissocie les threads des sessions. De nombreuses sessions peuvent rester ouvertes simultanément, tandis qu'un nombre restreint de threads traite les tâches des sessions actives.
Avantages
Par défaut, MySQL utilise un mode exclusif par session, où chaque session crée un thread dédié. Lorsqu'un grand nombre de sessions sont actives, la forte concurrence pour les ressources dégrade les performances. Une sollicitation excessive de l'ordonnanceur de threads du système et des échecs de cache (cache misses) entraînent également une chute brutale des performances.
Le Thread Pool de PolarDB met en œuvre des mécanismes de priorité et de contrôle de la concurrence pour différents types d'opérations SQL. Il maintient le nombre de connexions à un niveau optimal, permettant aux bases de données PolarDB de conserver des performances élevées même avec un grand nombre de connexions et une forte concurrence. Le Thread Pool offre les avantages suivants :
Lorsque de nombreux threads s'exécutent simultanément, le Thread Pool maintient automatiquement le nombre de threads concurrents dans une plage raisonnable, évitant ainsi une surcharge de l'ordonnancement des threads et les échecs de cache.
En cas d'exécution simultanée de nombreuses transactions, le Thread Pool attribue des priorités distinctes aux instructions et aux transactions, et contrôle leur concurrence séparément, ce qui réduit la compétition pour les ressources.
Le Thread Pool accorde une priorité plus élevée aux instructions SQL de gestion, garantissant leur exécution en premier lieu. Les nouvelles connexions, les opérations de gestion et la surveillance restent donc stables, même lorsque la charge du système est élevée.
Les instructions SQL de requêtes complexes reçoivent une priorité relativement plus faible et leur concurrence maximale est limitée. Cela empêche une accumulation excessive de requêtes complexes d'épuiser les ressources système et de rendre le service de base de données indisponible.
Utiliser le Thread Pool
La fonctionnalité Thread Pool inclut les paramètres suivants, modifiables dans la console. Pour plus d'informations, consultez la rubrique Définir les paramètres de cluster et de nœud.
Les paramètres de cluster dans la console PolarDB comportent le préfixe de compatibilité du fichier de configuration MySQL : loose_. Pour modifier les paramètres dans la console PolarDB, modifiez les paramètres précédés du préfixe loose_.
Paramètre | Description |
loose_thread_pool_enabled | Indique si le Thread Pool est activé. Valeurs possibles :
Remarque
|
loose_thread_pool_size | Nombre de groupes de threads dans le Thread Pool. La plage de valeurs dépend du nombre de cœurs CPU des spécifications du nœud principal du cluster. Plage de valeurs : DBNodeClassCPU~DBNodeClassCPU10. Valeur par défaut : DBNodeClassCPU2. Remarque
Exemples :
|
loose_thread_pool_high_prio_mode | Mode de file d'attente haute priorité du Thread Pool. Valeurs possibles :
Remarque S'applique à :
|
loose_thread_pool_high_prio_tickets | Nombre de tickets accordés à la fois pour la file d'attente haute priorité. Plage de valeurs : 0~4294967295. Valeur par défaut : 4294967295. Remarque S'applique à :
|
loose_thread_pool_idle_timeout | Seuil de temps pour la libération des threads inactifs dans le Thread Pool. Un thread inactif qui n'a traité aucune requête au-delà de ce seuil est libéré. Plage de valeurs : 0~31536000. Valeur par défaut : 60. Unité : secondes. Remarque S'applique à :
|
loose_thread_pool_oversubscribe | Nombre de threads actifs autorisés dans chaque groupe de threads. Un thread actif est un thread en cours d'exécution d'une instruction SQL. Plage de valeurs : 1~1000. Valeur par défaut : 20. |
loose_thread_pool_stall_limit | Seuil de temps utilisé pour déterminer si le Thread Pool est entré dans un état bloqué (stalled). Lorsque le Thread Pool entre dans un état bloqué, le système crée de nouveaux threads pour traiter les instructions SQL. Plage de valeurs : 1~18446744073709551615. Valeur par défaut : 10. Unité : millisecondes. Remarque MySQL 5.6 a une valeur par défaut de 30 millisecondes. |
loose_bypass_thread_pool_ips | Configure les adresses IP clientes non soumises aux restrictions du Thread Pool. Même lorsque le Thread Pool est saturé, les instructions SQL peuvent être exécutées pour effectuer des opérations de gestion. Exemple de configuration : Remarque S'applique à : MySQL 8.0.1 8.0.1 avec la révision 8.0.1.1.19 ou ultérieure. |
loose_bypass_thread_pool_check_ignore_proxy | Indique s'il faut ignorer les adresses IP des clients connectés via Proxy lors de la détection des adresses IP clientes à l'aide de
Remarque S'applique à : MySQL 8.0.1 avec la révision 8.0.1.1.19 ou ultérieure. |
loose_thread_pool_high_priority_users | Configure les comptes de base de données prioritaires. Après configuration, les requêtes provenant de ces comptes sont placées dans la file d'attente haute priorité du Thread Pool et traitées en premier. Exemple de configuration : Remarque
|
loose_thread_pool_mark_ddl_thread_timeout_sec | Configure le seuil de délai d'expiration du Thread Pool pour les instructions DDL. Une fois ce seuil dépassé, l'instruction DDL est marquée comme expirée et le système crée de nouveaux threads pour traiter les requêtes. Plage de valeurs : 0~864000. Valeur par défaut : 600. Unité : secondes. Remarque S'applique à : MySQL 8.0.1 avec la révision 8.0.1.1.19 ou ultérieure. |
loose_thread_pool_mark_ddl_thread_timeout_immediately | Indique s'il faut marquer immédiatement les instructions DDL comme expirées lorsque le Thread Pool est fortement sollicité et que la file d'attente basse priorité est encombrée. Le système crée alors de nouveaux threads pour traiter les requêtes. Ce paramètre convient aux charges de travail nécessitant des opérations DDL par lots fréquentes. Valeurs possibles :
Remarque S'applique à : MySQL 8.0.1 avec la révision 8.0.1.1.19 ou ultérieure. |
Interroger l'état du Thread Pool
Exécutez la commande suivante pour interroger l'état du Thread Pool :
select * from information_schema.THREAD_POOL_STATUS;L'exemple de sortie suivant est renvoyé :
mysql> select * from information_schema.THREAD_POOL_STATUS;
+----+--------------+---------------------+----------------------+-------------------+---------------------------+------------------+-----------------+------------------+
| ID | THREAD_COUNT | ACTIVE_THREAD_COUNT | WAITING_THREAD_COUNT | DUMP_THREAD_COUNT | SLOW_THREAD_TIMEOUT_COUNT | CONNECTION_COUNT | LOW_QUEUE_COUNT | HIGH_QUEUE_COUNT |
+----+--------------+---------------------+----------------------+-------------------+---------------------------+------------------+-----------------+------------------+
| 0 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 1 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 2 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 3 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 4 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 5 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 6 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 7 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 8 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 9 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 10 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 11 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 12 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 13 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 14 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 15 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 16 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 17 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 18 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 19 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 20 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 21 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 22 | 2 | 1 | 0 | 0 | 0 | 1 | 0 | 0 |
| 23 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 24 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 25 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 26 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 27 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 28 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 29 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 30 | 2 | 0 | 0 | 0 | 0 | 1 | 0 | 0 |
| 31 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 32 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 33 | 2 | 0 | 0 | 0 | 0 | 1 | 0 | 0 |
| 34 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 35 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 36 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 37 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 38 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 39 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 40 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 41 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 42 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 43 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 44 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 45 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 46 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 47 | 3 | 1 | 0 | 0 | 0 | 1 | 0 | 0 |
| 48 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 49 | 3 | 1 | 0 | 0 | 0 | 1 | 0 | 0 |
| 50 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 51 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 52 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 53 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 54 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 55 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 56 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 57 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 58 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 59 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 60 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 61 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 62 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
| 63 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+----+--------------+---------------------+----------------------+-------------------+---------------------------+------------------+-----------------+------------------+
64 rows in set (0.00 sec)Le tableau suivant décrit les paramètres.
|
Paramètre |
Description |
|
ID |
ID du Thread Pool. |
|
THREAD_COUNT |
Nombre de threads dans le Thread Pool. |
|
ACTIVE_THREAD_COUNT |
Nombre de threads actifs dans le Thread Pool. |
|
WAITING_THREAD_COUNT |
Nombre de threads dans le Thread Pool en attente d'E/S disque ou de validation de transaction. |
|
DUMP_THREAD_COUNT |
Nombre de connexions persistantes de type DUMP dans le Thread Pool. |
|
SLOW_THREAD_TIMEOUT_COUNT |
Nombre de threads dans le Thread Pool marqués comme expirés. |
|
CONNECTION_COUNT |
Nombre de connexions utilisateur établies dans le Thread Pool. |
|
LOW_QUEUE_COUNT |
Nombre de requêtes en attente dans la file d'attente basse priorité du Thread Pool. |
|
HIGH_QUEUE_COUNT |
Nombre de requêtes en attente dans la file d'attente haute priorité du Thread Pool. |
Tests Sysbench
Les figures ci-dessous comparent les performances avec le Thread Pool activé et désactivé. Les résultats des tests montrent que le Thread Pool offre des avantages de performance nets sous forte concurrence.
Figure 1. Test de mise à jour OLTP sans index 
Figure 2. Test OLTP en écriture seule 
Figure 3. Test OLTP en lecture seule 
Figure 4. Test OLTP en lecture/écriture 
Dépanner un Thread Pool saturé
Si la base de données rencontre des délais d'expiration de connexion ou des requêtes mises en file d'attente, vérifiez si le Thread Pool est saturé.
Connectez-vous à la console PolarDB et accédez à la page de détails du cluster cible.
Choisissez .
Comparez
thread_pool_running_threads(le nombre actuel de threads en cours d'exécution) avectp_thread_count(la capacité totale en threads du Thread Pool). Sithread_pool_running_threadsreste proche detp_thread_count, le Thread Pool est saturé.Vérifiez les métriques
tp_low_queue_countettp_high_queue_count. Un encombrement dans l'une ou l'autre file d'attente indique que les requêtes sont mises en file d'attente et que le Thread Pool est saturé.