ProxySQL suscite actuellement beaucoup d'intérêt dans le monde des bases de données MySQL et MariaDB, sans parler de ClickHouse qui aide à défendre ProxySQL.
Il est prudent de dire que ProxySQL est devenu le proxy de base de données par défaut pour la famille de bases de données MySQL (comme Percona Server, Oracle MySQL, Galera Cluster ou même avec MariaDB).
ProxySQL est, en fait, un solutionneur de problèmes efficace avec des fonctionnalités extrêmement riches qui gèrent la communication client-serveur de la base de données ; agissant en tant que middleware dans une approche très avancée et performante.
Il a rendu possible la possibilité de façonner le trafic de la base de données en retardant, en mettant en cache ou en réécrivant les requêtes à la volée. Il peut également être utilisé pour créer un environnement dans lequel les basculements n'affecteront pas les applications et seront transparents pour elles. La communauté ProxySQL est très réactive et crée constamment des correctifs, des correctifs et des versions de version en temps opportun.
Mais quelle est la performance de votre configuration ProxySQL et comment pouvez-vous déterminer si votre configuration a été correctement réglée ? Ce blog se concentre sur la détermination des performances de vos nœuds ProxySQL et sur la manière de les surveiller efficacement.
Problèmes courants que vous pouvez rencontrer avec ProxySQL
L'installation par défaut de ProxySQL est fournie avec un outil de réglage léger et simple capable de gérer une charge moyenne à lourde. Bien que cela puisse dépendre du type de requêtes envoyées au middleware, cela peut avoir un impact et commencer à rencontrer des goulots d'étranglement et de la latence.
Problèmes de latence
Par exemple, ce qui peut entraîner des problèmes de latence peut être difficile à déterminer si vous n'avez pas de système de surveillance. De même, vous pouvez surveiller ou vérifier manuellement le schéma des statistiques comme ci-dessous :
mysql> select * from stats_mysql_connection_pool\G
*************************** 1. row ***************************
hostgroup: 20
srv_host: 192.168.10.225
srv_port: 3306
status: ONLINE
ConnUsed: 0
ConnFree: 0
ConnOK: 0
ConnERR: 0
MaxConnUsed: 0
Queries: 0
Queries_GTID_sync: 0
Bytes_data_sent: 0
Bytes_data_recv: 0
Latency_us: 1151
*************************** 2. row ***************************
hostgroup: 20
srv_host: 192.168.10.226
srv_port: 3306
status: ONLINE
ConnUsed: 0
ConnFree: 0
ConnOK: 0
ConnERR: 0
MaxConnUsed: 0
Queries: 0
Queries_GTID_sync: 0
Bytes_data_sent: 0
Bytes_data_recv: 0
Latency_us: 470
*************************** 3. row ***************************
hostgroup: 10
srv_host: 192.168.10.227
srv_port: 3306
status: ONLINE
ConnUsed: 0
ConnFree: 0
ConnOK: 0
ConnERR: 0
MaxConnUsed: 0
Queries: 0
Queries_GTID_sync: 0
Bytes_data_sent: 0
Bytes_data_recv: 0
Latency_us: 10855
*************************** 4. row ***************************
hostgroup: 40
srv_host: 192.168.10.225
srv_port: 3306
status: ONLINE
ConnUsed: 0
ConnFree: 0
ConnOK: 0
ConnERR: 0
MaxConnUsed: 0
Queries: 0
Queries_GTID_sync: 0
Bytes_data_sent: 0
Bytes_data_recv: 0
Latency_us: 1151
*************************** 5. row ***************************
hostgroup: 40
srv_host: 192.168.10.226
srv_port: 3306
status: ONLINE
ConnUsed: 0
ConnFree: 0
ConnOK: 0
ConnERR: 0
MaxConnUsed: 0
Queries: 0
Queries_GTID_sync: 0
Bytes_data_sent: 0
Bytes_data_recv: 0
Latency_us: 470
5 rows in set (0.01 sec)Cela vous permet de surveiller la latence en fonction du groupe d'hôtes. Mais cela ajoute des tracas à moins que vous n'ayez à innover et à développer un ou plusieurs scripts qui parviendront à vous avertir.
Erreurs de connexion client
Le délai maximal de connexion dû au nombre maximal de connexions dans le backend (nœud de base de données lui-même) peut vous rendre perplexe si vous n'êtes pas en mesure de déterminer quelle est la principale source du problème. Vous pouvez cependant vérifier la base de données des statistiques pour rechercher de telles connexions interrompues dans le client ou même le serveur et les connexions sont refusées comme suit,
mysql> select * from stats.stats_mysql_global where variable_name like '%connect%';
+-------------------------------------+----------------+
| Variable_Name | Variable_Value |
+-------------------------------------+----------------+
| Client_Connections_aborted | 0 |
| Client_Connections_connected | 205 |
| Client_Connections_created | 10067 |
| Server_Connections_aborted | 44 |
| Server_Connections_connected | 30 |
| Server_Connections_created | 14892 |
| Server_Connections_delayed | 0 |
| Client_Connections_non_idle | 205 |
| Access_Denied_Max_Connections | 0 |
| Access_Denied_Max_User_Connections | 0 |
| MySQL_Monitor_connect_check_OK | 41350 |
| MySQL_Monitor_connect_check_ERR | 92 |
| max_connect_timeouts | 0 |
| Client_Connections_hostgroup_locked | 0 |
| mysql_killed_backend_connections | 0 |
+-------------------------------------+----------------+
15 rows in set (0.01 sec)C'est également idéal si vous pouvez vérifier et vérifier le nombre maximum de connexions de l'utilisateur principal pour voir quel est le nombre de limites de connexion qu'il peut ouvrir ou utiliser. Par exemple, j'ai ce qui suit dans mon test,
mysql> select username, active, transaction_persistent, max_connections from mysql_users;
+---------------+--------+------------------------+-----------------+
| username | active | transaction_persistent | max_connections |
+---------------+--------+------------------------+-----------------+
| proxydemo | 1 | 1 | 10000 |
| proxysql-paul | 1 | 1 | 10000 |
+---------------+--------+------------------------+-----------------+
2 rows in set (0.00 sec)Requêtes lentes
Identifier les requêtes lentes ne peut pas être si difficile dans ProxySQL, mais cela peut être inefficace s'il est fait manuellement. Vous pouvez vérifier cela si vous faites du manuel avec la variable,
mysql> select * from stats_mysql_global where variable_name like '%slow%';
+---------------+----------------+
| Variable_Name | Variable_Value |
+---------------+----------------+
| Slow_queries | 2 |
+---------------+----------------+
1 row in set (0.00 sec)Bien que cela puisse vous fournir des chiffres, vous pouvez consulter la table stats_mysql_query_digest sous le schéma des statistiques si vous souhaitez approfondir. Par exemple ci-dessous,
mysql> select count_star,sum_time,(sum_time/count_star)/1000 as average_time_ms,digest_text
-> from stats_mysql_query_digest
-> where count_star > 100 order by average_time_ms desc limit 10;
+------------+----------+-----------------+--------------------------------------+
| count_star | sum_time | average_time_ms | digest_text |
+------------+----------+-----------------+--------------------------------------+
| 884 | 15083961 | 17 | UPDATE sbtest1 SET k=k+? WHERE id=? |
| 930 | 16000111 | 17 | UPDATE sbtest9 SET k=k+? WHERE id=? |
| 914 | 15695810 | 17 | UPDATE sbtest4 SET k=k+? WHERE id=? |
| 874 | 14467420 | 16 | UPDATE sbtest8 SET k=k+? WHERE id=? |
| 904 | 15294520 | 16 | UPDATE sbtest3 SET k=k+? WHERE id=? |
| 917 | 15228077 | 16 | UPDATE sbtest6 SET k=k+? WHERE id=? |
| 907 | 14613238 | 16 | UPDATE sbtest2 SET k=k+? WHERE id=? |
| 900 | 15113004 | 16 | UPDATE sbtest5 SET k=k+? WHERE id=? |
| 917 | 15299381 | 16 | UPDATE sbtest7 SET k=k+? WHERE id=? |
| 883 | 15010119 | 16 | UPDATE sbtest10 SET k=k+? WHERE id=? |
+------------+----------+-----------------+--------------------------------------+
10 rows in set (0.01 sec)
qui détecte les 10 requêtes les plus lentes sur la base d'un échantillonnage par 100.
Utilisation de la mémoire
Les éléments matériels tels que le CPU, le disque et la mémoire doivent être surveillés pour s'assurer que votre ProxySQL est performant. Cependant, la chose la plus cruciale est la mémoire, car ProxySQL utilisera fortement la mémoire en raison du mécanisme de cache des requêtes. Par défaut, le cache des requêtes, qui dépend de la variable mysql-query_cache_size_MB, est par défaut de 256 Mib. À cet égard, cela peut arriver à une situation où il utilise de la mémoire et vous devez déterminer et diagnostiquer si vous trouvez des problèmes dans votre nœud ProxySQL ou même si vous êtes remarqué dans la couche application.
Lorsque vous identifiez cela, vous pouvez finir par vérifier les tables dans les schémas stats_history et stats. Vous pouvez voir la liste des tableaux qui peuvent vous aider lors du diagnostic,
mysql> show tables from stats;
| stats_memory_metrics |
19 rows in set (0.00 sec)
or,
mysql> show tables from stats_history;
+------------------------+
| tables |
+------------------------+
| mysql_connections |
| mysql_connections_day |
| mysql_connections_hour |
| mysql_query_cache |
| mysql_query_cache_day |
| mysql_query_cache_hour |
| system_cpu |
| system_cpu_day |
| system_cpu_hour |
| system_memory |
| system_memory_day |
| system_memory_hour |
+------------------------+
15 rows in set (0.00 sec)Déterminer efficacement les performances de votre ProxySQL
Il existe plusieurs façons de déterminer les performances de votre nœud ProxySQL. L'utilisation de ClusterControl vous offre la possibilité de déterminer cela avec des graphiques simples mais directs. Par exemple, lorsque ProxySQL est intégré à votre cluster, vous pourrez définir vos règles de requête, modifier les max_connections de l'utilisateur, déterminer les principales requêtes, modifier un groupe d'hôtes utilisateur et vous fournir les performances de votre nœud ProxySQL. Voir les captures d'écran ci-dessous...
Tout ce que vous voyez est la preuve de la compétence avec laquelle ClusterControl peut vous donner un aperçu de les performances de votre nœud ProxySQL. Mais cela ne vous limite pas à cela. ClusterControl dispose également de tableaux de bord riches et puissants que nous appelons SCUMM, qui comprend le tableau de bord ProxySQL Overview.
Si vous avez l'intention de déterminer les requêtes lentes, vous pouvez simplement jeter un coup d'œil au tableau de bord. La vérification de la distribution de votre latence sur les différents groupes d'hôtes auxquels vos nœuds principaux sont affectés vous aide à avoir un aperçu rapide des performances en fonction de la distribution. Vous pouvez surveiller les connexions client et serveur, en vous fournissant des informations sur le cache des requêtes. Plus important encore et non des moindres, il vous donne l'utilisation de la mémoire utilisée par le nœud ProxySQL. Voir les graphiques ci-dessous...
Ces graphiques font partie du tableau de bord qui vous aide simplement à déterminer facilement le performances de votre nœud ProxySQL.
ClusterControl ne vous limite pas lorsque vous traitez avec ProxySQL. En outre, il existe une fonctionnalité riche ici où vous pouvez également effectuer une sauvegarde ou importer la configuration, ce qui est très important lorsque vous traitez avec une haute disponibilité pour vos nœuds ProxySQL.
Conclusion
Il n'a jamais été aussi facile de surveiller et de déterminer si vous rencontrez des problèmes avec votre ProxySQL. Comme dans l'exemple de ce blog, nous présentons ClusterControl comme un outil qui peut vous apporter de l'efficacité et vous donner des informations pour déterminer les problèmes en suspens que vous rencontrez avec vos problèmes liés aux performances.
