Na prawie wszystkich serwerach produkcyjnych rozsądnie jest wyłączyć pamięć podręczną zapytań. Każdy modyfikacja tabeli powoduje wyczyszczenie wszystkich Wpisy QC dla tej tabeli. Im większy stół, tym więcej czasu to zajmuje. 128M jest niebezpiecznie wysoki.
Zwykle dobrze jest ustawić innodb_buffer_pool_size do około 70% dostępnych BARAN. Masz ustawioną znacznie niższą wartość, nawet mniejszą niż rozmiar zestawu danych. Prawdopodobnie 3G by pomogło. 20G już by nie pomogło (dopóki Twój zbiór danych nie powiększy się znacząco).
Upewnij się, że zarówno system operacyjny, jak i MySQL są wersjami 64-bitowymi.
Aby uzyskać dokładniejszą analizę, podaj
- Rozmiar pamięci RAM (32G)
SHOW VARIABLES;SHOW GLOBAL STATUS;(po co najmniej 24 godzinach pracy)
Analiza ZMIENNYCH i STANU:
Ważniejsze problemy
Ponieważ używasz tylko (?) InnoDB i tylko 2 GB danych, reagowanie na komentarze dotyczące innodb_buffer_pool_size nie jest krytyczne i key_buffer_size
Podaj więcej szczegółów na temat intensywnego korzystania z DELETE .
Skorzystaj ze slowloga, aby znaleźć „najgorsze” zapytania. Więcej szczegółów tutaj . Powinno to zidentyfikować problemy ze skanowaniem tmp_table i tabel wymienione poniżej.
Nie zawracaj sobie głowy używaniem OPTIMIZE TABLE .
Jak robisz "transakcje"? Czasami z automatycznym zatwierdzaniem, czasami z COMMIT ?
Szczegóły i inne obserwacje
( Key_blocks_used * 1024 / key_buffer_size ) = 4,710 * 1024 / 128M = 3.6% -- Procent użytego key_buffera. High-water-mark.-- Zmniejsz key_buffer_size, aby uniknąć niepotrzebnego użycia pamięci.
( innodb_buffer_pool_size / _ram ) = 4096M / 32768M = 12.5% -- % pamięci RAM używanej przez pulę_buforów InnoDB
( (key_buffer_size / 0.20 + innodb_buffer_pool_size / 0.70) / _ram ) = (128M / 0.20 + 4096M / 0.70) / 32768M = 19.8% -- Większość dostępnego pamięci RAM powinna być dostępna do buforowania.-- http://mysql. rjweb.org/doc.php/pamięć
( Innodb_buffer_pool_pages_free * 16384 / innodb_buffer_pool_size ) = 187,813 * 16384 / 4096M = 71.6% -- pula buforów wolna -- buffer_pool_size jest większy niż zestaw roboczy; może to zmniejszyć
( Innodb_pages_written / Innodb_buffer_pool_write_requests ) = 7,144,121 / 29935426 = 23.9% -- Zapisuj żądania, które musiały trafić na dysk -- Sprawdź innodb_buffer_pool_size
( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 1,199,046,656 / 4096M = 27.9% – Procent puli buforów zajętych przez dane – Niewielki procent może wskazują, że pula_buforów jest niepotrzebnie duża.
( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 533,153 / 60 * 512M / 20356473344 = 234 -- Minuty między rotacjami dziennika InnoDB Począwszy od 5.6.8, można to zmieniać dynamicznie; pamiętaj, aby zmienić także my.cnf.-- (Zalecenie 60 minut między rotacjami jest nieco arbitralne.) Dostosuj innodb_log_file_size. (Nie można zmienić w AWS.)
( Innodb_rows_deleted / Innodb_rows_inserted ) = 364,605 / 414950 = 0.879 -- Churn-- "Nie czekaj w kolejce, po prostu zrób to." (Jeśli MySQL jest używany jako kolejka.)
( Created_tmp_disk_tables / (Created_tmp_disk_tables + Created_tmp_tables) ) = 247,373 / (247373 + 446152) = 35.7% -- Procent tabel tymczasowych, które zostały rozlane na dysk -- może zwiększyć tmp_table_size i max_heap_table_size; unikaj plam itp.
( Select_scan ) = 871,872 / 533153 = 1.6 /sec -- pełne skanowanie tabel -- Dodaj indeksy / zoptymalizuj zapytania (chyba że są to małe tabele)
( Select_scan / Com_select ) = 871,872 / 12593904 = 6.9% -- % zaznaczeń wykonujących pełne skanowanie tabeli. (Może zostać oszukany przez przechowywane procedury).-- Dodaj indeksy/optymalizuj zapytania
( Com_optimize ) = 216 / 533153 = 1.5 /HR -- Jak często wykonywana jest funkcja OPTIMIZE TABLE.-- OPTIMIZE TABLE jest rzadko przydatna, a już na pewno nie przy dużej częstotliwości.
( long_query_time ) = 10.000000 = 10 -- Odcięcie (w sekundach) do zdefiniowania „wolnego” zapytania.-- Sugeruj 2
Ekstrema (bez komentarza):
Rażąco mały:
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
Nienormalnie duży:
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?)
Nieprawidłowe ciągi:
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
Pamięć podręczna zapytań
Ponieważ został wyłączony, nie została ustawiona żadna z wartości stanu Qcache. Więc nie mogę odpowiedzieć na pierwotne pytanie. Jeśli chciałbyś włączyć QC i zrestartować serwer i poczekać kilka dni, mógłbym przeprowadzić ponowną analizę z włączonym. Różne dane dotyczące trafień, suszonych śliwek itp. mogą odpowiedz na pierwotne pytanie.
