Настройки knexfile при использовании PgBouncer
У нас есть настройка, при которой несколько процессов Node записывают в одну и ту же базу данных (разные таблицы), и в результате при использовании Knex мы получаем больше подключений к базе данных, чем хотелось бы. Итак, я думал об использовании PgBouncer в качестве промежуточного программного обеспечения для подключения процессов Knex, но я не уверен, как попытки Knex создать пул соединений будут работать с PgBouncer, который настроит свой собственный пул соединений.
Пожалуйста, предположим следующее:
- Сервер базы данных 2vCPU
- 10+ Node-процессов, взаимодействующих с базой данных
- PgBouncer работает с размером пула 5
Вопросы:
- Если я установлю минимальный/максимальный размер как 1/5 в каждой настройке Knex, закончатся ли соединения или PgBouncer каким-то образом сможет «обмануть» каждую настройку Knex, заставив ее поверить, что у нее есть собственный пул?
- Не похоже, что я могу использовать пул Knex в этом сценарии. Даже использование минимальных и максимальных размеров пула в качестве 1/1 оставит меня без вариантов, если первые пять запускаемых мной шагов Knex будут запрашивать соединение каждый.
- Есть ли способ заставить Knex отказаться от пула и открывать/закрывать соединения по мере необходимости? Это идеальная установка для меня, потому что теперь PgBouncer на самом деле не будет открывать/закрывать соединения, а будет возвращать их в пул (если я не ошибаюсь?).
Какую стратегию мне следует использовать? Как должен выглядеть мой knexfile? И нужно ли мне кодировать по-другому для этого? Любая помощь или идеи приветствуются!
@jjanes Это 10 разных систем, интегрируемых с 10 различными API, поэтому они выполняются по-разному, поскольку ими нужно управлять индивидуально. Что касается настройки, больший размер пула на самом деле означает худшую производительность. Вот пища для размышлений: github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing
Похоже, что я могу сделать следующее: использовать функцию для создания экземпляра Knex каждый раз, когда я хочу запустить запрос к БД, и убедиться, что есть блок finally, выполняющий knex.destroy() после завершения выполнения кода, связанного с БД ( контекст: stackoverflow.com/questions/57813600/…). Хотя это выглядит ужасной общей практикой, при использовании PgBouncer имеет смысл, что на самом деле никакие соединения не создаются и не уничтожаются. Я также намерен сохранить настройки пула как минимум: 1, максимум: 1 для большинства моих приложений Node. Увидим, как пойдет.
Ответы 1
Хотя было бы нелепо разрешать 32000 подключений, также нелепо разрешать только 5. Я думаю, что урок из вашей ссылки должен состоять не в том, что существует точно определенное магическое количество подключений, а в том, что вам нужно смотреть на события ожидания работающую базу данных или просто поэкспериментируйте, чтобы увидеть, что происходит и не слишком ли много у вас подключений.
Хотя повторное подключение к pgbouncer (который повторно использует свое внутреннее подключение к PostgreSQL) может быть менее затратным, чем повторное полное подключение к PostgreSQL, оно все же будет намного дороже, чем простое повторное использование существующего подключения из внутреннего пула подключений knex. Если нагрузка на ваше соединение достаточно высока, чтобы иметь значение, то обход внутреннего пула соединений и просто использование pgbouncer было бы ошибкой. Скорее всего, использование pgbouncer вообще является ошибкой, так как он просто вводит еще один движущийся элемент без уважительной причины.
Использование knex pooler с min:1 и max:5 с 10 различными серверами приложений knex и ограничением в 5 подключений в pgbouncer означает, что только 5 ваших серверов приложений могут иметь подключение. Остальные будут вынуждены ждать, но непонятно, чего они будут ждать. Предположительно, они будут ждать вечно, или пока не обнаружат ошибку тайм-аута, или пока один из других серверов приложений не выйдет или не выключит свой пул. Pgbouncer мог бы обмануть их, но не в лучшую сторону. Возможно, имеет смысл использовать это значение min:0 (теперь это рекомендуемый параметр, но все же не значение по умолчанию), так как таким образом сервер приложений, по крайней мере, освободит свое последнее соединение после idleTimeoutMillis, позволяя другому приложению использовать его.
Использование min:1 max:1 могло бы быть полезным, если бы pgbouncer не использовался или использовался с достаточно большим размером пула, но он также мог полностью сломаться. Например, если приложению для корректной работы требуется как минимум 2 одновременных подключения. Вероятно, это было бы плохо написанное приложение, но плохо написанные приложения — правило, а не исключение.
Я принимаю ваш ответ с точки зрения взаимодействия knex и pgbouncer, но я не уверен в количестве подключений. Основное, что следует из ссылки, которой я поделился, заключается не в том, что я должен изучать буферы ожидания, а в том, что как только у нас будет больше процессов, чем количество ядер ЦП, мы получим общий удар по управлению этими входящими фрагментами данных. работа. Мне это кажется здравым смыслом, хотя я буду рад исправиться в свое время. На четырехъядерных машинах я не думаю, что более 10-15 подключений имеют смысл. В любом случае, спасибо за ваш вклад, правда! :-)
Зачем ты вообще все это делаешь? Зачем 10 узловых процессов, когда узел уже является многопоточным? (Я думаю, что в любом случае, я сам не пользователь узла) Почему разрешено только 5 подключений к PostgreSQL? Это 1/20 значения по умолчанию max_connections, и это значение по умолчанию уже предназначено для небольших систем.