Около двух недель назад я развернул некоторые изменения в своем приложении (Flask + SQLAlchemy поверх Postgres) в Heroku. Вскоре после этого время отклика моих динамовцев увеличилось, и время ожидания ответов началось. До начала этих проблем текущая версия приложения работала без сбоев в течение 2-3 месяцев.
Естественно, я подозревал свои изменения в приложении и просматривал их, но они не имели к этому никакого отношения (изменения в интерфейсе, замена текстовых электронных писем на HTML, незначительные изменения в статических данных, которые использует приложение ).
У меня есть копия приложения для тестирования, поэтому я клонировал последнюю резервную копию рабочей БД и начал расследование (клон был около 45 ГБ, по сравнению с 56 ГБ оригинала, но это, кажется, нормальное следствие "раздувание").
Оказывается, что даже тривиальные запросы занимают на производстве смехотворное время, в то время как они работают над тестированием так, как должны. Например, select * from A where some_id in (three, int, values) занимает менее 0,5 с при тестировании и около 12-15 с на продукт (A имеет 3M записей, а some_id - это внешний ключ для таблицы намного меньшего размера). Даже select count(*) from A займет столько же времени, так что это не индексация или что-то в этом роде.
Это не связано с конкретным запросом или даже таблицей, что устраняет мои сомнения в моем коде, так как большая часть его не изменялась месяцами и работала нормально, пока эти проблемы не начались.
Заглядывая дальше, я обнаружил, что журналы содержат средние значения нагрузки для сервера БД, а мой рабочий показывает load-avg 22 (я искал postgres load-avg в Papertrail), и он кажется почти постоянным ( медленно растет в течение длительных периодов времени).
Я обновил производственную базу данных с плана Postgres 9.6 / Standard 2 (хотя число моих подключений было около 105/400 и частота попаданий в кэш 100%) до плана Postgres 10 / Standard 3, но это не помогло малейшее улучшение. Это обновление также означало 30-60 минут простоя. Вскоре после восстановления приложения нагрузка на сервер БД была высокой (к сожалению, я не проверял во время простоя). Кроме того, похоже, что загрузка сервера БД не имеет пиков, которые отражали бы использование приложения (приложение в основном используется в США и ЕС, и загрузка обычного приложения отражает это).
На данный момент у меня нет идей (кроме обращения в службу поддержки Heroku, что сделает мой коллега), и буду признателен за любые предложения, что посмотреть или попробовать дальше.