Значит, все утверждения о том, что UNICORN WORKER должен составлять 2*vCPU, неверны?
Мой сервер: Intel Xeon E5-2686 v4 @ 2.30 ГГц — 24 vCPU + 32 ГБ ОЗУ.
Сколько UNICORN WORKER мне нужно настроить?
8 или 48?
На моём сайте более 7 тыс. пользователей, из которых около 1 тыс. активно участвуют ежедневно. Пользователи создают от 3 до 7 тыс. постов в день. Наше сообщество генерирует от 120 до 200 тыс. просмотров страниц в сутки, включая поисковых роботов и анонимных пользователей.
Это зависит от множества факторов. Например, от соотношения размера вашей базы данных и оперативной памяти, от соотношения трафика авторизованных пользователей и анонимного трафика, от наличия плагинов, которые нагружают очередь Sidekiq, от того, используете ли вы YJIT и так далее.
Простой способ — посмотреть данные MiniProfiler в час пик, просмотреть форум и оценить, ухудшилась ли производительность, чтобы выявить узкое место.
Поскольку этот процессор устаревший, я бы начал с количества воркеров Unicorn, превышающего обычное, так как каждый запрос будет выполняться дольше обычного. Однако, если PostgreSQL и Redis работают на одном сервере, нельзя перегружать их, запуская слишком много воркеров.
Попробуйте начать с 16 воркеров и оцените производительность сайта.
Можно ли дать простое и понятное описание того, чем занимаются воркеры Unicorn? Создается впечатление, что каждый запрос страницы от пользователя должен быть обработан воркером Unicorn. Если их недостаточно, пользователю приходится ждать. Если же их слишком много… ну, возможно, это немного увеличивает потребление оперативной памяти?
Это веб-серверы приложения.
Похоже, вашему 10-летнему процессору пора на пенсию. Увеличение количества рабочих процессов Unicorn позволит обслуживать больше пользователей одновременно, но не ускорит обработку отдельных запросов.
Попробуйте включить YJIT?
С вашим оборудованием я ожидал бы среднее время отклика для списка последних тем в состоянии входа около 150 мс на уровне приложения и 80 мс на уровне SQL.
Начните с 12 рабочих процессов и посмотрите, как система будет работать. Лучшее, что можно сделать, — отслеживать метрики: если хотите узнать, стоит ли добавлять больше рабочих процессов, проверьте, не выстраиваются ли запросы в очередь в ожидании рабочих процессов приложения.
Отслеживаете ли вы метрики, которые сам Discourse экспортирует через экспортер Prometheus? Они дадут вам хорошее представление об общей производительности экземпляра.
Как выглядят показатели производительности для анонимных и обычных (не администраторов) пользователей?
(/перестаю смеяться, захожу в панель хостинга … )
Вау, это разве не включено по умолчанию?
edit: ах да, конечно, вы могли собрать с помощью старого app.yml и не обновляли его с тех пор
У нас на хостинге это есть, но сделать это стандартным довольно сложно, так как пользователи могут работать в условиях ограниченного объема оперативной памяти…
Тем не менее, наш сборщик JS потребляет намного больше оперативной памяти, чем сам Discourse, так что можно сказать, что любой, кто может собрать JS-активы, имеет достаточно свободной оперативной памяти 
На этих скриншотах, сколько воркеров у вас настроено?
Я бы посоветовал:
- Немного увеличить количество воркеров, так как у вас наблюдается небольшая очередь.
- Включить YJIT, так как время отклика вашего веб-сервера довольно велико.
Теперь у вас всего 8 воркеров, и YJIT уже включен.
Сколько воркеров нужно добавить?
Кстати, вот на что опирался Falco, давая эту рекомендацию:
Я бы увеличил количество с 8 до 12. Это даст вам запас прочности и должно помочь очистить очереди.
Кстати, этот большой пик указывает на то, что другие запросы ожидают… что-то, вероятно, общую блокировку. Возможно, это связано с мега-темой.
Если вы сможете получить также метрики использования PostgreSQL, это было бы полезно.
Мега-темы являются слабым местом. См. Improving Instance Performance (Megatopics, Database Size and Extreme Load)
Подумайте о том, чтобы разбить их или использовать вместо этого чат (я вижу, что ваша самая большая тема с 8,9 тыс. ответов явно является комнатой чата).
Культура обсуждений в нашем сообществе — это мега-темы, которые сформировались ещё до того, как мы начали использовать Discourse, а в чате отсутствуют такие функции, как размытые спойлеры и скрытые детали.
Как это сделать
Мы используем GitHub - prometheus-community/postgres_exporter: A PostgreSQL metric exporter for Prometheus · GitHub, хотя не уверен, есть ли в Meta какие-либо руководства по его настройке.
Но, учитывая, что у вас уже настроен Prometheus, похоже, вы разбираетесь в этом.
В настоящее время оперативная память сервера составляет 16/32 ГБ, количество воркеров UNICORN_WORKERS: 12, параметр db_shared_buffers: “4096MB”.
Поскольку свободная оперативная память ещё доступна, а несколько веб-запросов находятся в очереди, я увеличил количество воркеров UNICORN_WORKERS до 24. Сегодня во второй половине дня сервер внезапно отключился, а после его перезапуска пользователи начали массово заходить. Это привело к очень низкому количеству активных веб-запросов и большому числу запросов в очереди. Несколько дней назад мы наблюдали, что 24 воркера UNICORN_WORKERS могли обрабатывать более 150 активных веб-запросов, но сегодня во второй половине дня их было только 30. Это связано с тем, что мы недавно сменили домен, и множество постов перерабатываются через Sidekiq. Это создало значительную нагрузку на сервер. Что нам делать?
