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