Quelle valeur de thread_cache_size dois-je utiliser?

J'utilise Asp.Net avec MySQL. Dans la chaîne de connexion .Net, j'ai défini la taille maximale du pool sur 150.

Si j'exécute ce qui suit, j'obtiens ces valeurs:

SHOW GLOBAL STATUS LIKE 'max_used_connections'; gives 66
SHOW GLOBAL STATUS LIKE 'Threads_created'; gives 66
SHOW GLOBAL STATUS LIKE 'connections'; gives 474

Ce qui donne Threads_created / Connections = 0,1392.

Donc, à partir de cela, il semble que je doive augmenter thread_cache_size.

Mais si je cours, SHOW PROCESSLISTje vois toujours que j'ai beaucoup de connexions ouvertes (la plupart d'entre elles dorment) à cause du pool créé par .Net. Dois-je encore définir le thread_cache_sizecar je vais toujours réutiliser les connexions du pool de connexions? Si la taille de la piscine est de 150, pensez-vous qu'une bonne valeur serait de mettre thread_cache_size150+? Cela affecterait-il beaucoup le processeur et la mémoire?

Sur la base des informations de la documentation MySQL, vous devez effectuer les opérations suivantes: savoir quel est le plus grand nombre de connexions simultanées que mysqld a eu en utilisant Connections , Threads_created et Max_used_connections ,

• SHOW GLOBAL STATUS LIKE 'Connections';
• SHOW GLOBAL STATUS LIKE 'Threads_created';
• SHOW GLOBAL STATUS LIKE 'Max_used_connections';

Essayez de calculer les éléments suivants

Threads_created / Connections: Si cela dépasse 0,01, augmentez thread_cache_size. À tout le moins, thread_cache_sizedevrait être supérieur à Max_used_connections.

Selon les documents MySQL, vous devez définir de thread_cache_sizesorte que la plupart des nouvelles connexions utilisent des threads du cache plutôt que des threads nouvellement créés. Cela permet d'économiser certains frais généraux de création de threads, bien que cela ne crée normalement pas d'amélioration significative des performances:

Les demandes de threads sont satisfaites en réutilisant les threads extraits du cache si possible, et ce n'est que lorsque le cache est vide qu'un nouveau thread est créé. Cette variable peut être augmentée pour améliorer les performances si vous avez beaucoup de nouvelles connexions. Normalement, cela n'apporte pas une amélioration notable des performances si vous avez une bonne implémentation de thread. Cependant, si votre serveur voit des centaines de connexions par seconde, vous devez normalement définir thread_cache_size suffisamment haut pour que la plupart des nouvelles connexions utilisent des threads mis en cache . (la source)

Cela signifierait que vous devez définir votre thread_cache_sizeafin que Threads_created / Connections(le% de connexions qui conduisent à la création de nouveaux threads) soit plutôt faible. Si vous prenez les documents MySQL littéralement ("la plupart"), la valeur doit être <50%. La réponse de RolandoMySQLDBA indique <1%. Je ne sais pas qui est le plus proche de la vérité.

Vous ne devez pas définir thread_cache_sizeplus haut que Max_used_connections. La dernière phrase de la réponse de RolandoMySQLDBA ("À tout le moins, thread_cache_size devrait être supérieure à Max_used_connections") ne semble pas sensée car elle dit que vous devez conserver plus de threads dans le cache que votre serveur n'en utilise jamais . MySQL ne mettra jamais autant de threads dans le cache de toute façon - il ne place pas de manière préventive les threads dans le cache - il ne les y place qu'après qu'un client a créé un thread et se déconnecte. Si vous n'avez jamais X clients connectés en même temps, vous n'aurez jamais X threads dans le cache:

Lorsqu'un client se déconnecte, les threads du client sont placés dans le cache s'il y a moins de threads thread_cache_size à cet endroit. (la source)

Voir aussi cette réponse de Michael:

Définir thread_cache_size à une valeur supérieure à max_connections semble être un conseil extrêmement inutile ... le cache ne peut pas devenir plus grand que max_connections et même un cache n'importe où proche de cette taille ne pourrait avoir de sens que si vous avez une énorme quantité de désabonnement sur vos threads ... ce qui, dans une application bien comportée, ne sera pas le cas.

/dba//a/28701

Dans la journée de travail commune, une «nouvelle embauche» aurait-elle besoin d'une connexion? La plupart des magiciens ne sauront pas combien de personnes pourraient être embauchées dans les prochains jours. La version 8 de MySQL suggère CAP thread_cache_size à 100 pour éviter la surcharge indépendamment de max_used_connections. Pour moi, 100 est une bonne PAC.

Voir ce lien, s'il vous plaît.

https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_thread_cache_size