Bei fast allen Produktionsservern ist es ratsam, den Abfrage-Cache zu deaktivieren. Alle Änderungen an einer Tabelle führen zum Löschen von allen QC-Einträge für diese Tabelle. Je größer der Tisch, desto länger dauert es. 128 Mio. ist gefährlich hoch.
Normalerweise ist es ratsam, innodb_buffer_pool_size festzulegen auf etwa 70 % der verfügbaren RAM. Sie haben es auf einen viel niedrigeren Wert eingestellt, sogar kleiner als die Datensatzgröße. 3G würde wahrscheinlich helfen. 20G würden nicht mehr helfen (bis Ihr Datensatz erheblich wächst).
Stellen Sie sicher, dass sowohl das Betriebssystem als auch MySQL 64-Bit-Versionen sind.
Geben Sie für eine gründlichere Analyse
an- RAM-Größe (32 GB)
SHOW VARIABLES;SHOW GLOBAL STATUS;(nach mindestens 24 Stunden Laufzeit)
Analyse von VARIABLEN und STATUS:
Die wichtigeren Themen
Da Sie nur (?) InnoDB und nur 2 GB Daten verwenden, ist es nicht wichtig, auf die Kommentare zu innodb_buffer_pool_size zu antworten und key_buffer_size
Geben Sie weitere Details zu Ihrer häufigen Verwendung von DELETE an .
Nutzen Sie das Slowlog, um die „schlechtesten“ Abfragen zu finden. Weitere Details hier . Das sollte die unten erwähnten tmp_table- und Tabellen-Scan-Probleme identifizieren.
Machen Sie sich nicht die Mühe, OPTIMIZE TABLE zu verwenden .
Wie machst du "Transaktionen"? Mal mit Autocommit, mal mit COMMIT ?
Details und andere Beobachtungen
( Key_blocks_used * 1024 / key_buffer_size ) = 4,710 * 1024 / 128M = 3.6% -- Prozentsatz des verwendeten key_buffer. Obergrenze.-- Senken Sie key_buffer_size, um unnötigen Speicherverbrauch zu vermeiden.
( innodb_buffer_pool_size / _ram ) = 4096M / 32768M = 12.5% -- % RAM verwendet für InnoDB buffer_pool
( (key_buffer_size / 0.20 + innodb_buffer_pool_size / 0.70) / _ram ) = (128M / 0.20 + 4096M / 0.70) / 32768M = 19.8% -- Der größte Teil des verfügbaren Arbeitsspeichers sollte für das Caching verfügbar gemacht werden. -- http://mysql. rjweb.org/doc.php/memory
( Innodb_buffer_pool_pages_free * 16384 / innodb_buffer_pool_size ) = 187,813 * 16384 / 4096M = 71.6% - Pufferpool frei - Pufferpoolgröße ist größer als der Arbeitssatz; verringern könnte
( Innodb_pages_written / Innodb_buffer_pool_write_requests ) = 7,144,121 / 29935426 = 23.9% -- Schreibanforderungen, die auf die Festplatte treffen mussten -- Überprüfen Sie innodb_buffer_pool_size
( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 1,199,046,656 / 4096M = 27.9% -- Prozentsatz des von Daten belegten Pufferpools -- Ein kleiner Prozentsatz kann zeigen an, dass der Pufferpool unnötig groß ist.
( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 533,153 / 60 * 512M / 20356473344 = 234 -- Minuten zwischen InnoDB-Protokollrotationen Beginnend mit 5.6.8 kann dies dynamisch geändert werden; Stellen Sie sicher, dass Sie auch my.cnf ändern.-- (Die Empfehlung von 60 Minuten zwischen Rotationen ist etwas willkürlich.) Passen Sie innodb_log_file_size an. (Kann in AWS nicht geändert werden.)
( Innodb_rows_deleted / Innodb_rows_inserted ) = 364,605 / 414950 = 0.879 -- Abwanderung-- "Stellen Sie es nicht in die Warteschlange, tun Sie es einfach." (Wenn MySQL als Warteschlange verwendet wird.)
( Created_tmp_disk_tables / (Created_tmp_disk_tables + Created_tmp_tables) ) = 247,373 / (247373 + 446152) = 35.7% -- Prozentsatz der temporären Tabellen, die auf die Festplatte übergelaufen sind -- möglicherweise tmp_table_size und max_heap_table_size erhöhen; Vermeiden Sie Kleckse usw.
( Select_scan ) = 871,872 / 533153 = 1.6 /sec -- Vollständige Tabellenscans -- Indizes hinzufügen / Abfragen optimieren (sofern es sich nicht um winzige Tabellen handelt)
( Select_scan / Com_select ) = 871,872 / 12593904 = 6.9% -- % der Auswahlen, die einen vollständigen Tabellenscan durchführen. (Kann durch gespeicherte Routinen getäuscht werden.) - Indizes hinzufügen / Abfragen optimieren
( Com_optimize ) = 216 / 533153 = 1.5 /HR -- Wie oft OPTIMIZE TABLE ausgeführt wird.-- OPTIMIZE TABLE ist selten nützlich, schon gar nicht bei hoher Häufigkeit.
( long_query_time ) = 10.000000 = 10 -- Cutoff (Sekunden) zum Definieren einer "langsamen" Abfrage.-- Vorschlag 2
Extreme (ohne Kommentar):
Ungewöhnlich klein:
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
Ungewöhnlich groß:
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?)
Abnormale Zeichenfolgen:
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 abfragen
Da es ausgeschaltet war, wurde keiner der Qcache-Statuswerte gesetzt. Daher kann ich die ursprüngliche Frage nicht beantworten. Wenn Sie die QC einschalten und den Server neu starten und ein paar Tage warten möchten, könnte ich mit eingeschalteter Funktion erneut analysieren. Verschiedene Metriken über Hits, Pflaumen usw. können Beantworten Sie die ursprüngliche Frage.
