Проблема: чрезвычайно медленная обработка Sidekiq после крупных импортов на мультисайтовом экземпляре

Поддержка
1

Мы запускаем несколько сайтов Discourse с поддержкой мультисайтовости в рамках одного приложения. Недавно мы выполнили пакетный импорт большого количества пользователей (сотни тысяч пользователей на 6 сайтах). После импорта Sidekiq обрабатывает фоновые задачи очень медленно. Панель управления Sidekiq показывает огромный backlog, и задачи очищаются гораздо медленнее, чем ожидалось.

Детали окружения:

  • Виртуальная машина была обновлена до 16 ядер CPU / 16 ГБ RAM.
  • Однако в интерфейсе Sidekiq мы видим только 5 потоков, и кажется, что используется лишь небольшая часть доступных ресурсов.
  • Основная очередь импорта («nursingjobs» как родитель мультисайта) обрабатывает задачи для всех дочерних сайтов, но пропускная способность задач очень низкая.
  • Метрики сервера: загрузка CPU иногда достигает 80–90%, использование памяти — около 6,7/7,2 ГБ.

Наша цель:

  • Ускорить обработку Sidekiq/фоновых задач для быстрого устранения больших backlog после импорта.
  • Обеспечить, чтобы Discourse использовал все доступные ресурсы (CPU/RAM).
  • Понять, есть ли ограничения на количество потоков или процессов, которые нужно скорректировать.

Вопросы:

  1. Как лучше всего настроить Sidekiq/Discourse для высокой пропускной способности после импорта?
  2. Какие рекомендуемые настройки для UNICORN_SIDEKIQS и DISCOURSE_SIDEKIQ_WORKERS на системах с большим количеством ядер?
  3. Есть ли настройки Postgres или другие параметры app.yml, которые стоит изменить, чтобы избежать ошибок пула БД при увеличении параллелизма Sidekiq?
  4. Какие существуют лучшие практики для быстрого и безопасного устранения огромных backlog Sidekiq после импорта?

На изображении показана панель управления Sidekick.io с количеством процессов, неудачными экземплярами, задержкой и тремя задачами в очереди, каждая из которых имеет опции удаления. (Подпись сгенерирована ИИ)
На изображении показана панель управления Sidekick.io с количеством процессов, неудачными экземплярами, задержкой и тремя задачами в очереди, каждая из которых имеет опции удаления. (Подпись сгенерирована ИИ)1920×590 139 KB

Статистика Sidekiq/скриншоты доступны, если это потребуется!

3

Ответ на все эти вопросы — более или менее — увеличить значение DISCOURSE_SIDEKIQ_WORKERS.

Я бы поднял его примерно до 32, так как у вас, как вы знаете, много свободных ресурсов CPU. Если после того, как система поработает какое-то время, у вас всё ещё останется много свободных ресурсов CPU, не стесняйтесь увеличить это значение ещё больше.

Для обычной работы, вероятно, можно будет снизить его, скажем, до 8 или 12.

Убедитесь, что у вас достаточно max_connections для PostgreSQL. Вы, скорее всего, уже увеличили это значение, так как работаете в режиме мультисайта, но следите за этим показателем.

4

Спасибо @supermathie, теперь всё работает.
Я обновил конфигурацию следующим образом:

  UNICORN_WORKERS: 8
  UNICORN_SIDEKIQS: 7
  DISCOURSE_SIDEKIQ_WORKERS: 10
  DISCOURSE_DB_POOL: 20

А также увеличил количество процессоров до:

8 vCPU
16 ГБ памяти