Мы используем RDS в экземпляре db.t2.large. Группа автомасштабирования EC2 записывает данные в базу данных в течение дня. В часы пик у нас около 50 000 HTTP-запросов, каждый из которых считывает/записывает данные MySQL.Время соединения RDS в часы пик (с ~ 50 000 HTTP-запросами)
Это изменяется каждый день, но для сегодняшнего, например, в течение часа:
Мы видим, что «Connect Error (2002) Тайм-аут соединения» от наших PHP экземпляров, около 187 раз в минуту.
- RDS процессор не будет поднимать выше 50%
- DB Соединения не будет идти выше 30 (макс установлен в 5000).
- Свободное хранение ~ 300G (размер диска большой, чтобы обеспечить высокие IOPS)
- Запись IOPS ударила 1500, но упала до 900, потому что срок действия пакета истек, после часов пик.
- Чтение IOPS поражает 300 каждые 10 минут и около 150 между ними.
- Disk Write Пропускная способность составляет в среднем от 20 до 25 МБ/сек
- Disk Read Пропускной способности между 0,75 и 1,5 Мб/сек
- CPU Credit Balance составляет около 500, так что мы не имеем необходимости процессор разбился.
И когда речь идет о сети, я вижу потенциальный предел мы ударяя:
- Network Receive Пропускной достигает 1,41 МБ/сек и остаются около 1,5 Мбайт/секунд в течение часа.
- За это время сеть передачи 5 5,2 Мб/с каплями до 4 МБ/каждые 10 мин, который совпадает с нашим cronjobs, которые обработки данных (в основном для чтения)
Я пытался размещения EC2-х в разных или тех же AZ, но это не влияет
За это время я могу подключиться с моей локальной рабочей станции через SSH Tunnel (EC2 -> RDS). И от EC2 до RDS.
Сценарии PHP установлены на тайм-аут после 5 секунд попытки подключения для обеспечения быстрого ответа. Я увеличил этот предел до 15 секунд для некоторых скриптов.
Но какой предел мы нажимаем на RDS? Прежде чем начать миграцию или изменение типов экземпляров, мы хотели бы узнать источник этой проблемы. Я также просто включил расширенный мониторинг, чтобы получить более подробную информацию по этой проблеме.
Если вам нужна дополнительная информация, я с удовольствием разработаю там, где это необходимо.
Спасибо!
Update 25/01/2016
По рекомендации datasage мы увеличили размер диска RDS до 500 Гб, что дает нам 1500 IOPS с 3600 лопнул, он использует около 1200 IOPS (так что даже не трещит сейчас) и тайм-ауты все еще происходят.
Тайм-аут подключения установлен на 5 секунд и 15 секунд, как указано выше, не показывает разницы.
Update 26/01/2016
RDS Скриншот из наших часы пик:
Update 28/01/2016
Я изменил настройки sync_bin_log - 0, потому что изначально я думал, что мы достигли пропускной способности EBS (GP-SSD 160 Мбит/с), это дает нам знак существенное снижение пропускной способности диска и IOPS также ниже, но мы по-прежнему видим, что время выхода в сеть происходит.
Когда мы строим время, в котором происходят ошибки, мы видим, что каждую минуту: 40 секунд тайм-ауты начинают происходить в течение примерно 25 секунд, а затем ошибки в течение примерно 35 секунд снова и снова начинаются. Это во время пикового часа нашего входящего трафика.
В примерах T2 используется кредитная модель. Как выглядит кредитный баланс, когда возникают таймауты? – datasage
Я улучшил форматирование на вопрос, так как я уже отметил баланс кредитного баланса ЦБ :-) ЦП Кредиты составляют около 500 и не уменьшаются. – Nick
В этом случае вам кажется, что вы нажимаете ограничения IOPS. SSD общего назначения имеет 3 IOP на каждый GB. Это включает в себя чтение и запись. Если вы не можете уменьшить свои IOP, вам может потребоваться переключиться на подготовленные IOPS – datasage