НИЗКОЕ количество операций ввода-вывода в секунду после обновления MySQL RDS
Мы достигли верхних пределов наших IOPS в последние несколько дней. Мы несколько раз увеличивали количество операций ввода-вывода в секунду. 1250 -> 2500 -> 4500. На каждом этапе мы быстро видели, что мы использовали все доступные IOPS, так как он достигал максимума между чтением и записью.
Наконец, сегодня утром у нас был еще один крупный заказчик и наш ЦП, память и Максимальное количество операций ввода-вывода в секунду. Я принял решение выделить базу данных большего размера, чтобы система продолжала работать. Мы перешли с db.m5.xlarge на db.m5.2xlarge. Мы также увеличили количество операций ввода-вывода в секунду до 8000 с обновлением.
Теперь наш ЦП по сравнению с ним сильно забит, а количество операций ввода-вывода в секунду практически равно 0. Приложение кажется отзывчивым, но наши очереди задач довольно медленные.
Код не изменился, просто база данных. Что мне не хватает? RDS сообщает неправильно?
Вы заметите скачки числа операций ввода-вывода в секунду при чтении за последние 3 дня, которые соответствуют более высоким показателям операций ввода-вывода в секунду.
Вероятно, у вас есть запрос, который упал со скалы. (Спасибо за хорошее описание. Вот вероятное объяснение.)
Пример. Допустим, запрос сканирует таблицу размером 7 ГБ (без полезного индекса и т. Д.) С 70 млн строк.
Случай 1: RAM = 8 ГБ; innodb_buffer_pool_size = 6 ГБ. Запрос выталкивает все из кеша, чтобы завершить сканирование. Это требует надежного ввода-вывода. Все остальные запросы также затронуты - их данные также были вытеснены из ОЗУ.
Случай 2: ОЗУ = 16 ГБ; innodb_buffer_pool_size = 12 ГБ. При первом сканировании вся таблица загружается в кеш;последующие запуски этого запроса не требуют ввода-вывода. Даже другие запросы выполняются быстрее из-за отсутствия конкуренции за кэш.
В обоих случаях, вероятно, есть куча ресурсов процессора, просматривающих все 70 миллионов строк.
План A: потратьте деньги на то, чтобы иметь больше RAM, CPU и ненужные IOP.
План B: Найдите этот очень непростой запрос и попросите нас помочь его оптимизировать. Затем вы можете вернуться к более дешевой виртуальной машине.
Пожалуйста, предоставьте запрос и SHOW CREATE TABLE для задействованных таблиц. Решение может быть таким простым, как добавление составного индекса или переформулировка запроса.
Ключевым моментом здесь было вообще ничего не делать. «Волшебным образом» наш процессор нормализовался до того уровня, который я ожидал. Хорошей новостью было то, что я обнаружил несколько проблемных мест в наших запросах, несколько чрезмерно усердных блокировок и ТОННУ понимания настройки InnoDB / RDS / MySQL.
Возможно, RDS медленно оптимизирует индексы или что-то, чего я не совсем понимаю, но теперь у нас потрясающая задержка, пропускная способность и использование именно там, где я ожидал, с четырьмя ядрами и 2х памятью.
