Наша база данных работала 16 ГБ оперативной памяти, 4 vcpu и 60 ГБ диска (машина m4.xlarge aws rds) 3 месяца назад, и она работала нормально, пока из одного момента в другой она не начала растиглубина очереди вместе с задержкой чтения и записи.В этом случае мы перезагрузили и обновили нашу базу данных до 32 ГБ оперативной памяти, 8 vcpu (экземпляр m4.2xlarge), и проблема исчезла.
Конечно, это не устойчиво во времени, но мы не смогли найти точную причину.Мы знаем, что наш трафик, а следовательно, и операции с базами данных, увеличиваются, но точно не дублируются по размеру.
Дело в том, что через 3 месяца сегодня снова возникла проблема с 32 ГБ 8 vcpu, иопять же, как кнопка паники, мы обновили до 64 ГБ 16 vcpu.И мы также дублировали размер диска до 120 ГБ, чтобы быть уверенными.В момент происшествия трафик не увеличился внезапно, и, кроме того, я могу гарантировать, что трафик не будет в два раза тяжелее, чем 3 месяца назад.Однако за эти 3 месяца мы проанализировали медленный журнал запросов и улучшили некоторые запросы, добавив некоторые индексы.
Теперь у нас есть (соответствующие таблицы) эти таблицы и индексы
Мы не являемся экспертами по базам данных, но это не похоже на то, что трафик слишком велик для наших баз данных (мы запускаем приложение электронной коммерции ruby on rails).Мы понимаем, что объем «свободной памяти» всегда был больше 20 ГБ, диска - более 15 ГБ.Но мы также не знаем, почему он использовал 100 МБ подкачки, если оперативная память была свободна.
Вот графики мониторинга за последние 6 часов, в середине - инцидент, затем масштаб вокруг18: 15.
