Переезд из Slack в Mattermost (2)
Часть 1: https://levaminov.ru/z3TpTpYSK4J
Часть 3: https://levaminov.ru/JsEwp91lmC-
К нашей инсталляции Mattermost в пике подключено около 350 устройств – не так много, как в истории с мессенджером в Тинькофф, но проблемы бывают и у маленьких инсталляций. Спойлер: наша проблема так и не решена.
По мере переезда пользователей из Slack мы столкнулись с тем, что в часы пик число коннектов к базе упирается в лимит, ресурсов не хватает, рестарт сервера Mattermost не спасает, лечится только полной остановкой кластера. Да и это могло помочь как на неделю, так и на день, никакой связи с числом подключенных устройств нет.
В какой-то момент метод получения числа файлов закрепленных за конкретным чатом начинает возвращать таймауты, затем появляются ошибки подключения к базе – too many connections. Возникает вопрос – а где проблема – в базе или в самом приложении?
Время шло, мы занимались очередными переездами, но ситуация с Mattermost надоела окончательно и мы решили перенести базу с конфигурации 4 vCPU/16 GB на 8 vCPU/32 GB.
В итоге дошло до того, что проблемы начали появляться с началом дня и заканчиваться только поздней ночью, а число рестартов начинало напрягать – даунтайм Mattermost был 15-20 секунд, а после 10-15 минут проблема могла возвращалась и так весь день. Для пользователей это проявлялось в следующем:
- долго загружаются каналы и треды;
- при отправке сообщения оно дублируется, либо не сохраняется;
- при запуске приложения отображаются не все каналы;
- ну и наконец – даунтайм отключал от общения всех.
Еще с начала тестовой установки Mattermost мы писал все логи, в том числе SQL, все это анализировалось в режиме реального времени:
Благодаря этому мы всегда видели как система себя ведет в общем, как реагирует на какие-то изменения. На графиках мы заметили, что проблемы с нагрузкой всегда начинаются с ошибок:
Unable to get the file count for the channel
В часы пик хост mySQL, за который мы платим 25000 руб. в месяц, был загружен на 98% – выглядит сомнительно, поэтому мы продолжили капать дальше, метод GetChannelFileCount вызывается только в getChannelStats – статистика по каналу, содержит в себе:
В какой-то момент у меня возникла мысль, что у нас нет какого-то индекса на таблице Files, но это предположение не оправдалось – свежая инсталляция содержит все то же описание таблиц... ну окей.
Метод getChannelStats использует только в API:
GET /api/v4/channels/.+/stats
В качестве эксперимента отдаем по этому пути 204:
nginx.ingress.kubernetes.io/configuration-snippet: |
location ~ /api/v4/channels/.+/stats {
return 204;
}В итоге нагрузка на хост базы резко сократилась:
В конце 11 ноября мы перекрыли этот и еще один роут (на графике он значился как GetTopChannelsForUserSince), график по ошибкам стал таким:
Высокие столбцы – это те самые моменты, в которые мы рестартовали кластер Mattermost. Вроде, стало хорошо. Почему я написал, что проблема не решена? Нууу... теперь в шапке канала пользователи видят следующее:
Так как метод ничего не возвращает, в интерфейсе тоже ничего не отображается, что может запутать наших пользователей, поэтому сейчас мы думаем (в свободное от работы время) над тем, как решить и эту проблему.
UPDATE: Я писал в Тинькофф с вопросами по распространению их переработанной версии (бесплатно или за деньги), мне ответили, что точного решения нет, как и сроков. Так что, на месте тех, кто готовится к переезду со Slack, я бы не расчитывал на их решение и не ждал его в ближайшем будущем.
P.S. Мы предлагаем свою аналитику по логам, как на графиках выше – https://anomaly1.ru.
P.P.S. Да и вообще можем по графикам проконсультировать или настроить что-нибудь – https://arendamozgov.ru.