Примерно с 14 до 14:30 пользователи проекта дали фидбек, что выкинуло из веб приложения и при повторной авторизации не получалось авторизоваться
Через пол часа проблема решилась сама собой. Сегодня и в этот период не было никаких обновлений деплоя.
Подскажите пожалуйста что это может быть и почему такая проблема могла появится, как избежать ее в будущем?
Ошибки в логах в это время
Деплой
Судя по графикам приложение уперлось в лимит CPU и RAM, выделенных для вашего приложения. Мы проверим со своей стороны не было ли повышенной нагрузки на наших серверах.
Судя по чарту - приложение приблизилось к лимиту памяти и в какой-то момент начало зависать. Мы такое поведение уже видели несколько раз, docker не убивает приложение пока оно не упрется и не запросит память выше предела.
Мы со своей стороны проверим как можно это поведение автоматически отловить и перезапускать приложение если такое случалось, а вы со своей стороны дайте пожалуйста больше информации если у вас есть выполнение планировщика или какие-то экстра большие запросы (загрузка/выгрузка файлов, импорт прайс листов и т.п.) что могло бы происходить в момент когда приложение потребляет 100% памяти. Судя по графику оно работало идеально и в какой-то момент просто съело всю память.
В этот раз (когда приложение приблизилось к лимиту) у меня выполнялся планировщик, который считает метрики у каждого руководителя и отправляет их в телеграм.
Но что странно, это то, что такой планировщик выполняется каждый день в одно и то же время и не было подобной проблемы ни разу ни до, ни после этого кейса. Даже после перезапуска деплоя в тот день я просто через свагер повторно запустил БП и он корректно отработал.
А как много сообщений отправляется? Метрики считаются блоками или сырым SQL? Есть ли глобальные переменные с большими данными?
Со своей стороны тестируем уже улучшение, но все равно нужно понять что может вызывать такое поведение.
Немного, по 3 сообщения в 15 чатов телеграм в течение 17 минут равномерно (то есть с паузами), всего 45 сообщений (сделано так с блоками delay специально, чтобы не перенагружать запросами)
Метрики считаются и и блоками и sql
Глобальных переменных нет
Мы раскатываем обновление для управления памятью. Должно минимизировать такие случае за счет более агрессивного освобождения памяти. Если вдруг вам удастся найти точный кейс - мы сможем запустить в режиме отладки и изучить почему происходит избыточное потребление памяти.
