Op bijna alle productieservers is het verstandig om de Query-cache uit te schakelen. Elke wijziging van een tabel veroorzaakt het opschonen van alle QC-items voor die tabel. Hoe groter de tafel, hoe meer tijd dat kost. 128M is gevaarlijk hoog.
Normaal gesproken is het verstandig om innodb_buffer_pool_size . in te stellen tot ongeveer 70% van beschikbare RAM. Je hebt het ingesteld op een veel lagere waarde, zelfs minder dan de datasetgrootte. 3G zou waarschijnlijk helpen. 20G zou niet meer helpen (totdat uw dataset aanzienlijk groeit).
Zorg ervoor dat zowel het besturingssysteem als MySQL 64-bits versies zijn.
Voor een meer grondige analyse, geef
- RAM-grootte (32G)
SHOW VARIABLES;SHOW GLOBAL STATUS;(na minimaal 24 uur te hebben gelopen)
Analyse van VARIABELEN en STATUS:
De belangrijkste problemen
Aangezien u alleen (?) InnoDB en slechts 2 GB aan gegevens gebruikt, is het niet van cruciaal belang om te reageren op de opmerkingen over innodb_buffer_pool_size en key_buffer_size
Geef wat meer details over uw veelvuldig gebruik van DELETE .
Maak gebruik van de slowlog om de 'slechtste' queries te vinden. Meer details hier . Dat zou de onderstaande problemen met tmp_table en tabelscan moeten identificeren.
Gebruik geen OPTIMIZE TABLE .
Hoe doe je "transacties"? Soms met autocommit, soms met COMMIT ?
Details en andere opmerkingen
( Key_blocks_used * 1024 / key_buffer_size ) = 4,710 * 1024 / 128M = 3.6% -- Percentage van key_buffer gebruikt. High-water-mark.-- Verlaag key_buffer_size om onnodig geheugengebruik te voorkomen.
( innodb_buffer_pool_size / _ram ) = 4096M / 32768M = 12.5% -- % RAM gebruikt voor InnoDB buffer_pool
( (key_buffer_size / 0.20 + innodb_buffer_pool_size / 0.70) / _ram ) = (128M / 0.20 + 4096M / 0.70) / 32768M = 19.8% -- Het grootste deel van het beschikbare RAM-geheugen zou beschikbaar moeten zijn voor caching.-- http://mysql. rjweb.org/doc.php/memory
( Innodb_buffer_pool_pages_free * 16384 / innodb_buffer_pool_size ) = 187,813 * 16384 / 4096M = 71.6% -- bufferpool vrij -- buffer_pool_size is groter dan de werkset; zou het kunnen verminderen
( Innodb_pages_written / Innodb_buffer_pool_write_requests ) = 7,144,121 / 29935426 = 23.9% -- Schrijf verzoeken die schijf moesten raken -- Controleer innodb_buffer_pool_size
( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 1,199,046,656 / 4096M = 27.9% -- Percentage van bufferpool dat wordt ingenomen door gegevens -- Een klein percentage mag geven aan dat de buffer_pool onnodig groot is.
( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 533,153 / 60 * 512M / 20356473344 = 234 -- Minuten tussen InnoDB log rotaties Vanaf 5.6.8 kan dit dynamisch worden gewijzigd; zorg ervoor dat u ook my.cnf.-- wijzigt (De aanbeveling van 60 minuten tussen rotaties is enigszins willekeurig.) Pas innodb_log_file_size aan. (Kan niet wijzigen in AWS.)
( Innodb_rows_deleted / Innodb_rows_inserted ) = 364,605 / 414950 = 0.879 -- Churn -- "Stel het niet in de rij, doe het gewoon." (Als MySQL als wachtrij wordt gebruikt.)
( Created_tmp_disk_tables / (Created_tmp_disk_tables + Created_tmp_tables) ) = 247,373 / (247373 + 446152) = 35.7% -- Percentage tijdelijke tabellen dat naar schijf is gemorst -- misschien verhogen tmp_table_size en max_heap_table_size; vermijd blobs, enz.
( Select_scan ) = 871,872 / 533153 = 1.6 /sec -- volledige tabelscans -- Indexen toevoegen / zoekopdrachten optimaliseren (tenzij het kleine tabellen zijn)
( Select_scan / Com_select ) = 871,872 / 12593904 = 6.9% -- % van de selecties die de volledige tabel scannen. (Kan voor de gek gehouden worden door opgeslagen routines.)-- Indexen toevoegen / zoekopdrachten optimaliseren
( Com_optimize ) = 216 / 533153 = 1.5 /HR -- Hoe vaak OPTIMIZE TABLE wordt uitgevoerd.-- OPTIMIZE TABLE is zelden nuttig, zeker niet bij hoge frequenties.
( long_query_time ) = 10.000000 = 10 -- Cutoff (seconden) voor het definiëren van een "trage" zoekopdracht.-- Suggest 2
Extremen (zonder commentaar):
Abnormaal 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
Abnormaal groot:
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 snaren:
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
Query cache
Omdat het was uitgeschakeld, zijn geen van de Qcache-statuswaarden ingesteld. Ik kan dus niet ingaan op de oorspronkelijke vraag. Als u de QC wilt inschakelen en de server opnieuw wilt opstarten en een paar dagen wilt wachten, kan ik het opnieuw analyseren. Verschillende statistieken over hits, pruimen, enz. kunnen beantwoord de oorspronkelijke vraag.