Следующее не напрямую отвечает на вопрос, который вы задаете, но указывает на некоторые очень низкие настройки и использование MyISAM. Я не знаю, поможет ли переключение на InnoDB и / или увеличение некоторых настроек.
Имейте в виду, что сброс таблиц MyISAM по существу блокирует пользователей от работы с базой данных. (С другой стороны, возможно, ваш набор данных довольно мал, а активность довольно низкая.)
Наблюдения:
- Версия: 5.5.64- MariaDB
- 8 ГБ ОЗУ
- Время работы = 21:05:35; некоторые значения GLOBAL STATUS могут быть еще не значимыми.
- Вы не работаете на Windows.
- Работает на 64-битной версии
- Вы, кажется, работаете полностью (или в основном) MyISAM.
Более важные вопросы:
Вы должны перейти от MyISAM к InnoDB; см. Преобразование из MyISAM в InnoDB
Посмотрите, можете ли вы поднять следующее (более подробное обсуждение ниже):
open_files_limit = 2000
table_open_cache = 300
key_buffer_size = 200M
innodb_buffer_pool_size = 600M -- after moving tables to InnoDB
OPTIMIZE TABLE - нечастая задача; Вы делаете это слишком часто.
Подробности и другие наблюдения:
( (key_buffer_size / 0.20 + innodb_buffer_pool_size / 0.70) ) = ((16M / 0.20 + 128M / 0.70)) / 8192M = 3.2% - Большая часть доступного оперативного памяти должна быть доступна для кэширования. - http://mysql.rjweb.org/doc.php/memory
( open_files_limit ) = 760 - ulimit -n - Чтобы разрешить больше файлов, измените ulimit или /etc/security/limits.conf или в sysctl.conf (kern .maxfiles & kern.maxfilesperpro c) или что-то еще (зависит от ОС)
( table_open_cache ) = 64 - Количество дескрипторов таблиц для кэширования - обычно хорошо несколько сотен.
( innodb_buffer_pool_size ) = 128M - InnoDB Data + Index cache - 128M (старое значение по умолчанию) очень мало.
( Innodb_buffer_pool_pages_free / Innodb_buffer_pool_pages_total ) = 5,578 / 8191 = 68.1% - Pct of buffer_pool в настоящее время не используется - innodb_buffer_pool_size (сейчас 134217728) больше необходимого?
( innodb_print_all_deadlocks ) = innodb_print_all_deadlocks = OFF - регистрировать ли все тупики. - Если вы страдаете от тупиков, включите это. Внимание: Если у вас много взаимоблокировок, это может привести к записи большого количества на диск.
( join_buffer_size ) = 131,072 / 8192M = 0.00% - 0-N на поток. Может ускорять СОЕДИНЕНИЯ (лучше исправить запросы / индексы) (все механизмы) Используется для сканирования индекса, сканирования индекса диапазона, полного сканирования таблицы, каждого полного JOIN и т. Д. c. - Если большое, уменьшите join_buffer_size (теперь 131072), чтобы избежать нехватки памяти. Рекомендовать менее 1% оперативной памяти. Если мало, увеличьте до 0,01% ОЗУ для улучшения некоторых запросов.
( innodb_buffer_pool_populate ) = OFF = 0 - управление NUMA
( query_prealloc_size ) = 8,192 / 8192M = 0.00% - для анализа. Количество оперативной памяти
( query_alloc_block_size ) = 8,192 / 8192M = 0.00% - для анализа. Pct of RAM
( character_set_server ) = character_set_server = latin1 - Проблемам с кодировкой можно помочь, установив для character_set_server (теперь latin1) значение utf8mb4. Это будущее значение по умолчанию.
( local_infile ) = local_infile = ON - local_infile (теперь ON) = ON - потенциальная проблема безопасности
( Key_writes / Key_write_requests ) = 5,804 / 9232 = 62.9% - эффективность key_buffer для записей - если у вас достаточно ОЗУ, было бы целесообразно увеличить key_buffer_size (сейчас 16777216).
( Created_tmp_disk_tables / Created_tmp_tables ) = 13,250 / 18108 = 73.2% - процент временных таблиц, которые вылились на диск - возможно, увеличить tmp_table_size (теперь 16777216) и max_heap_table_size (теперь 16777216); улучшить показатели; избегайте больших двоичных объектов и т. д. c.
( (Com_insert + Com_update + Com_delete + Com_replace) / Com_commit ) = (68440 + 1927 + 425 + 0) / 0 = INF - Операции на коммит (с учетом всех InnoDB) - Низкий: может помочь объединить запросы в транзакции; Высокий: длинные транзакции напрягают разные вещи.
( Select_scan ) = 165,862 / 75935 = 2.2 /sec - полное сканирование таблицы - добавление индексов / оптимизация запросов (если они не являются крошечными таблицами)
( Com_optimize ) = 464 / 75935 = 22 /HR - как часто OPTIMIZE ТАБЛИЦА выполняется. - OPTIMIZE TABLE редко используется, конечно, не на высокой частоте.
( binlog_format ) = binlog_format = STATEMENT - STATEMENT / ROW / MIXED. - ROW предпочтительнее на 5,7 (10,3)
( expire_logs_days ) = 0 - Как скоро автоматически очистить binlog (после этого много дней) - Слишком большой (или ноль) = занимает дисковое пространство; слишком маленький = нужно быстро реагировать на сеть / машину cra sh. (Не актуально, если log_bin (теперь OFF) = OFF)
( innodb_autoinc_lock_mode ) = 1 - Galera: желания 2 - 2 = "чередование"; 1 = "последовательный" типичный; 0 = "традиционный". - Галера желаний 2; 2 требует BINLOG_FORMAT = ROW или MIXED
( log_slow_queries ) = log_slow_queries = OFF - для регистрации медленных запросов. (До 5.1.29, 5.6.1)
( slow_query_log ) = slow_query_log = OFF - регистрировать ли медленные запросы. (5.1.12)
( long_query_time ) = 10 - Обрезание (секунды) для определения «медленного» запроса. - Предложите 2
( back_log ) = 50 - (Размер по состоянию на 5.6.6; основан на max_connections) - Повышение до минимума (150, max_connections (теперь 151)) может помочь при выполнении большого количества соединений.
( Com_change_db / Connections ) = 1,278,567 / 363881 = 3.51 - Переключатели базы данных на соединение - (второстепенно) Рассмотрите возможность использования синтаксиса "db.table"
( Com_change_db ) = 1,278,567 / 75935 = 17 /sec - Вероятно, из операторов USE. - Рассмотреть возможность соединения с БД, используя синтаксис db.tbl, исключить ложные операторы USE и т. Д. c.
( Threads_running / thread_cache_size ) = 1 / 0 = INF - Потоки: текущие / кэшированные (не относится к использованию пула потоков) - Оптимизировать запросы
У вас есть тайм Query Cache. Вы должны установить и query_cache_type = OFF, и query_cache_size = 0. Существует (согласно слухам) «ошибка» в коде Q C, которая оставляет некоторый код включенным, если вы не отключите обе эти настройки.
Аномально маленький:
( Innodb_pages_read + Innodb_pages_written ) / Uptime = 0.0672
(innodb_buffer_pool_size + innodb_log_buffer_size + key_buffer_size + query_cache_size + Max_used_connections * (thread_stack + net_buffer_length)) / _ram = 1.9%
Innodb_adaptive_hash_non_hash_searches = 1.1 /sec
Innodb_buffer_pool_pages_flushed / max(Questions, Queries) = 0.00056
Innodb_buffer_pool_pages_made_young = 0
Innodb_buffer_pool_pages_old = 943
Innodb_buffer_pool_read_ahead = 0
Innodb_checkpoint_max_age = 7.78e+6
Innodb_ibuf_merged_inserts = 0
Innodb_ibuf_merges = 0
Innodb_lsn_current = 2.52e+8
Innodb_lsn_flushed = 240.6MB
Innodb_lsn_last_checkpoint = 2.52e+8
Innodb_master_thread_10_second_loops = 945
Innodb_master_thread_1_second_loops = 10,439
Innodb_master_thread_sleeps = 0.14 /sec
Innodb_mem_adaptive_hash = 2.25e+6
Innodb_mem_dictionary = 2.1e+6
Innodb_mem_total = 131.4MB
Innodb_pages_read + Innodb_pages_written = 0.067 /sec
Innodb_x_lock_spin_waits = 0.047 /HR
Open_tables = 64
net_buffer_length = 8,192
Аномально большой:
Com_check = 22 /HR
Com_show_charsets = 28 /HR
Com_show_events = 1.2 /HR
Feature_gis = 0.66 /HR
Аномальные строки:
binlog_checksum = NONE
innodb_fast_shutdown = 1
opt_s__engine_condition_pushdown = off
opt_s__extended_keys = off