web-dev-qa-db-ja.com

WANリンクを介してPGbouncerに使用する構成

アメリカとヨーロッパに1つずつ、合計2つのデータセンターがあります。さまざまな理由から、ヨーロッパのデータセンターにはデータベースサーバーがあり、ワーカーとWebアプリはアメリカにあります。

PGbouncerは、トランザクションプーリングモードのアメリカのデータセンターにあり、ヨーロッパのデータセンターへの接続遅延を削減するのに役立ちます。残念ながら、私はしばしば「<IDLE> in transaction "状態。ロックを保持し、残りのマシンが有用な進行を行うのを妨げています。

America
-------

worker      webapp
   |           |
    \         /
     \       /
      +--+--+
         |
     pgbouncer
         |
         :

      public
      Internet

         :
         |
      PostgreSQL

------
Europe

トランザクションでアイドル状態になるのを防ぐために、どのpgbouncerパラメーターを設定/リセット/変更する必要がありますか？

postgresqlpgbouncer
1
François Beausoleil

ええと、「<IDLE> in transaction」のままのアプリケーションは、実際にはアプリケーションレベルの問題であり、pgBouncerができることではありません。

まず、アプリケーションが「トランザクション中の<IDLE>」にどのくらいの期間残っているかを把握し、悪質な違反者を追跡する必要があります。クライアントはWANリンク上で遠く離れているため、クライアントが「トランザクション中の<IDLE>」であるのは、たとえば、短いクエリの間隔が数百ミリ秒（つまり、ネットワーク遅延）であるのは完全に正常です。それに加えて、後続のクエリ間のクライアント側での処理時間もあります）。 。

大規模なコードベースと多数のクライアントがある場合、「トランザクション内の<IDLE>」接続などのコード内のどこから接続が発生しているかを正確に特定するのは難しい場合があります（独自のコードベースからではなく、フレームワークの問題である可能性もあります-= Djangoは、トランザクション '接続で不思議な' <IDLE>を引き起こすという悪い歴史がありました）。これらの接続がどこから来ているかを追跡しやすくするために、コードベース内の個別のアプリケーションに別のapplication_nameを設定することをお勧めします。 。

最後に、Postgresが「トランザクション内の<IDLE>」接続を強制終了できるようにするための保留中のパッチがあります： http://www.postgresql.org/message-id/538DC843.2070608@dalibo .com

運が良ければ、Postgres 9.5にidle_in_transaction_timeout（またはそれが終わる名前）があるかもしれません。

2
Josh Kupershmidt