Пулы соединений Sidekiq, Redis и Postgresql. Как должны выглядеть мои настройки с учетом моего сценария? - PullRequest
Новая
       62

Пулы соединений Sidekiq, Redis и Postgresql. Как должны выглядеть мои настройки с учетом моего сценария?

0 голосов
/ 17 июня 2020

В течение некоторого времени я получал ошибки connection pool timeout и 2020-06-17T16:15:33.701Z pid=1132347 tid=goeqpzc8b WARN: PG::ConnectionBad: FATAL: sorry, too many clients already при использовании рабочих sidekiq и postgres. Я попытался понять, как все это просто работает, но просто не могу избавиться от этих ошибок, независимо от того, на что я настраиваю свои настройки.

Прямо сейчас мой config/database.yml файл использует эти настройки в качестве своих параметров : 

default: &default
  adapter: postgresql
  encoding: unicode
  pool: 20
  port: 25060

В моем файле config/sidekiq.yml также установлены следующие параметры: 

development:
  :concurrency: 20
production:
  :concurrency: 20
:queues:
  - default

и в соответствии с настройками моей базы данных из Digital Ocean у меня есть подключение к внутреннему серверу. предел 22.

С учетом сказанного, почему задания sidekiq завершаются сбоем, вместо того, чтобы просто стоять в очереди и ждать выполнения? В каждом из моих работников sidekiq есть код для записей CRUD в ActiveRecord, но я не уверен, насколько это важно для фактических работников sidekiq.

Насколько я понимаю, мой лимит с управляемой базой данных составляет 22 подключений вверху, но мои настройки в файлах database.yml и sidekiq.yml ниже предела, поэтому я не уверен, как и почему он все еще не работает, а не просто остается в очереди, пока не останется место.

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

Я ищу любые предложения или разъяснения по этому поводу.

1 Ответ

1 голос
/ 18 июня 2020

PG :: ConnectionBad: FATAL: извините, уже слишком много клиентов

Разрыв между 20 и 22 не дает вам большого запаса прочности. Например, открытие pgAdmin4 и запуск некоторого контрольного соединения (оба обхода пула соединений) могут привести к превышению лимита, если пул пытается полностью использоваться. Если вы не можете увеличить max_connections, попробуйте уменьшить размер пула на пару, чтобы повысить безопасность. Это может усугубить другую проблему, но переход от 2 проблем к 1 - это своего рода прогресс. run?

Я не пользователь sidekiq, но, видимо, они готовы ждать так долго, и этот период превышен. Или, по крайней мере, «тайм-аут пула соединений» не является сообщением, сгенерированным PostgreSQL, поэтому оно приходит откуда-то еще; и, судя по формулировке, очевидным кандидатом является менеджер пула.

...