Вывод mysqltuner, рекомендации по настройкам?

Question

Вывод mysqltuner, рекомендации по настройкам?

0

У меня нет 250 ГБ ОЗУ (в нашем бюджете), у меня в настоящее время 70 ГБ, и он заполняет 57 ГБ после часа использования (буферы mysql).
Я в основном не уверен в:
временные буферы таблицы буфера запросов чернослив join_buffer и размер query_cache

Буфер innodb, вероятно, не слишком мал, большая часть из этих 240GB редко доступна. Я думаю, что в основном доступ к материалам.

Некоторые из этих значений уже находятся на краю, где я читал, что это не полезно (например, 128 МБ tmp_table или 1MB join_buffer)

[--] Up for: 9h 51m 30s (78M q [2K qps], 921K conn, TX: 110B, RX: 26B)
[--] Reads / Writes: 49% / 51%
[--] Total buffers: 46.6G global + 1.9M per thread (1500 max threads)
[OK] Maximum possible memory usage: 49.3G (82% of installed RAM)
[OK] Slow queries: 0% (1K/78M)
[OK] Highest usage of available connections: 28% (428/1500)
[OK] Key buffer size / total MyISAM indexes: 256.0M/1.6G
[OK] Key buffer hit rate: 99.9% (105M cached / 55K reads)
[OK] Query cache efficiency: 26.9% (11M cached / 44M selects)
[!!] Query cache prunes per day: 4482061
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 10M sorts)
[!!] Joins performed without indexes: 603
[!!] Temporary tables created on disk: 49% (1M on disk / 2M total)
[OK] Thread cache hit rate: 99% (6K created / 921K connections)
[OK] Table cache hit rate: 83% (1K open / 2K opened)
[OK] Open file limit used: 12% (633/5K)
[OK] Table locks acquired immediately: 99% (9M immediate / 9M locks)
[!!] InnoDB  buffer pool / data size: 46.0G/240.6G
[OK] InnoDB log waits: 0
-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    Increasing the query_cache size over 128M may reduce performance
    Adjust your join queries to always utilize indexes
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
    query_cache_size (> 180M) [see warning above]
    join_buffer_size (> 1.0M, or always use indexes with joins)
    tmp_table_size (> 128M)
    max_heap_table_size (> 128M)
    innodb_buffer_pool_size (>= 240G)

конфигурации:

max_allowed_packet      = 64M
thread_stack            = 256K
thread_cache_size       = 16

max_connections         = 1500
max_user_connections    = 850
query_cache_limit       = 3M
query_cache_size        = 180M
query_cache_type        = 1
table_open_cache        = 2500
key_buffer_size          = 256M   # index in memory for myisam
innodb_buffer_pool_size = 46G
innodb_log_file_size = 256M
tmp_table_size = 128M
max_heap_table_size = 128M
join_buffer_size = 1M

John 15 янв. 2018, в 07:17

Источник

0

Я не эксперт по MySQL, но если у вас проблемы с 70 ГБ ОЗУ, вы, вероятно, не используете открытые соединения. Если у вас нет сайта, подобного Amazon.
Juan Carlos Oropeza 15 янв. 2018, в 05:22

Теги:

mysql

mariadb

2 ответа

Ещё вопросы

Я не эксперт по MySQL, но если у вас проблемы с 70 ГБ ОЗУ, вы, вероятно, не используете открытые соединения. Если у вас нет сайта, подобного Amazon.

Wilson Hauck · Answer 1 · 2018-02-05T14-59-00.000Z

В конфигурационном файле что делать:

thread_cache_size=100  # from 16  for V8 suggested CAP on busy system
innodb_buffer_pool_instances=8  # from default 1 to reduce mutex contention
query_cache_min_res_unit=512  # from 4K to increase capacity of QC
query_cache_limit=1M  # from 3M - 180M QC could only hold 60 of them
query_prealloc_size=32768  # from def 8192 to reduce malloc load
max_write_lock_count=2  # from a huge number to give RD opportunity every 2
max_connections=500  # from 1500 will leave 20% growth room
thread_concurrency=30  # to prevent saturation
key_age_threshold=64800  # why discard a key at 5 minutes? keep keep 18 hrs
key_cache_division_limit=50  # from 100% for warm cache to manage
key_cache_block_size=32768  # from 1024 to reduce CPU overhead

Rick James · Answer 2 · 2018-01-15T11-20-00.000Z

Попробуйте работать в 70 ГБ ОЗУ. "Пул буферов InnoDB/размер данных: 46.0G/240.6G" в порядке, если вы не слишком сильно бьетесь. Обычно улучшение индексов и/или запросов может помочь.

То, что я вижу в спецификациях кеша Query, не так уж плохо. Но насколько это велико? Каково значение query_cache_size? Если оно больше 50 М, оно слишком велико, потому что чернослив стоит дорого.

Не изменяйте другие настройки, которые рекомендует mysqltuner.

У вас около 50 query_cache_prunes в секунду, что слишком велико.

Таким образом, хотя скорость атаки высока, я подозреваю, что QC плохо настроен. Рекомендации:

Узнайте, какие запросы, вероятно, будут повторяться точно, а какие нет. Измените часто используемые для SELECT SQL_CACHE... и измените нечастые на SELECT SQL_NO_CACHE... И измените на query_cache_type = DEMAND.

Чтобы углубиться и исправить некоторые медленные запросы, пожалуйста, следуйте приведенным здесь рекомендациям.

Я обновляю свой вопрос с деталями конфигурации
@john Пожалуйста, опубликуйте полный текстовый отчет от MySQLTuner (полный отчет будет содержать подсказки об использовании таблицы INNODB и доступной / используемой оперативной памяти. Вы используете SSD или вращающиеся жесткие диски?
@john Планируется ли публиковать полный текстовый отчет из MySQLTuner (полный отчет будет содержать подсказки об использовании таблицы INNODB и о доступной / используемой оперативной памяти. Используете ли вы SSD или вращающиеся жесткие диски? Мы знаем, что вы заняты.