[pgsql-jp: 35721] Re: pgpoolのfflush()におけるEAGAIN

[Tatsuo Ishii]

石井です．

> > 永橋です。
> > 
> > linuxでpgpool(2.6.1)の簡単な動作確認を行いました。
> > 
> > 個別のメールでnon_blockingに統一するとのお話がありましたが
> > 2.6.1でもdo_acceptのaccept関数で生成されたソケットには
> > fcntlでのO_NONBLOCK設定がされていなかったのでlinuxでは
> > blockingで動作していると思われます。
> 
> そうですね．
> 
> > そこでchild.cのdo_acceptを呼び出し後を以下のように変更しました。
> > 
> >     frontend = do_accept(unix_fd, inet_fd, &timeout);
> > 
> >     if (frontend == NULL)
> >     {
> >       /* check select() timeout */
> >       if (connected && pool_config.child_life_time > 0 &&
> >         timeout.tv_sec == 0 && timeout.tv_usec == 0)
> >       {
> >         pool_debug("child life %d seconds expired", pool_config.child_life_time);
> >         send_frontend_exits();
> >         exit(2);
> >       }
> >       continue;
> >     }
> > #ifdef NONE_BLOCK
> >     set_nonblock(frontend->fd);
> > #endif
> > 
> > 動作としては正常なのですが大量レコード検索時 pool_fulsh_itでの
> > write関数でEAGAINが多発します。
> > （検索結果３万レコードを受けるのに13万回発生)
> > 
> > この状態がシステムにどれほどの負荷がかかるのか判断できませんが
> > やはり山下さんが言われてたようにselectで書き込み可を確認しwrite関数を
> > 呼び出した方が良いのではないでしょうか。
> 
> 記憶がさだかではないのですが，なぜnon blockに拘っているかというと，
> Solarislか何かで，non blockでないと性能が出ない，という話が以前あった
> からなのです(記憶違いだったらごめんなさい)．しかしそもそもSolarisや
> FreeBSDでnon blockでの動作が正常ではなかったことが発覚した今，non
> blockに拘る必要があるのかどうか迷っています．
> 
> できれば，
> 
> 1) non block
> 2) 事前select(writeできることを確認)+non block
> 3) block
> 
> の3パターンのパフォーマンス比較をしてみるのがよいと思います．

Linuxでやってみました．1)はパフォーマンスがよくありません．おまけに，
broken pipeエラーがたまに出ます．2)と3)はほとんど同じ性能でした．とな
ると，わざわざnon blockingにする意味もなさそうです．

一律non blockingをやめたバージョンを，

http://www2b.biglobe.ne.jp/~caco/pgpool/tmp/pgpool-2.6.1.tar.gz

に置きましたので，特にSolarisやFreeBSDの方はテストして頂けるとありがた
いです．
--
Tatsuo Ishii