Мы вернули все изменённые значения к значениям по умолчанию и обновились до версии 2.6.0 beta4. Игры состоятся в четверг и пятницу, поэтому к концу недели у нас будет хорошее покрытие тестами.
К сожалению, исправление не решает проблему. У нас была умеренно активная игра с 600 сообщениями. Несколько зависаний были зафиксированы как в ходе моих собственных тестов, так и нашими участниками. Они коррелируют с игровыми событиями, то есть с пиками активности.
- Использование процессора было в пределах нормы: пик около 60%, средняя нагрузка — около 30%.
- Проблема точно на стороне клиента. Когда чат темы зависает, если перейти на главную страницу, вы увидите счётчик непрочитанных сообщений. Вернитесь обратно в тему, и сообщения станут видимыми.
Что меня всё ещё ставит в тупик и не освещается в этой теме, так это то, что изменилось с версии 2.3, в которой такой проблемы не было?
Крупные обновления 2.4 и 2.5 произошли в наш (продлённый из-за COVID) межсезонный период, поэтому никто ничего не заметил, но зависания проявились сразу же в самой первой предсезонной товарищеской игре.
Есть ли какие-либо параметры для хакерских настроек, которые мы могли бы попробовать уже завтра? Завтра будет жаркое дерби и выездной матч, так что сообщество будет в огне.
В нашем случае отключение плагина «Кто онлайн» и деактивация файла ограничения частоты запросов (я читал, что в более поздней бета-версии были внесены некоторые улучшения) помогли нам решить проблему.
Теперь у нас также проходят футбольные матчи, когда 300 или чуть больше пользователей одновременно кликают и пишут в одной теме, и во время последнего матча производительность заметно улучшилась.
Вы используете последнюю версию с недавним исправлением?
Пожалуйста, пожалуйста, обновите статус на «тесты пройдены». Я сильно доработал всё после бета-версии.
Да, последняя бета-версия (то есть обновлённая в течение последних 48 часов).
Обновлено. Отчет последует.
К сожалению, всё ещё не удалось. Конечно, игра была напряжённой с 950 сообщениями. Я следил за GAnalytics: около 250 человек наблюдали, 119 отправили сообщения. Как и раньше, наблюдались несколько зависаний. Шина сообщений вернула несколько ошибок 429 с сообщениями: «Вы выполнили это действие слишком много раз, пожалуйста, подождите X минут».
Нагрузка на ЦП достигла пика примерно 70%, при этом время ожидания (wa) было практически нулевым. Таким образом, несмотря на высокую активность, мы всё ещё не можем обеспечить то, на что способен аппаратный уровень.
Не могли бы вы ответить на один вопрос, который меня беспокоит: что было реализовано после версии 2.3, что вызывает это, и какую пользу это должно принести?
Реализация в целом осталась прежней, за исключением того, что теперь у нас есть глобальные лимиты скорости для приложений, которые можно настраивать. Вы можете их повысить, если хотите, хотя это может привести к полному сбою — не знаю точно.
Не совсем понимаю, что вы имеете в виду под «зависаниями». Если сейчас система слишком загружена, обновления могут прекратиться, но разница в том, что вам больше не нужно обновлять страницу в браузере, чтобы исправить ситуацию — она восстановится автоматически, как только сервер освободит ресурсы.
Здесь немного непонятно: ваши пользователи не замечают никаких улучшений после моих изменений?
На вашем сервере много свободной оперативной памяти? Если да, добавьте больше воркеров Unicorn.
Что у вас указано в параметре db_shared_buffers? В начале у нас наблюдалось много «нестабильного» поведения (некоторые темы «съедали» много ресурсов, особенно при активном участии) при использовании всего рекомендованных 25% от общего объема оперативной памяти. Когда мы увеличили этот параметр до 16 ГБ (из 32 ГБ), вся нестабильность исчезла… А совсем недавно, после последних изменений, ситуация стала ещё лучше.
Хорошо, это явление сложно отслеживать в производственной среде (чаты игр), поскольку каждая игра уникальна — разное количество критических событий, разные оппоненты, разный эмоциональный накал и так далее.
С нашей точки зрения проблема заключается в том, что наша максимальная пропускная способность снизилась по сравнению с версией 2.3. Это ключевой момент. У каждого сервера есть свои пределы, но сейчас мы получаем от него меньше, чем в марте, когда работала версия 2.3. Согласно приблизительным данным мониторинга бэкенда, сервер не может достичь 100% нагрузки или полной загрузки.
То, что видит конечный пользователь, — это просто остановка потока чата без какого-либо визуального индикатора того, что происходит. Это вызывает путаницу.
Я вполне уверен, что изменения, прошедшие тестирование, улучшили ситуацию, но производительность или максимальная отдача всё ещё значительно ниже, чем в версии 2.3.
У нас есть VPS с 6 быстрыми ядрами и 16 ГБ ОЗУ. Количество процессов Unicorn установлено на 12, настройки, связанные с буфером ОЗУ, оставлены по умолчанию.
Я считаю, что следующим лучшим шагом будет настройка исторического мониторинга вашей системы, чтобы мы могли определить, где находится узкое место, поскольку мы уже установили, что это не время процессора. Всегда возможно, что вы исчерпываете пропускную способность вашей сетевой подключения!
а также более традиционные метрики сервера, такие как node-exporter.
Если это так и вы хотите увеличить нагрузку:
-
Вы можете уменьшить лимиты запросов. Это позволит пользователям более агрессивно взаимодействовать с Discourse. В частности, вы можете удвоить значения
DISCOURSE_MAX_REQS_PER_IP_PER_MINUTEиDISCOURSE_MAX_REQS_PER_IP_PER_10_SECONDS. -
Вы можете попробовать добавить больше рабочих процессов Unicorn.
Это ожидаемое поведение временно, пока вы находитесь под высокой нагрузкой, но система должна автоматически восстановиться, как только нагрузка снизится.
Мое предположение: всё это связано с лимитами запросов. Лимиты являются новой функцией и предназначены для защиты сервера. Похоже, ваш сервер защищён именно по этой причине.
Мы попробовали игру с…
DISCOURSE_REJECT_MESSAGE_BUS_QUEUE_SECONDS: 0.3
DISCOURSE_MAX_REQS_PER_IP_MODE: none…и когда на третий период эмоции начали накаляться, ситуация ухудшилась. Мы достигли пределов наших серверов: пользователей постоянно выкидывало в режим выхода из системы, а чат игры тоже зависал.
Это была история успеха на протяжении четырёх лет, но сейчас мы оказались в очень сложной ситуации. Переход на следующий уровень мощности VPS перевёл бы нас в ценовую категорию около 160 евро в месяц, что является серьёзным вызовом для любительского сайта. И речь идёт не о огромных объёмах пользователей — всего 116 человек опубликовали более 800 сообщений во время игры.
Идеология «не создавайте чаты» тоже не подходит. Если бы их не было, эмоциональные реакции рассеивались бы по более «серьёзным» темам. Чаты — важный инструмент для концентрации эмоционального заряда живой ситуации в одной теме, сохраняя при этом аналитические темы чистыми.
У меня форум о футболе, и я столкнулся с похожими проблемами.
В целом, я обнаружил, что это вопрос масштабируемости.
Проблемы возникали у меня на разных уровнях.
Digital Ocean:
1 CPU, 1 ГБ = 30–40 пользователей в режиме чата;
2 CPU, 2 ГБ = 70–80 пользователей в режиме чата;
4 CPU, 8 ГБ = подходит для 120 пользователей и 1000 постов за 2 часа. Лимит не был достигнут.
Я пробую разные уровни масштабирования на Hetzner (зеркальный сайт), так как это дешевле, но всё идёт не так гладко, как я надеялся.
Мой опыт пока таков:
3 CPU (чип AMD CPX 21) и 4 ГБ = трудности с 20 пользователями;
2 CPU (Intel) и 8 ГБ = проблем с 20 пользователями нет.
Собираюсь протестировать систему с 80–100 одновременными пользователями в условиях матча.
Когда я смотрел на использование CPU на Digital Ocean, даже под нагрузкой использование CPU казалось довольно низким — менее 50% во всех случаях и на всех тарифах.
Когда я проверял CPU на Hetzner с чипом AMD, наблюдалась медианная загрузка около 60%, но каждую минуту или около того происходил кратковременный скачок до 300% использования CPU. С чипом Intel таких скачков не наблюдалось.
Что это означает, я не знаю. Подозреваю, что мониторинг CPU на Hetzner работает лучше (фиксирует кратковременные скачки). Но в целом использование CPU выглядит сбалансированным. На первый взгляд Digital Ocean справляется со скачками лучше, но после этого уик-энда у меня будет больше информации по Hetzner.
Я также должен добавить, что при тестировании на Hetzner плагин «whose online» не оказал никакого влияния.
Однако плагин быстрых сообщений Discourse, похоже, оказался вредным.
Следующая игра должна состояться завтра. Мы убрали собственные хаки и теперь пробуем эти настройки.
Также, как отчаянная попытка, я увеличил db_shared_buffers с 4 ГБ (25%) до 6 ГБ (37,5%). Кроме того, я раскомментировал строку db_work_mem 40 МБ из файла app.yml (кстати, это очень слабо документированная опция, хотя и представлена администраторам как возможность для улучшения).
Я больше не жду найти решение проблемы, а лишь надеюсь на лучший контроль ущерба — набор параметров, который минимизирует негативное влияние на пользовательский опыт. Тем временем мне предстоит изучить возможности дальнейшего увеличения наших хостинг-ресурсов.
Вопрос к @sam и другим разработчикам.
Как постоянно растущий размер базы данных влияет на этот сценарий использования, когда пользователи в течение нескольких часов активно обсуждают одну тему?
Я изучил историю активности игровых чатов и заметил, что ещё в 2017 году были игры с огромной статистикой, хотя наш сервер имел лишь долю ресурсов по сравнению с тем, что у нас есть сегодня. Были игры, где количество сообщений достигало 1600 от 165 пользователей, и никто не жаловался на производительность. Сейчас же мы не можем обслуживать даже половину такого объёма, несмотря на значительно более мощный сервер.
Попробуйте увеличить её до 80 МБ. Возможно, вместо другого изменения.
Это один из пунктов, над которым мы постоянно активно работаем.
Когда Discourse только появился, почти все сайты имели совершенно новые базы данных, поэтому они легко помещались в оперативную память. Теперь, спустя несколько лет, у некоторых сайтов базы данных превышают 100 ГБ, а объём оперативной памяти даже не достигает десятой части этого размера.
Одно из предстоящих обновлений в ближайшие недели — это переход на PostgreSQL 13, который позволит уменьшить максимальный размер объекта вдвое.
Помимо этого, первым шагом в диагностике проблем с производительностью является сбор данных с помощью плагина экспортера Prometheus для Discourse, чтобы мы не действовали вслепую.