web-dev-qa-db-ja.com

pgBouncerはうまく機能しますが、時々利用できなくなります

忙しいpostgres 9データベースの前でpgBouncerを実行しています。ほとんどの場合、問題なく動作します。しかし、psycopg2からの例外を除いて、数時間ごとにアプリケーションからエラー電子メールが届きます。

OperationalError（ 'サーバーに接続できませんでした：要求されたアドレスを割り当てることができませんサーバーはホスト「neo-hulk」で実行されており、ポート6432でTCP/IP接続を受け入れていますか？'）

これは、pythonアプリで、タスクを実行しているセロリワーカーの束が含まれています。これらのエラーが発生したら、pgbouncer dbを確認し、プールサイズが制限内にあることを確認します。実験を行った後、プールの最大値を設定しましたサイズを400に、プールサイズを200に設定します。プールモードは「セッション」です（リクエストはほとんど自動コミットで、ほとんどトランザクションはありません）。

何がpgBouncerをそのように「消失」させるのですか？それは短期間のみです（そして、全体としては、処理する要求の膨大な量と比較して、ごく少量の要求について話しています）が、失敗した要求は重要です。

ありがとう！

postgresqlpythonpgbouncer
9
Harel

エラーメッセージの "要求されたアドレスを割り当てることができません"の部分はカーネルからのものですTCPスタック。断続的に発生する場合、これは通常、使用可能なソケットのスペースが使い果たされたことを意味します待機状態のソケットが多すぎるため（TIME_WAIT、またはおそらくFIN_WAIT_1またはFIN_WAIT_2）

ソケットポートの範囲はcat /proc/sys/net/ipv4/ip_local_port_rangeで出力できます。標準のLinuxカーネルのデフォルト値は、通常32768 61000です。

システムがビジー状態のときに、クライアントとpgBouncerのホストでnetstat -ton|grep WAITの結果を確認できます。 -oフラグは、待機状態に関連するタイムアウトカウンターを表示します。

TCPソケットの総数が61000-32768=28232に近い場合、この範囲の枯渇が問題である可能性があります。閉じられたソケットは通常TIME_WAIT状態で60秒を費やすため、条件。クライアントホストが1分間に28232回以上接続すると、ポートが解放されるまで、新しい接続は前述のエラーで失敗します。

最初の回避策として、TCPポート範囲を拡張できます。

 # echo "1025 65535" >/proc/sys/net/ipv4/ip_local_port_range

満足できない場合は、tcp_tw_recycleフラグとtcp_tw_reuseフラグを確認し、/proc/sys/net/ipv4とsysctlでも調整できます。

それらは（man tcpから）として定義されます。

 tcp_tw_recycle（ブール値;デフォルト：無効; Linux 2.4以降）
 TIME_WAITソケットの高速リサイクルを有効にします。この
オプションを有効にすると、NAT（ネットワークアドレス変換）。
 
 tcp_tw_reuse（ブール値;デフォルト：無効; Linux 2.4.19/2.6以降）
 TIME_WAITソケットをプロトコル接続の観点から安全である場合に新しい接続に再利用できるようにします
。 .____。]技術専門家のアドバイス/リクエスト。

個人的には、MySQLクライアントアプリでこの問題に直面したときにtcp_tw_recycleで成功しましたが、これを推奨するものではありません。TCPの理解は表面的なものです。

15
Daniel Vérité