В почти всички производствени сървъри е разумно да изключите кеша на заявките. Всеки промяната на таблица води до изчистване на всички QC записи за тази таблица. Колкото по-голяма е масата, толкова повече време отнема. 128M е опасно високо.
Обикновено е разумно да зададете innodb_buffer_pool_size до около 70% от наличните RAM. Задали сте го на много по-ниска стойност, дори по-малка от размера на набора от данни. 3G вероятно ще помогне. 20G няма да помогне повече (докато наборът от данни не нарасне значително).
Уверете се, че операционната система и MySQL са 64-битови версии.
За по-задълбочен анализ предоставете
- Размер на RAM (32G)
SHOW VARIABLES;SHOW GLOBAL STATUS;(след работа поне 24 часа)
Анализ на ПРОМЕНЛИВИ и СЪСТОЯНИЕ:
По-важните въпроси
Тъй като използвате само (?) InnoDB и само 2 GB данни, не е критично да отговаряте на удара с коментари относно innodb_buffer_pool_size и key_buffer_size
Предоставете малко повече подробности за интензивното използване на DELETE .
Използвайте slowlog, за да намерите „най-лошите“ заявки. Повече подробности тук . Това трябва да идентифицира проблемите с tmp_table и сканирането на таблици, споменати по-долу.
Не си правете труда да използвате OPTIMIZE TABLE .
Как се справяте с "транзакциите"? Понякога с autocommit, понякога с COMMIT ?
Подробности и други наблюдения
( Key_blocks_used * 1024 / key_buffer_size ) = 4,710 * 1024 / 128M = 3.6% -- Използван процент на key_buffer. High-water-mark.-- Намалете key_buffer_size, за да избегнете ненужното използване на паметта.
( innodb_buffer_pool_size / _ram ) = 4096M / 32768M = 12.5% -- % от RAM, използван за InnoDB buffer_pool
( (key_buffer_size / 0.20 + innodb_buffer_pool_size / 0.70) / _ram ) = (128M / 0.20 + 4096M / 0.70) / 32768M = 19.8% -- По-голямата част от наличната RAM трябва да бъде предоставена за кеширане.-- 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_size е по-голям от работния набор; може да го намали
( Innodb_pages_written / Innodb_buffer_pool_write_requests ) = 7,144,121 / 29935426 = 23.9% -- Заявки за писане, които трябваше да ударят диска -- Проверете innodb_buffer_pool_size
( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 1,199,046,656 / 4096M = 27.9% -- Процент на буферния пул, зает от данни -- Малък процент може показват, че buffer_pool е ненужно голям.
( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 533,153 / 60 * 512M / 20356473344 = 234 -- Минути между ротациите на журналите на InnoDB Започвайки с 5.6.8, това може да се променя динамично; не забравяйте също така да промените my.cnf.-- (Препоръката за 60 минути между завъртанията е донякъде произволна.) Коригирайте innodb_log_file_size. (Не може да се промени в AWS.)
( Innodb_rows_deleted / Innodb_rows_inserted ) = 364,605 / 414950 = 0.879 -- Churn-- "Не го чакайте на опашка, просто го направете." (Ако MySQL се използва като опашка.)
( Created_tmp_disk_tables / (Created_tmp_disk_tables + Created_tmp_tables) ) = 247,373 / (247373 + 446152) = 35.7% -- Процент на временните таблици, които са прехвърлени на диска -- може би увеличаване на tmp_table_size и max_heap_table_size; избягвайте петна и т.н.
( Select_scan ) = 871,872 / 533153 = 1.6 /sec -- пълно сканиране на таблици -- Добавяне на индекси / оптимизиране на заявки (освен ако не са малки таблици)
( Select_scan / Com_select ) = 871,872 / 12593904 = 6.9% -- % от избраните, извършващи пълно сканиране на таблица. (Може да се заблуди от съхранените процедури.)-- Добавяне на индекси / оптимизиране на заявки
( Com_optimize ) = 216 / 533153 = 1.5 /HR -- Колко често се изпълнява OPTIMIZE TABLE.-- OPTIMIZE TABLE рядко е полезно, със сигурност не при висока честота.
( long_query_time ) = 10.000000 = 10 -- Прекъсване (секунди) за дефиниране на „бавна“ заявка.-- Предложение 2
Крайности (без коментар):
Ненормално малък:
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
Ненормално голям:
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?)
Ненормални низове:
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
Кеш на заявките
Тъй като беше изключен, нито една от стойностите на състоянието на Qcache не беше зададена. Така че не мога да отговоря на първоначалния въпрос. Ако искате да включите QC и да рестартирате сървъра и да изчакате няколко дни, мога да направя повторен анализ с него. Различни показатели за посещения, сини сливи и т.н. може адресирайте първоначалния въпрос.
