I nästan alla produktionsservrar är det klokt att stänga av Query-cachen. Varje ändring av en tabell orsakar rensning av alla QC-poster för den tabellen. Ju större bord, desto mer tid tar det. 128M är farligt högt.
Normalt är det klokt att ställa in innodb_buffer_pool_size till cirka 70 % av tillgänglig BAGGE. Du har det inställt på ett mycket lägre värde, till och med mindre än datasetstorleken. 3G skulle förmodligen hjälpa. 20G skulle inte hjälpa längre (tills din datauppsättning växer avsevärt).
Se till att både OS och MySQL är 64-bitarsversioner.
För en mer grundlig analys, tillhandahåll
- RAM-storlek (32G)
SHOW VARIABLES;SHOW GLOBAL STATUS;(efter att ha kört minst 24 timmar)
Analys av VARIABLER och STATUS:
De viktigare frågorna
Eftersom du bara (?) använder InnoDB och bara 2 GB data är det inte avgörande att svara på kommentarerna om innodb_buffer_pool_size och key_buffer_size
Ge lite mer information om din tunga användning av DELETE .
Använd slowlog för att hitta de "värsta" frågorna. Mer information här . Det bör identifiera problemen med tmp_table och tabellsökning som nämns nedan.
Bry dig inte om att använda OPTIMIZE TABLE .
Hur gör du "transaktioner"? Ibland med autocommit, ibland med COMMIT ?
Detaljer och andra observationer
( Key_blocks_used * 1024 / key_buffer_size ) = 4,710 * 1024 / 128M = 3.6% -- Procent av använd nyckelbuffert. High-water-mark.-- Sänk key_buffer_size för att undvika onödig minnesanvändning.
( innodb_buffer_pool_size / _ram ) = 4096M / 32768M = 12.5% -- % av RAM som används 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% -- Det mesta av tillgängligt ram ska göras tillgängligt för cachning.-- http://mysql. rjweb.org/doc.php/memory
( Innodb_buffer_pool_pages_free * 16384 / innodb_buffer_pool_size ) = 187,813 * 16384 / 4096M = 71.6% -- buffertpool ledig -- buffer_pool_size är större än arbetsuppsättningen; kan minska den
( Innodb_pages_written / Innodb_buffer_pool_write_requests ) = 7,144,121 / 29935426 = 23.9% -- Skriv förfrågningar som var tvungna att träffa disk-- Kontrollera innodb_buffer_pool_size
( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 1,199,046,656 / 4096M = 27.9% -- Procent av buffertpoolen som tas upp av data-- En liten procent kan indikerar att buffertpoolen är onödigt stor.
( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 533,153 / 60 * 512M / 20356473344 = 234 -- Minuter mellan InnoDB-loggrotationer Från och med 5.6.8 kan detta ändras dynamiskt; se till att även ändra my.cnf.-- (Rekommendationen på 60 minuter mellan rotationer är något godtycklig.) Justera innodb_log_file_size. (Kan inte ändras i AWS.)
( Innodb_rows_deleted / Innodb_rows_inserted ) = 364,605 / 414950 = 0.879 -- Churn-- "Ställ inte i kö, bara gör det." (Om MySQL används som en kö.)
( Created_tmp_disk_tables / (Created_tmp_disk_tables + Created_tmp_tables) ) = 247,373 / (247373 + 446152) = 35.7% -- Procent av temporära tabeller som spillts till disken-- kanske öka tmp_table_size och max_heap_table_size; undvik blobbar etc.
( Select_scan ) = 871,872 / 533153 = 1.6 /sec -- genomsökningar av hela tabellerna -- Lägg till index / optimera frågor (såvida de inte är små tabeller)
( Select_scan / Com_select ) = 871,872 / 12593904 = 6.9% -- % av de utvalda som gör full tabellskanning. (Kan luras av lagrade rutiner.) -- Lägg till index / optimera frågor
( Com_optimize ) = 216 / 533153 = 1.5 /HR -- Hur ofta OPTIMIZE TABLE utförs.-- OPTIMIZE TABLE är sällan användbart, absolut inte vid hög frekvens.
( long_query_time ) = 10.000000 = 10 -- Cutoff (sekunder) för att definiera en "långsam" fråga.-- Föreslå 2
Extremer (utan kommentar):
Onormalt liten:
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
Onormalt stor:
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?)
Onormala strängar:
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
Frågecache
Eftersom den stängdes av har inga av Qcache-statusvärdena ställts in. Så jag kan inte svara på den ursprungliga frågan. Om du vill slå på QC och starta om servern och vänta några dagar kan jag analysera om med den på. Olika mätvärden om träffar, katrinplommon osv kan ta upp den ursprungliga frågan.