У нас проблемы с настройкой MySQL 5.6 на AWS, и мы ищем указатели для решения некоторых проблем с производительностью.
Раньше у нас были выделенные серверы, и мы могли настраивать их по своему усмотрению.
Наше приложениеиспользует много временных таблиц, и у нас не было проблем с производительностью в этом отношении.
Пока мы не переключились на экземпляр AWS RDS.
Теперь в журналах появляется много медленных запросов, что замедляет работу всего приложения.
Ранее мы работали с MySQL 5.4, а сейчас - 5.6.
Просматривая документы, мы обнаружили некоторые изменения, касающиеся формата временных таблиц по умолчанию.
По умолчанию это InnoDB, и мы вернули его обратно в MYISAM.как мы привыкли и добились улучшения в этом отношении.
первый аспект:
Кроме того, наша БД достаточно велика, и у нас есть сотни одновременных доступ к нашему приложениюи некоторые таблицы требуют вычисления в реальном времени.В этом случае используются Join и Unions.
При разработке приложения (с MySQL 5.4) мы обнаружили, что разбиение больших запросов на 2 или более шагов и использование промежуточных таблиц повышает общую производительность.
Explain показал сортировку файлов и временный файл, чтобы мы могли избавиться от них с временными таблицами.
Является ли разбиение запросов на временные таблицы действительно хорошей идеей?
Редактировать Мы знаем условия онеявное преобразование временных таблиц MEMORY на диск.
Другая вещь, в которой мы не уверены, заключается в том, что делает запрос с использованием временных файлов?
Мы знаем, что использование правильных индексов - это один из способов (использование правильного порядка в предложении where, правильное использование order by и т. д.), но есть ли что-то еще, что мы могли бы сделать?
второй аспект:
Что касается некоторых настроек, которые мы используем, мы имеемнесколько сотен Мбайт для max_heap_table_size и tmp_table_size, поэтому мы надеялись, что наши временные таблицы могут храниться в памяти.
Мы также нашли статьи, описывающиеg, чтобы посмотреть ReadIOPS и WriteIOPS.
Показания стабильны и низки, но записи показывают нестабильные и большие числа.
Вот график:
Значения по вертикальной оси - это операции / сек.
Как мы можем интерпретировать эти числа?
Одна вещь, которую нужно знать о нашем приложении, состоит в том, что каждое действие пользователя записывается в один большой журнал.Таблица.Но это должно быть один раз на страницу загрузки.
третий аспект:
Как далеко мы можем пойти с этими настройками, чтобы временные таблицы могли использоваться в памяти?
Например, мы читаем некоторыев статьях, объясняющих, что они установили несколько Гбайт max_heap_table_size на выделенном сервере MySQL с около 12 Гбайт оперативной памяти.(звучит примерно 80% или около того)
Это действительно то, что мы можем попробовать?(Применимы ли те же настройки к RDS?) Кроме того, можем ли мы установить innodb_buffer_pool_size на то же значение?
Примечание Я не могу найти там статью, где я нашел эту информацию,но я мог бы перепутать некоторые имена параметров.Я отредактирую вопрос, если снова найду источник.
Настройки сервера сильно отличаются от того, что у нас было (новые серверы на AWS не установлены нами), и многие значения настроек были увеличеныи некоторые уменьшились.
Мы боимся, что это нехорошо…
Вот некоторые заметные изменения:
- innodb_buffer_pool_size (увеличено * 6)
- innodb_log_buffer_size (уменьшено/ 4)
- innodb_additional_mem_pool_size (уменьшено / 4)
- sort_buffer_size (уменьшено / 2)
- myisam_sort_buffer_size (увеличено * 1279) (у нас есть только таблицы innoDB, нам нужнокоснуться этого?)
- read_buffer_size (увеличено * 2)
- join_buffer_size (уменьшено / 4)
- read_rnd_buffer_size (увеличено * 4)
- tmp_table_size + max_heap_table_size (увеличилось * 8)
Некоторые изменения кажутся нам странными (например, myisam_sort_buffer_size), мы думаем, что использование тех же настроек было бы лучше с самого начала.
Можем ли мы иметь некоторые указатели на эти переменные?(Извините, мы не можем предоставить точные цифры)
Кроме того, есть ли хорошая статья, которую мы могли бы прочитать, которая суммирует хороший баланс между всеми этими параметрами?
Поскольку мы обеспокоены временными таблицамине помещается в памяти, я сделал этот запрос, чтобы увидеть, какой процент запросов фактически записывается на диск:
select
tmp_tables
,tmp_tables_disk
,round( (tmp_tables_disk / tmp_tables) * 100, 2 ) as to_disk_percent
from
(select variable_value as tmp_tables from information_schema.GLOBAL_STATUS where variable_name = 'Created_tmp_tables') as s1
,(select variable_value as tmp_tables_disk from information_schema.GLOBAL_STATUS where variable_name =
'Created_tmp_disk_tables') as s2
Результат составляет 10 ~ 12% (в зависимости от экземпляра).Это высоко?
TL; DR
Я пытался добавить как можно больше подробностей в вопрос о текущей ситуации, надеюсь, что это не более запутанно, чем-нибудь ...
Вопросы о записи.Есть ли способ диагностировать, что вызывает так много записей?(может быть, связаны с временными таблицами?)