Как я могу определить, каковы должны быть ограничения подключения моей базы данных? - PullRequest
3 голосов
/ 19 января 2011

В моей организации базы данных PostgreSQL создаются с ограничением в 20 соединений в соответствии с политикой. Это имеет тенденцию плохо взаимодействовать, когда в игре находятся несколько приложений, использующих пулы соединений, поскольку многие из них открывают свой полный набор соединений и удерживают их в режиме ожидания.

Как только более двух приложений связываются с БД, у нас заканчиваются соединения, как и следовало ожидать.

Поведение в пуле - это новая вещь здесь; до сих пор мы управляли пулированными соединениями, сериализуя доступ к ним через сетевой шлюз БД (?!) или вообще ничего не объединяя Как следствие, мне приходится снова и снова объяснять (буквально 5 билетов на проблемы от одного человека в ходе проекта), как работает объединение в пул.

То, что я хочу, это одно из следующих:

  1. Твердое, неоспоримое обоснование для увеличения количества доступных соединений с базой данных, чтобы хорошо играть с пулами.
    Если так, то каков безопасный предел? Есть ли какая-либо причина для ограничения 20?

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

Для чего стоит, вот компоненты в игре. Если уместно, как настроен один из них, пожалуйста, взвесьте:

БД: PostgreSQL 8.2. Нет, мы не будем обновлять его как часть этого.
Веб-сервер: Python 2.7, Pylons 1.0, SQLAlchemy 0.6.5, psycopg2

  • Это осложняется тем фактом, что некоторые аспекты системы обращаются к данным с помощью SQLAlchemy ORM с помощью настроенного вручную механизма, в то время как другие обращаются к данным с помощью другой фабрики обработчиков (Still sqlalchemy), написанной одним из моих партнеров, который упаковывает соединение в объект, который соответствует старому PHP API.

Задача: Python 2.7, сельдерей 2.1.4, SQLAlchemy 0.6.5, psycopg2

1 Ответ

2 голосов
/ 19 января 2011

Я думаю, что разумно требовать одно соединение на одно действие одновременно, и разумно предположить, что одновременные HTTP-запросы выполняются одновременно.

Теперь количество одновременных HTTP-запросов, которые вы хотите обработать, должно масштабироваться с: а) нагрузкой на ваш сервер и б) количеством доступных процессоров. Если все пойдет хорошо, каждый запрос будет занимать какое-то время процессора (на веб-сервере, на сервере приложений или на сервере базы данных), что означает, что вы не можете обрабатывать больше запросов одновременно, чем у вас есть процессоры. На практике это не так, что все идет хорошо: некоторые запросы в какой-то момент будут ожидать ввода-вывода и не будут загружать процессор. Так что нормально обрабатывать больше запросов одновременно, чем у вас.

Тем не менее, если предположить, что у вас есть, скажем, 4 процессора, разрешение 20 одновременных запросов - это уже довольно большая нагрузка. Я бы предпочел задушить HTTP-запросы, чем увеличивать количество запросов, которые могут обрабатываться одновременно. Если вы обнаружите, что для одного запроса требуется более одного подключения, в вашем приложении есть недостаток.

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

...