J'ai une requête SELECT qui prend environ 2 minutes pour s'exécuter. Cela oblige notre application à se bloquer sur la nouvelle base de données cloud vers laquelle nous l'avons migrée. La nouvelle base de données cloud n'a que 3,5 Go de mémoire et 1 vCPU.

Sur notre ancienne base de données VM, cela ne prend que 0.6 secondes, soit environ 16 Go de mémoire.

Parfois, la requête SELECT entraîne généralement une utilisation du processeur à 100%. Et il semble que d'autres requêtes ne soient pas exécutées lorsque cette requête de longue durée est en cours d'exécution.

569 rows in set (1 min 52.23 sec)

Y a-t-il quelque chose que je peux configurer pour régler le my.cnf pour obtenir de meilleurs résultats et principalement pour empêcher l'application de se bloquer. Ce sont les seuls paramètres dont je dispose actuellement.

open_files_limit = 102400
max_connections = 5000
innodb_flush_log_at_trx_commit = 0
innodb_thread_concurrency = 8
log_bin_trust_function_creators=1
innodb_buffer_pool_size=2800M
innodb_log_file_size=600M
innodb_rollback_on_timeout=ON
innodb_log_buffer_size=16M

C'est une requête qui renvoie le nombre d'amis. Et certains d'entre eux pourraient avoir environ 600 amis et obtenir cette liste est ce qui cause le problème. Nous ne pouvons pas modifier la requête pour le moment car elle est codée en dur dans l'application. Mais en regardant la requête, il semble optimisé.

-1
John 21 févr. 2021 à 12:47

1 réponse

Meilleure réponse

Mise à jour: J'ai dû reconstruire les index et cela résout le problème. Une fois le vidage importé, j'ai exécuté la commande mysqlcheck database_name -p --optimize, puis le problème a été résolu.

La requête fonctionne désormais correctement, l'utilisation du processeur a diminué, la mémoire est consommée et la mise en cache des requêtes fonctionne également.

0
John 11 mars 2021 à 14:08