November 14

Переезд из Slack в Mattermost (2)

К нашей инсталляции 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 – статистика по каналу, содержит в себе:

  • GetChannelMemberCount
  • GetChannelGuestCount
  • GetChannelPinnedPostCount
  • GetChannelFileCount

В какой-то момент у меня возникла мысль, что у нас нет какого-то индекса на таблице 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.