På næsten alle produktionsservere er det klogt at slå Query-cachen fra. Hver ændring af en tabel forårsager rensning af alle QC-poster for den tabel. Jo større bordet er, jo mere tid tager det. 128M er farligt højt.
Normalt er det klogt at indstille innodb_buffer_pool_size til omkring 70 % af tilgængelig VÆDDER. Du har den indstillet til en meget lavere værdi, endda mindre end datasættets størrelse. 3G ville nok hjælpe. 20G ville ikke hjælpe mere (indtil dit datasæt vokser markant).
Sørg for, at både OS og MySQL er 64-bit versioner.
Angiv
for en mere grundig analyse- RAM-størrelse (32G)
SHOW VARIABLES;SHOW GLOBAL STATUS;(efter at have kørt mindst 24 timer)
Analyse af VARIABLER og STATUS:
De vigtigere problemer
Da du kun (?) bruger InnoDB og kun 2 GB data, er det ikke afgørende at svare på kommentarerne om innodb_buffer_pool_size og key_buffer_size
Angiv nogle flere detaljer om din store brug af DELETE .
Gør brug af slowlog til at finde de 'værste' forespørgsler. Flere detaljer her . Det skulle identificere tmp_table og tabelscanningsproblemerne nævnt nedenfor.
Lad være med at bruge OPTIMIZE TABLE .
Hvordan laver du "transaktioner"? Nogle gange med autocommit, nogle gange med COMMIT ?
Detaljer og andre observationer
( Key_blocks_used * 1024 / key_buffer_size ) = 4,710 * 1024 / 128M = 3.6% -- Procent af brugt nøglebuffer. High-water-mark.-- Sænk key_buffer_size for at undgå unødvendig hukommelsesbrug.
( innodb_buffer_pool_size / _ram ) = 4096M / 32768M = 12.5% -- % af RAM brugt til 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 meste af tilgængelig ram bør gøres tilgængelig for caching.-- 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 er større end arbejdssæt; kunne mindske det
( Innodb_pages_written / Innodb_buffer_pool_write_requests ) = 7,144,121 / 29935426 = 23.9% -- Skriv anmodninger, der skulle ramme disk-- Tjek innodb_buffer_pool_size
( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 1,199,046,656 / 4096M = 27.9% -- Procent af bufferpuljen optaget af data-- En lille procent kan angive, at buffer_poolen er unødvendigt stor.
( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 533,153 / 60 * 512M / 20356473344 = 234 -- Minutter mellem InnoDB-logrotationer Fra og med 5.6.8 kan dette ændres dynamisk; sørg for også at ændre my.cnf.-- (Anbefalingen på 60 minutter mellem rotationer er noget vilkårlig.) Juster innodb_log_file_size. (Kan ikke ændres i AWS.)
( Innodb_rows_deleted / Innodb_rows_inserted ) = 364,605 / 414950 = 0.879 -- Churn-- "Lad være med at stille det i kø, bare gør det." (Hvis MySQL bruges som en kø.)
( Created_tmp_disk_tables / (Created_tmp_disk_tables + Created_tmp_tables) ) = 247,373 / (247373 + 446152) = 35.7% -- Procent af midlertidige tabeller, der spildes til disken - måske øge tmp_table_size og max_heap_table_size; undgå klatter osv.
( Select_scan ) = 871,872 / 533153 = 1.6 /sec -- fuld tabelscanninger -- Tilføj indekser / optimer forespørgsler (medmindre de er små tabeller)
( Select_scan / Com_select ) = 871,872 / 12593904 = 6.9% -- % af udvalgte, der laver fuld tabelscanning. (Kan blive narre af lagrede rutiner.)-- Tilføj indekser / optimer forespørgsler
( Com_optimize ) = 216 / 533153 = 1.5 /HR -- Hvor ofte udføres OPTIMIZE TABLE.-- OPTIMIZE TABLE er sjældent nyttigt, bestemt ikke ved høj frekvens.
( long_query_time ) = 10.000000 = 10 -- Cutoff (sekunder) for at definere en "langsom" forespørgsel.-- Foreslå 2
Yderligheder (uden kommentarer):
Unormalt lille:
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
Unormalt 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?)
Unormale strenge:
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
Forespørgselscache
Siden den blev slået fra, blev ingen af Qcache-statusværdierne indstillet. Så jeg kan ikke besvare det oprindelige spørgsmål. Hvis du gerne vil tænde for QC og genstarte serveren og vente et par dage, kunne jeg analysere igen med den tændt. Forskellige metrics om hits, svesker osv. kan besvare det oprindelige spørgsmål.