In quasi tutti i server di produzione, è consigliabile disattivare la cache delle query. Ogni la modifica a una tabella provoca l'eliminazione di tutti Voci QC per quella tabella. Più grande è il tavolo, più tempo ci vorrà. 128M è pericolosamente alto.
Normalmente, è consigliabile impostare innodb_buffer_pool_size a circa il 70% di disponibili RAM. Lo hai impostato su un valore molto più basso, anche inferiore alla dimensione del set di dati. Probabilmente il 3G aiuterebbe. 20G non aiuterebbe più (fino a quando il tuo set di dati non crescerà in modo significativo).
Assicurati che sia il sistema operativo che MySQL siano versioni a 64 bit.
Per un'analisi più approfondita, fornisci
- Dimensione RAM (32G)
SHOW VARIABLES;SHOW GLOBAL STATUS;(dopo aver eseguito almeno 24 ore)
Analisi di VARIABILI e STATO:
Le questioni più importanti
Dato che stai usando solo (?) InnoDB e solo 2 GB di dati, non è fondamentale rispondere ai commenti soffiati su innodb_buffer_pool_size e key_buffer_size
Fornisci qualche dettaglio in più sul tuo uso massiccio di DELETE .
Usa lo slowlog per trovare le query "peggiori". Maggiori dettagli qui . Ciò dovrebbe identificare i problemi di scansione di tmp_table e tabella menzionati di seguito.
Non preoccuparti di usare OPTIMIZE TABLE .
Come stai facendo le "transazioni"? A volte con autocommit, a volte con COMMIT ?
Dettagli e altre osservazioni
( Key_blocks_used * 1024 / key_buffer_size ) = 4,710 * 1024 / 128M = 3.6% -- Percentuale di key_buffer utilizzata. High-water-mark.-- Abbassa key_buffer_size per evitare un utilizzo non necessario della memoria.
( innodb_buffer_pool_size / _ram ) = 4096M / 32768M = 12.5% -- % di RAM utilizzata per 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 maggior parte della ram disponibile dovrebbe essere resa disponibile per la memorizzazione nella cache.-- http://mysql. rjweb.org/doc.php/memoria
( Innodb_buffer_pool_pages_free * 16384 / innodb_buffer_pool_size ) = 187,813 * 16384 / 4096M = 71.6% -- buffer pool free-- buffer_pool_size è più grande del working set; potrebbe diminuirlo
( Innodb_pages_written / Innodb_buffer_pool_write_requests ) = 7,144,121 / 29935426 = 23.9% -- Scrivi richieste che dovevano colpire il disco-- Controlla innodb_buffer_pool_size
( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 1,199,046,656 / 4096M = 27.9% -- Percentuale del pool di buffer occupato dai dati-- Una piccola percentuale può indica che buffer_pool è inutilmente grande.
( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 533,153 / 60 * 512M / 20356473344 = 234 -- Minuti tra le rotazioni del log di InnoDB A partire da 5.6.8, questo può essere modificato dinamicamente; assicurati di cambiare anche my.cnf.-- (La raccomandazione di 60 minuti tra le rotazioni è alquanto arbitraria.) Regola innodb_log_file_size. (Impossibile modificare in AWS.)
( Innodb_rows_deleted / Innodb_rows_inserted ) = 364,605 / 414950 = 0.879 -- Churn-- "Non fare la coda, fallo e basta." (Se MySQL viene utilizzato come coda.)
( Created_tmp_disk_tables / (Created_tmp_disk_tables + Created_tmp_tables) ) = 247,373 / (247373 + 446152) = 35.7% -- Percentuale di tabelle temporanee che si sono riversate su disco:forse aumentare tmp_table_size e max_heap_table_size; evitare blob, ecc.
( Select_scan ) = 871,872 / 533153 = 1.6 /sec -- scansioni di tabelle complete-- Aggiungi indici/ottimizza le query (a meno che non siano tabelle minuscole)
( Select_scan / Com_select ) = 871,872 / 12593904 = 6.9% -- % di selezioni che eseguono la scansione completa della tabella. (Può essere ingannato dalle routine memorizzate.)-- Aggiungi indici / ottimizza le query
( Com_optimize ) = 216 / 533153 = 1.5 /HR -- Con quale frequenza viene eseguito OPTIMIZE TABLE.-- OPTIMIZE TABLE è raramente utile, certamente non ad alta frequenza.
( long_query_time ) = 10.000000 = 10 -- Cutoff (Seconds) per definire una query "lenta".-- Suggerisci 2
Estremi (senza commento):
Anormalmente piccolo:
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
Anormalmente grande:
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?)
Stringhe anomale:
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 di query
Poiché è stato disattivato, nessuno dei valori di stato di Qcache è stato impostato. Quindi non posso rispondere alla domanda originale. Se desideri accendere il QC e riavviare il server e attendere alcuni giorni, potrei rianalizzare con esso. Varie metriche su hit, prugne e così via possono rispondere alla domanda originale.
