Dans presque tous les serveurs de production, il est sage de désactiver le cache de requête. Tous la modification d'une table provoque la purge de toutes Entrées QC pour cette table. Plus la table est grande, plus cela prend de temps. 128M est dangereusement élevé.
Normalement, il est sage de définir innodb_buffer_pool_size à environ 70 % des disponibles RAM. Vous l'avez défini sur une valeur bien inférieure, même inférieure à la taille de l'ensemble de données. 3G aiderait probablement. 20G n'aiderait plus (jusqu'à ce que votre jeu de données augmente de manière significative).
Assurez-vous que le système d'exploitation et MySQL sont des versions 64 bits.
Pour une analyse plus approfondie, fournissez
- Taille de la RAM (32 G)
SHOW VARIABLES;SHOW GLOBAL STATUS;(après avoir fonctionné au moins 24 heures)
Analyse de VARIABLES et STATUT :
Les problèmes les plus importants
Puisque vous n'utilisez (?) qu'InnoDB et seulement 2 Go de données, il n'est pas essentiel de répondre aux commentaires sur innodb_buffer_pool_size et key_buffer_size
Fournissez plus de détails sur votre utilisation intensive de DELETE .
Utilisez le slowlog pour trouver les « pires » requêtes. Plus de détails ici . Cela devrait identifier les problèmes de tmp_table et d'analyse de table mentionnés ci-dessous.
Ne vous embêtez pas à utiliser OPTIMIZE TABLE .
Comment faites-vous les "transactions" ? Parfois avec autocommit, parfois avec COMMIT ?
Détails et autres observations
( Key_blocks_used * 1024 / key_buffer_size ) = 4,710 * 1024 / 128M = 3.6% -- Pourcentage de key_buffer utilisé. High-water-mark.-- Réduisez key_buffer_size pour éviter une utilisation inutile de la mémoire.
( innodb_buffer_pool_size / _ram ) = 4096M / 32768M = 12.5% -- % de RAM utilisé pour InnoDB buffer_pool
( (key_buffer_size / 0.20 + innodb_buffer_pool_size / 0.70) / _ram ) = (128M / 0.20 + 4096M / 0.70) / 32768M = 19.8% -- La plupart de la RAM disponible devrait être mise à disposition pour la mise en cache.-- http://mysql. rjweb.org/doc.php/memory
( Innodb_buffer_pool_pages_free * 16384 / innodb_buffer_pool_size ) = 187,813 * 16384 / 4096M = 71.6% -- buffer pool free -- buffer_pool_size est plus grand que le jeu de travail ; pourrait le diminuer
( Innodb_pages_written / Innodb_buffer_pool_write_requests ) = 7,144,121 / 29935426 = 23.9% -- Demandes d'écriture qui devaient atteindre le disque - Vérifiez innodb_buffer_pool_size
( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 1,199,046,656 / 4096M = 27.9% -- Pourcentage du pool de mémoire tampon occupé par les données -- Un petit pourcentage peut indiquent que le buffer_pool est inutilement grand.
( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 533,153 / 60 * 512M / 20356473344 = 234 -- Minutes entre les rotations des journaux InnoDB À partir de la version 5.6.8, cela peut être modifié dynamiquement; assurez-vous également de modifier my.cnf.-- (La recommandation de 60 minutes entre les rotations est quelque peu arbitraire.) Ajustez innodb_log_file_size. (Impossible de modifier dans AWS.)
( Innodb_rows_deleted / Innodb_rows_inserted ) = 364,605 / 414950 = 0.879 -- Churn-- "Ne faites pas la queue, faites-le." (Si MySQL est utilisé comme file d'attente.)
( Created_tmp_disk_tables / (Created_tmp_disk_tables + Created_tmp_tables) ) = 247,373 / (247373 + 446152) = 35.7% -- Pourcentage de tables temporaires qui se sont déversées sur le disque -- peut-être augmenter tmp_table_size et max_heap_table_size ; éviter les blobs, etc.
( Select_scan ) = 871,872 / 533153 = 1.6 /sec -- Analyses complètes de table -- Ajouter des index / optimiser les requêtes (sauf s'il s'agit de petites tables)
( Select_scan / Com_select ) = 871,872 / 12593904 = 6.9% -- % de sélections effectuant une analyse complète de la table. (Peut être trompé par les routines stockées.)-- Ajouter des index / optimiser les requêtes
( Com_optimize ) = 216 / 533153 = 1.5 /HR -- Combien de fois OPTIMIZE TABLE est exécuté.-- OPTIMIZE TABLE est rarement utile, certainement pas à haute fréquence.
( long_query_time ) = 10.000000 = 10 -- Coupure (Secondes) pour définir une requête "lente".-- Suggestion 2
Extrêmes (sans commentaire) :
Anormalement petit :
Com_commit = 2.5 /HR
Innodb_buffer_pool_pages_made_not_young = 0.15 /sec
Innodb_ibuf_merged_delete_marks = 27 /HR
Innodb_row_lock_time = 8
Innodb_row_lock_time_max = 1
interactive_timeout = 360
Anormalement grand :
Com_rollback_to_savepoint = 14 /HR
Handler_savepoint_rollback = 14 /HR
join_cache_level = 8 (This may be unused? It was removed in 5.6.3, but possibly left in MariaDB 10.1?)
Chaînes anormales :
Innodb_buffer_pool_dump_status = Dumping buffer pool(s) not yet started
Innodb_buffer_pool_load_status = Loading buffer pool(s) not yet started
innodb_checksum_algorithm = INNODB
innodb_cleaner_lsn_age_factor = HIGH_CHECKPOINT
innodb_empty_free_list_algorithm = BACKOFF
innodb_force_load_corrupted = OFF
innodb_foreground_preflush = EXPONENTIAL_BACKOFF
innodb_log_checksum_algorithm = INNODB
myisam_stats_method = NULLS_UNEQUAL
opt_s__engine_condition_pushdown = off
opt_s__mrr = off
opt_s__mrr_cost_based = off
Cache des requêtes
Depuis qu'il a été désactivé, aucune des valeurs d'état de Qcache n'a été définie. Je ne peux donc pas répondre à la question initiale. Si vous souhaitez activer le QC et redémarrer le serveur et attendre quelques jours, je pourrais ré-analyser avec lui. Diverses mesures sur les hits, les pruneaux, etc. peuvent répondre à la question d'origine.
