thread_cache_size réduire CPU et max de la connexion?

Récemment trouvé mon serveur MySQL hits 90% de l'utilisation élevée du PROCESSEUR lors de la simulation sur simultanées 100-500 threads demande

avec les paramètres par défaut plus suivant dans mon.cnf

max_connections = 500 
max_allowed_packet = 16M

Je remarque que le max_connection peut toucher jusqu'à 500, threads_created pouvez également revenir en haut à 200-500 et je pense que c'est effectivement causer anormalement élevée de l'UC

Donc au lieu d'utiliser les paramètres par défaut j'ai ajusté

innodb_buffer_pool_size = 2G #32 bits serveur linux 
innodb_log_file_size = 256M 
innodb_log_buffer_size = 8M 
innodb_thread_concurrency = 16 
innodb_flush_method = O_DIRECT 
innodb_additional_mem_pool_size = 20M 
table_cache = 1028 
thread_cache_size = 16 
key_buffer_size=32M 
query_cache_size=32M 
join_buffer_size=1M

Avec le même test de charge, le CPU plongé de 10% et au-dessous de...
Cependant je remarque que le max_connection n'est jamais arrivé sur 500 plus.
Il est de moins de 50 ans...

Est-ce causé par thread_cache_size j'ai ajusté? par défaut elle est de 0.
Ou est-il quelque chose de mal, quelque part ... je me demande dans ce cas si le serveur mysql est correctement testé avec le max de connexion. Je veux tester si threads simultanés peut frapper la max_connections mais de toute façon il n'a jamais frappé avec la même quantité que j'ai testé avant.
Depuis le changement, il n'est jamais arrivé au-dessus de 50 ans.

Une idée?

Je sais qu'il est trop tard pour demander, mais quelle était votre ancienne configuration tels que l'ancienne valeur de ci-dessus parametes?

OriginalL'auteur flyclassic | 2011-12-29

  1. 1

    Création de nouveaux threads (puisque je suppose que votre application ne pas utiliser le regroupement de connexion) prend une quantité décente de frais généraux. Avec MySQL ré-utilisant des fils de cette manière (jusqu'à 16), il n'est plus en utilisant le CPU supplémentaire de créer des threads comme souvent, et il est également susceptible de finition les opérations en temps opportun, par conséquent, la fermeture de la connexion plus rapide et donc la tenue de moins de connexions ouvertes en même temps.

    Juste une supposition 🙂

    OriginalL'auteur 1tiger1

  2. 0

    Votre utilisation de 

    innodb_thread_concurrency = 16

    est un acteur majeur dans la limitation de l'activité. Voir

    https://dev.mysql.com/doc/refman/5.6/en/innodb-parameters.html#sysvar_innodb_thread_concurrency

    pour des explications détaillées et des recommandations tests.

    La valeur par défaut 0 = illimité utilisé en simultané innodb_threads - mais le danger est de saturer vos systèmes de commutation de contexte pour de nombreux actifs innodb_threads exécutant en même temps.

    OriginalL'auteur Wilson Hauck