[pgsql-jp: 34749] Re: pgpoolが無応答になる

[Kouji Ito]

伊藤です。
>
> 違いますね．pgpoolでは，このfdをnon blockingにしており，かつ複数の子プ
> ロセスが同じfdに対するaccept要求を取り合う構造になっています．したがっ
> て，ある子プロセスがacceptしにいったときにはすでに他の子プロセスに横取
> りされてしまっている...ということは起こり得ます．このケースでEAGAINが
> acceptから返るわけです．
>
> もちろんaccept要求が来ているのに，どの子プロセスのacceptもEAGAINで蹴ら
> れてしまった...ということならもちろん異常なんですが，ひとつの子プロセ
> スの動きだけを見ているだけでは，そういうことなのかどうかの判断はできな
> いと思います．
>
なるほど、そういう作りになっているんですね。
納得です。


>> accept()に渡しているファイルディスクリプタが間違っているとすると、
>> select()が、返してきているfd_setが間違っているか、その後の
>> アプリ側での、ファイルディスクリプタのチェックが間違っている、
>> アプリ側で、fd_setを壊しているぐらいでしょうか。
>> いずれも、可能性としては低そうですね。
>>
>> Linuxには詳しくないのであまり突っ込んだ話が出来ないのですが、
>> select(),accept()あたりに関するカーネルパッチとか出てないんでしょうか？
>> 接続したとたんに、相手がclose()したり、ハーフオープンな接続があった
>> 時とかのLinuxのselect(),accept()ってどう動くんでしょう？
>
> よくわかりませんが，さすがにそういうコネクションに対してacceptが-1以外
> を返すことはないと思われます．仮に-1以外を返したとしても，次にフロント
> エンドからスタートアップパケットを読み込むためにそのコネクションに対し
> てreadをかけますので，その時点でエラーになると思います
なるほど。

>> ロジック上問題がないとすると、tcpdumpなどで、LANのトレースを取る必用が
>> あるかもしれません。
>
> このあたりはうといのですが，これによってどのような情報を得ることができ
> るのでしょうか？
acceptや、select（結局は、カーネルがってことになりますが）がバグっている
可能性はかなり低い。

acceptに対して、コネクションが確立済のソケットを渡すというのは、何かおかしい
のではないか。（これは、pgpoolの作りとしておかしな訳ではないということで納得）

pgpoolは通常は普通に動いている。

何かがきっかけで、pgpoolを動かしているpgpoolサーバのCPU使用率が100%になる。

straceの結果からは、誰かがpgpoolに対して接続(connnect)を行っている事が判る。

pgpoolサーバへは、WEB1と、WEB2がアクセスしにきている。

というのが、前回のstraceの結果と、成瀬さんの調査で判った、と考えました。
さらに、他の要因を考えたときに、

pgpoolに誰が、どのタイミングでコネクションの確立を行おうとしているのか、
さらに、そのタイミングと、straceでのselectから抜けてくるタイミングは一致しているのか、
誰かがpgpoolに対して不正なアクセスをしてきていないのか、
pgpoolが使用しているポート番号に対して、全く関係ない処理がconnectしてきている
可能性はないのか、

という部分に着目すると、pgpoolサーバで、tcpdumpすることで、なにか新たな手がかりが
見つかるのではないかと思った訳です。