2011-01-18 2 views
3

私の組織では、PostgreSQLデータベースはポリシーとして20接続制限で作成されます。これは、多くのアプリケーションが接続プールを使用する複数のアプリケーションが動作しているときに、それらの接続の完全なスイートを開いてアイドル状態に保持するため、接続が不十分になる傾向があります。データベースの接続制限はどのようにする必要がありますか?

DBに接続しているアプリケーションが複数あるとすぐに、期待通りに接続が不足します。

ここでは、プーリングの動作は新しいものです。これまでは、WebベースのDBゲートウェイ(?!)を介してアクセスをシリアル化してプールされた接続を管理していました。結果として、プルーイングがどのように機能するかについて何度も何度も何度も説明しなければなりません。私が欲しいもの

は、次のいずれかです。

  1. プールで素晴らしいプレーするために、データベースに利用可能な接続の数を増やすための固体、inarguable根拠。
    もしそうなら、どのような安全な制限がありますか?限界を20に保つ理由はありますか?

  2. 私が間違っている理由とプールのサイズを減らすか、それらを完全になくす必要がある理由。

ここで重要なのは、再生中のコンポーネントです。これらのいずれかがどのように設定されているかに関係がある場合は、次のように入力してください。

DB:PostgreSQL 8.2。いいえ、私たちはこれの一部としてそれをアップグレードしません。
Webサーバ:Pythonの2.7、Pylonsの1.0、SQLAlchemyの0.6.5、psycopg2

  • これは、手動で構成されたエンジンを使用してSQLAlchemyのORMを使用して、システムのアクセスデータのいくつかの側面は、他の人がデータにアクセスしながら、という事実によって複雑になります古いPHP APIと一致するオブジェクトに接続をラップする、自分のアソシエートが書き込んだ別のエンジンファクトリ(Still sqlalchemy)を使用しています。

タスクランナー:Pythonの2.7、セロリ2.1.4、SQLAlchemyの0.6.5、psycopg2

+0

私はこれがserverfault.comでうまく答えられると思います。 – David

答えて

2

私はそれが同時活動ごとに1つの接続を必要とするのが妥当だと思うし、それが同時HTTP要求が同時にあると仮定するのが合理的です実行される。

処理する同時HTTPリクエストの数は、a)サーバーの負荷と、b)利用可能なCPUの数との比例関係になります。すべてがうまくいくと、各リクエストはどこか(Webサーバー、アプリケーションサーバー、またはデータベースサーバー)のどこかでCPU時間を消費します。つまり、CPUよりも多くの要求を同時に処理できませんでした。実際には、すべてうまくいくわけではありません。一部の要求は、ある時点でIOを待機し、CPUを消費しないことがあります。だからあなたはCPUを持っているよりも同時にいくつかの要求を処理するのは大丈夫です。

まだ、4つのCPUを持っていると仮定すると、20の同時リクエストを許可することは、かなりの負荷がかかります。私は、同時に処理できる要求の数を増やすよりも、むしろHTTP要求を抑制する方がよいでしょう。 1つのリクエストに複数の接続が必要な場合は、アプリケーションに欠陥があります。

私はこの制限に対処し、(実際に同時に処理している要求の数に比べて)アイドル状態の接続があまりにも多くないことを確認することをお勧めします。

関連する問題