Оптимизация крупного многосайтового проекта: узкие места в базе данных и Sidekiq

Поддержка Самостоятельное хостинг
,
1

Мне нужна экспертная помощь по оптимизации настройки мульти-сайта Discourse. У меня есть один веб-сервер (VM) и отдельный сервер базы данных (VM) у крупного облачного провайдера. Хотя оба сервера имеют хорошие характеристики, моя система перегружается большим объемом фоновых задач, что, похоже, создает чрезмерную нагрузку на базу данных.

Моя текущая конфигурация в app.yml следующая:

  • UNICORN_WORKERS: 4
  • UNICORN_SIDEKIQS: 4
  • DISCOURSE_SIDEKIQ_WORKERS: 10
  • DISCOURSE_DB_POOL: 8

Судя по моим наблюдениям, проблема не в достижении жесткого лимита соединений, а в огромном количестве задач, одновременно конкурирующих за ресурсы базы данных. Очереди в Sidekiq постоянно заполняются, из-за чего сайт ощущается медленным, даже при выполнении базовых административных задач.

Мне нужен общий подход к настройке системы для обеспечения стабильности и производительности. В частности, я хотел бы понять лучшие практики по следующим вопросам:

  • Конкурентность Sidekiq: Как следует настраивать параметр DISCOURSE_SIDEKIQ_WORKERS в среде мульти-сайта для обработки большого объема задач без перегрузки базы данных?
  • Разделение очередей: Рекомендуется ли запускать отдельные процессы Sidekiq для обработки разных очередей (например, critical против low приоритета)? Это позволило бы гарантировать, что тяжелые задачи не будут блокировать более срочные.

На данный момент я не ищу решения, требующих серьезных изменений в архитектуре или перехода на другой веб-сервер, так как хочу сохранить процесс максимально простым и безопасным. Надеюсь получить советы по безопасному и эффективному пути развития.

Спасибо!

2

Discourse должен быть способен адаптировать эти параметры в зависимости от ресурсов вашей системы. Обратите внимание, что безопасно повторно запустить скрипт ./discourse-setup, если вы недавно увеличили ресурсы системы. Скрипт может адаптироваться к увеличенным ресурсам и соответствующим образом изменить ваш файл .yml.

3

Похоже, вам нужно их меньше?

Я почти уверен, что система уже умеет расставлять приоритеты для задач с высоким приоритетом.

4

@itsbhanusharma @pfaffman Спасибо за вашу помощь. Я ценю, что вы оба нашли время поделиться своими знаниями.

5

Если база данных является узким местом, рассматривали ли вы возможность перехода на более крупный тип экземпляра для вашей облачной базы данных?