kai-users-ja Mailing List for kai (Page 3)
Kai is a distributed key-value datastore
Status: Beta
Brought to you by:
takemaru
You can subscribe to this list here.
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
(8) |
Feb
(23) |
Mar
(13) |
Apr
(1) |
May
(4) |
Jun
(6) |
Jul
(24) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Takeru I. <tak...@gm...> - 2009-02-25 10:12:08
|
お疲れ様でした. branches/takemaru_stats/ にも反映させました. 2009/2/24 masahito ikuta <coo...@gm...>: > コミットが完了致しました。 > ※ svn コマンドが古かったようです・・・。 > > 念のため、手元での簡単な手動テストと > make test は通しておりますが > 不具合等ございましたら、お手数ではございますが > ご指摘をよろしくお願い致します。 > > ちなみに・・・git の操作ミスで先に branch にコミットしてしまいました。 > 申し訳ございませんでした。 > > 2009/2/24 masahito ikuta <coo...@gm...>: >> コミットしようとしたらエラーになってしまい >> チェックアウトしようとしたら、下記のエラーが出ました。 >> >> % svn co https://kai.svn.sourceforge.net/svnroot/kai kai >> svn: REPORT リクエスト (相手: '/svnroot/kai/!svn/vcc/default') が失敗しました >> svn: Can't find a temporary directory: Internal error >> >> 誠に申し訳ございませんが >> コミットまで、もう少々お待ち下さい orz >> >> 2009/2/24 masahito ikuta <coo...@gm...>: >>>> このテストコードのようにものすごい勢いでソケットを廃棄される状況では,再利用までの時間を短くするなどの調整を行わない限り,TCP >>>> は正常に動作しないように思いました. >>> >>> なるほどー。 >>> >>> と言う事で >>> http://www.linux.or.jp/JM/html/LDP_man-pages/man7/socket.7.html >>> を読んで理解しました。 >>> >>> では、今晩あたり trunk にコミットします!お騒がせして申し訳ございませんでした。 >>> >>> 2009/2/23 Takeru INOUE <tak...@gm...>: >>>> 2009/2/23 Takeru INOUE <tak...@gm...>: >>>>> 必ず次のようなエラーになりますね (16383 回目の connect に失敗). >>>>> >>>>> Can not connect:16383 at test.pl line 14. >>>>> >>>>> 複数のクライアントを走らせた場合でも,合計の connect 数が 16383 になるとエラーになりました. >>>>> >>>>> Can not connect:7152 at test.pl line 14. >>>>> Can not connect:9231 at test.pl line 14. >>>>> >>>>> どうやら,この magic number でリソースが足りなくなるようです. >>>>> >>>>>>> 今後は、Acceptor Pooling を止めるとどうなるか >>>>>>> 試してみる予定です。 >>>>>> >>>>>> max_connection = 1 で試していた事を忘れていました。 >>>>>> Yaws と Mochiweb の Source を見直してみます。 >>>>> >>>>> max_connection = 2 でも同じでした. >>>>> 本家 ML に聞いてみた方がいいかも. >>>>> 聞いときましょうか. >>>> >>>> と思ったのですが,よく考えたら,TCP ソケットは再利用可能になるまでに一定の時間がかかるので,それまで接続できなくなっているのではないでしょうか. >>>> つまり,gen_tcp:close/1 によってソケットは正常に閉じられているが,再利用できるまで何秒かかかっているということです. >>>> >>>> このテストコードのようにものすごい勢いでソケットを廃棄される状況では,再利用までの時間を短くするなどの調整を行わない限り,TCP >>>> は正常に動作しないように思いました. >>>> >>>>>> 2009/2/23 masahito ikuta <coo...@gm...>: >>>>>>>> コミットされたらこちらでも確認してみますね. >>>>>>> >>>>>>> コミットするか否か迷っておりますので、お知恵を拝借させて下さい。 >>>>>>> >>>>>>> ▼修正後の状況 >>>>>>> クライアントから切断された際 >>>>>>> Active Mode では、メッセージとして {tcp_closed, Socket} が >>>>>>> Passive Mode では、gen_tcp:recv/3 の戻り値として {error, closed} が >>>>>>> それぞれ戻って来るのですが >>>>>>> 両モード共に gen_tcp:close/1 を呼んだとしても >>>>>>> ある一定回数以上 接続・切断を繰り替えすと >>>>>>> 数秒間だけ接続できなくなります。 >>>>>>> >>>>>>> 以前の版と異なるのは、以下の三点です。 >>>>>>> ・Erlang Shell ごと落ちない(そもそもプロセスが落ちなくなった) >>>>>>> ・障害が発生させる為の 接続・切断 の回数が以前より多い(私の環境で 4 倍ほど) >>>>>>> ・数秒経つと、また接続が可能となる >>>>>>> >>>>>>> ▼個人的な希望 >>>>>>> 以前の状態よりは、マシな状態である為 >>>>>>> trunk にコミットさせて頂けないでしょうか? >>>>>>> >>>>>>> ▼現在、調査して解っている箇所 >>>>>>> Erlang Shell から i() で、接続できない状態のプロセスを確認すると >>>>>>> 接続できる状態と同様に prim_inet:accept0/2 で待ち受けており >>>>>>> gen_tcp:accept/2 で失敗しているようでもありませんでした。 >>>>>>> >>>>>>> gen_tcp:close/1 の戻り値を確認しても >>>>>>> ok が戻されている為、正常に終了できているようでした。 >>>>>>> >>>>>>> ※もしかして、gen_tcp:close/1 って非同期で inet 関連のプロセスと通信してる? >>>>>>> >>>>>>> ちなみに、Active、Passive 両モード共に >>>>>>> サーバ側から切断する分には全く問題が発生しません。 >>>>>>> >>>>>>> ※クライアントから切断するなんて、普通に行う事なんだけどなぁ・・・ >>>>>>> >>>>>>> gen_tcp のドキュメントを読み返しているのですが >>>>>>> そもそも、ドキュメント内のサンプルコードでは >>>>>>> {error, closed} を受信しても gen_tcp:close/1 を呼び出してすらいない為 >>>>>>> 完全に手詰まりです。 >>>>>>> >>>>>>> 本メールにテストに必要なファイル一式を添付致しましたので >>>>>>> いろいろお試し頂けると助かります。 >>>>>>> >>>>>>> 今後は、Acceptor Pooling を止めるとどうなるか >>>>>>> 試してみる予定です。 >>>>>>> >>>>>>> 以上です。 >>>>>>> >>>>>>> 2009/2/22 Takeru INOUE <tak...@gm...>: >>>>>>>> 深夜までお疲れ様でした m(_ _)m >>>>>>>> >>>>>>>> コミットされたらこちらでも確認してみますね. >>>>>>>> >>>>>>>> 2009/2/21 masahito ikuta <coo...@gm...>: >>>>>>>>> 幾田です。 >>>>>>>>> 原因が判明しました。 >>>>>>>>> >>>>>>>>> ▼対処 >>>>>>>>> クライアントから切断された際の処理に gen_tcp:close/1 を加え >>>>>>>>> 障害が再現しない事を確認しました。 >>>>>>>>> >>>>>>>>> 後で、コミットしておきます。 >>>>>>>>> >>>>>>>>> ▼障害内容 >>>>>>>>> クライアントから切断されたのだから >>>>>>>>> gen_tcp:close/1 は不要だろうと思い込んでいたのですが >>>>>>>>> gen_tcp:close/1 は、諸々の後始末をしているようで >>>>>>>>> これを呼ばずに、クライアント側で接続・切断を繰り返すと >>>>>>>>> 一定回数後に、 Erlang Shell ごと落ちていました。 >>>>>>>>> >>>>>>>>> ▼検証用のクライアントコード >>>>>>>>> kai_tcp_server で echo server を作り >>>>>>>>> 下記の Perl Script で接続・切断を繰り返すと >>>>>>>>> サーバが落ちます。 >>>>>>>>> (対処済みのサーバは落ちませんでした) >>>>>>>>> >>>>>>>>> #!/usr/bin/env perl >>>>>>>>> >>>>>>>>> use strict; >>>>>>>>> use warnings; >>>>>>>>> >>>>>>>>> use IO::Socket; >>>>>>>>> >>>>>>>>> for (1..10000) { >>>>>>>>> test(); >>>>>>>>> } >>>>>>>>> >>>>>>>>> sub test { >>>>>>>>> my $socket = IO::Socket::INET->new( >>>>>>>>> PeerAddr => 'localhost', >>>>>>>>> PeerPort => 11211, >>>>>>>>> Proto => 'tcp', >>>>>>>>> ) or die 'Can not connect.'; >>>>>>>>> >>>>>>>>> $socket->print('aaa', "\r\n"); >>>>>>>>> $socket->flush(); >>>>>>>>> my $return = <$socket>; >>>>>>>>> $socket->close(); >>>>>>>>> } >>>>>>>>> >>>>>>>>> >>>>>>>>> 以上です。 >>>>>>>>> >>>>>>>>> >>>>>>>>> 2009/2/21 masahito ikuta <coo...@gm...>: >>>>>>>>>> 幾田です。 >>>>>>>>>> >>>>>>>>>> kai-users-ja に参加していなかった事をスッカリ忘れていて >>>>>>>>>> 先ほど、慌てて Subscribe しました。申し訳ございません。 >>>>>>>>>> >>>>>>>>>>>quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop >>>>>>>>>>>のいずれの場合にもマッチしないようです. >>>>>>>>>> >>>>>>>>>> 明日、障害の再現後、修正致します。 >>>>>>>>>> >>>>>>>>>>>> 橋本です。 >>>>>>>>>>>> >>>>>>>>>>>> 以前、"接続が問答無用で切断されるようになった" >>>>>>>>>>>> >>>>>>>>>>>というタイトルで質問させてもらいました。そのときは割り当てるファイルディスクリプタを大きくして解決したと思っていましたが、もしかしたら間違えていたかもしれません。 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>statsの実装を進めていただいているので、ポーリングしてグラフ化するようにcactiのプラグインを動かしてみました。5分おきにstatsをポーリングするだけなのですが、一日ほど動かしただけで先日報告した"接続が問答無用で切断されるようになった" >>>>>>>>>>>> >>>>>>>>>>>と同じ状態になりました。監視のテストをしただけで実際にデータを突っ込んだりはしていません。今回はファイルディスクリプタの数を明示的に増やしたりはしていません。 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>推測なのですが、kaiから切断するときにquitを送らずに、tcpを切断した場合に問題になるようなことはないでしょうか。先日も、今回のcactiのプラグインもkaiへのアクセスにはpeclのmemcache実装を使っています。 >>>>>>>>>>> >>>>>>>>>>>ちょっとテストしてみましたが,その推測通りっぽいです. >>>>>>>>>>>kai_tcp_server モジュールで処理フローが行方不明になっています.. >>>>>>>>>>> >>>>>>>>>>>cooldaemon 様: >>>>>>>>>>>ここ数日ほど出先で mac >>>>>>>>>>>しかなく,十分なチェックができないでいます. >>>>>>>>>>>quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop >>>>>>>>>>>のいずれの場合にもマッチしないようです. >>>>>>>>>>>ただし,mac の netstat >>>>>>>>>>>で確認したところ,サーバ側のソケットは正しく閉じられているように見えました. >>>>>>>>>>>可能なら,Linux でチェックしてみてください. >>>>>>>>>>> >>>>>>>>>>>> http://pecl.php.net/package/memcache >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>tcpdumpして確認したのですが、ソースコードで明示的にcloseを行ってもquitコマンドは発行していないようです。以前ご紹介したmcbだとちゃんとquitを送っているようです。そのため、このツールを使って負荷をかけた場合には問題が発生したなかったのではないかと推測しています。 >>>>>>>>>>>> >>>>>>>>>>>> http://www.interdb.jp/techinfo/mcb/index.html >>>>>>>>>>>> >>>>>>>>>>>> いかがでしょうか。 >>>>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>>>>>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>>>>>>>>>>> -Strategies to boost innovation and cut costs with open source participation >>>>>>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD >>>>>>>>>>>> http://p.sf.net/sfu/XcvMzF8H >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Kai-users-ja mailing list >>>>>>>>>>>> Kai-users-ja@li... >>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>-- >>>>>>>>>>>Takeru INOUE <takeru.inoue@gm...> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> cooldaemon >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> cooldaemon >>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>>>>>>>> -Strategies to boost innovation and cut costs with open source participation >>>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD >>>>>>>>> http://p.sf.net/sfu/XcvMzF8H >>>>>>>>> _______________________________________________ >>>>>>>>> Kai-users-ja mailing list >>>>>>>>> Kai...@li... >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Takeru INOUE <tak...@gm...> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> cooldaemon >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> cooldaemon >>>>>> ------------------------------------------------------------------------------ >>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>>>>> -Strategies to boost innovation and cut costs with open source participation >>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD >>>>>> http://p.sf.net/sfu/XcvMzF8H >>>>>> _______________________________________________ >>>>>> Kai-users-ja mailing list >>>>>> Kai...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Takeru INOUE <tak...@gm...> >>>>> >>>> >>>> >>>> >>>> -- >>>> Takeru INOUE <tak...@gm...> >>>> >>> >>> >>> >>> -- >>> cooldaemon >>> >> >> >> >> -- >> cooldaemon >> > > > > -- > cooldaemon > -- Takeru INOUE <tak...@gm...> |
From: masahito i. <coo...@gm...> - 2009-02-24 14:37:55
|
コミットが完了致しました。 ※ svn コマンドが古かったようです・・・。 念のため、手元での簡単な手動テストと make test は通しておりますが 不具合等ございましたら、お手数ではございますが ご指摘をよろしくお願い致します。 ちなみに・・・git の操作ミスで先に branch にコミットしてしまいました。 申し訳ございませんでした。 2009/2/24 masahito ikuta <coo...@gm...>: > コミットしようとしたらエラーになってしまい > チェックアウトしようとしたら、下記のエラーが出ました。 > > % svn co https://kai.svn.sourceforge.net/svnroot/kai kai > svn: REPORT リクエスト (相手: '/svnroot/kai/!svn/vcc/default') が失敗しました > svn: Can't find a temporary directory: Internal error > > 誠に申し訳ございませんが > コミットまで、もう少々お待ち下さい orz > > 2009/2/24 masahito ikuta <coo...@gm...>: >>> このテストコードのようにものすごい勢いでソケットを廃棄される状況では,再利用までの時間を短くするなどの調整を行わない限り,TCP >>> は正常に動作しないように思いました. >> >> なるほどー。 >> >> と言う事で >> http://www.linux.or.jp/JM/html/LDP_man-pages/man7/socket.7.html >> を読んで理解しました。 >> >> では、今晩あたり trunk にコミットします!お騒がせして申し訳ございませんでした。 >> >> 2009/2/23 Takeru INOUE <tak...@gm...>: >>> 2009/2/23 Takeru INOUE <tak...@gm...>: >>>> 必ず次のようなエラーになりますね (16383 回目の connect に失敗). >>>> >>>> Can not connect:16383 at test.pl line 14. >>>> >>>> 複数のクライアントを走らせた場合でも,合計の connect 数が 16383 になるとエラーになりました. >>>> >>>> Can not connect:7152 at test.pl line 14. >>>> Can not connect:9231 at test.pl line 14. >>>> >>>> どうやら,この magic number でリソースが足りなくなるようです. >>>> >>>>>> 今後は、Acceptor Pooling を止めるとどうなるか >>>>>> 試してみる予定です。 >>>>> >>>>> max_connection = 1 で試していた事を忘れていました。 >>>>> Yaws と Mochiweb の Source を見直してみます。 >>>> >>>> max_connection = 2 でも同じでした. >>>> 本家 ML に聞いてみた方がいいかも. >>>> 聞いときましょうか. >>> >>> と思ったのですが,よく考えたら,TCP ソケットは再利用可能になるまでに一定の時間がかかるので,それまで接続できなくなっているのではないでしょうか. >>> つまり,gen_tcp:close/1 によってソケットは正常に閉じられているが,再利用できるまで何秒かかかっているということです. >>> >>> このテストコードのようにものすごい勢いでソケットを廃棄される状況では,再利用までの時間を短くするなどの調整を行わない限り,TCP >>> は正常に動作しないように思いました. >>> >>>>> 2009/2/23 masahito ikuta <coo...@gm...>: >>>>>>> コミットされたらこちらでも確認してみますね. >>>>>> >>>>>> コミットするか否か迷っておりますので、お知恵を拝借させて下さい。 >>>>>> >>>>>> ▼修正後の状況 >>>>>> クライアントから切断された際 >>>>>> Active Mode では、メッセージとして {tcp_closed, Socket} が >>>>>> Passive Mode では、gen_tcp:recv/3 の戻り値として {error, closed} が >>>>>> それぞれ戻って来るのですが >>>>>> 両モード共に gen_tcp:close/1 を呼んだとしても >>>>>> ある一定回数以上 接続・切断を繰り替えすと >>>>>> 数秒間だけ接続できなくなります。 >>>>>> >>>>>> 以前の版と異なるのは、以下の三点です。 >>>>>> ・Erlang Shell ごと落ちない(そもそもプロセスが落ちなくなった) >>>>>> ・障害が発生させる為の 接続・切断 の回数が以前より多い(私の環境で 4 倍ほど) >>>>>> ・数秒経つと、また接続が可能となる >>>>>> >>>>>> ▼個人的な希望 >>>>>> 以前の状態よりは、マシな状態である為 >>>>>> trunk にコミットさせて頂けないでしょうか? >>>>>> >>>>>> ▼現在、調査して解っている箇所 >>>>>> Erlang Shell から i() で、接続できない状態のプロセスを確認すると >>>>>> 接続できる状態と同様に prim_inet:accept0/2 で待ち受けており >>>>>> gen_tcp:accept/2 で失敗しているようでもありませんでした。 >>>>>> >>>>>> gen_tcp:close/1 の戻り値を確認しても >>>>>> ok が戻されている為、正常に終了できているようでした。 >>>>>> >>>>>> ※もしかして、gen_tcp:close/1 って非同期で inet 関連のプロセスと通信してる? >>>>>> >>>>>> ちなみに、Active、Passive 両モード共に >>>>>> サーバ側から切断する分には全く問題が発生しません。 >>>>>> >>>>>> ※クライアントから切断するなんて、普通に行う事なんだけどなぁ・・・ >>>>>> >>>>>> gen_tcp のドキュメントを読み返しているのですが >>>>>> そもそも、ドキュメント内のサンプルコードでは >>>>>> {error, closed} を受信しても gen_tcp:close/1 を呼び出してすらいない為 >>>>>> 完全に手詰まりです。 >>>>>> >>>>>> 本メールにテストに必要なファイル一式を添付致しましたので >>>>>> いろいろお試し頂けると助かります。 >>>>>> >>>>>> 今後は、Acceptor Pooling を止めるとどうなるか >>>>>> 試してみる予定です。 >>>>>> >>>>>> 以上です。 >>>>>> >>>>>> 2009/2/22 Takeru INOUE <tak...@gm...>: >>>>>>> 深夜までお疲れ様でした m(_ _)m >>>>>>> >>>>>>> コミットされたらこちらでも確認してみますね. >>>>>>> >>>>>>> 2009/2/21 masahito ikuta <coo...@gm...>: >>>>>>>> 幾田です。 >>>>>>>> 原因が判明しました。 >>>>>>>> >>>>>>>> ▼対処 >>>>>>>> クライアントから切断された際の処理に gen_tcp:close/1 を加え >>>>>>>> 障害が再現しない事を確認しました。 >>>>>>>> >>>>>>>> 後で、コミットしておきます。 >>>>>>>> >>>>>>>> ▼障害内容 >>>>>>>> クライアントから切断されたのだから >>>>>>>> gen_tcp:close/1 は不要だろうと思い込んでいたのですが >>>>>>>> gen_tcp:close/1 は、諸々の後始末をしているようで >>>>>>>> これを呼ばずに、クライアント側で接続・切断を繰り返すと >>>>>>>> 一定回数後に、 Erlang Shell ごと落ちていました。 >>>>>>>> >>>>>>>> ▼検証用のクライアントコード >>>>>>>> kai_tcp_server で echo server を作り >>>>>>>> 下記の Perl Script で接続・切断を繰り返すと >>>>>>>> サーバが落ちます。 >>>>>>>> (対処済みのサーバは落ちませんでした) >>>>>>>> >>>>>>>> #!/usr/bin/env perl >>>>>>>> >>>>>>>> use strict; >>>>>>>> use warnings; >>>>>>>> >>>>>>>> use IO::Socket; >>>>>>>> >>>>>>>> for (1..10000) { >>>>>>>> test(); >>>>>>>> } >>>>>>>> >>>>>>>> sub test { >>>>>>>> my $socket = IO::Socket::INET->new( >>>>>>>> PeerAddr => 'localhost', >>>>>>>> PeerPort => 11211, >>>>>>>> Proto => 'tcp', >>>>>>>> ) or die 'Can not connect.'; >>>>>>>> >>>>>>>> $socket->print('aaa', "\r\n"); >>>>>>>> $socket->flush(); >>>>>>>> my $return = <$socket>; >>>>>>>> $socket->close(); >>>>>>>> } >>>>>>>> >>>>>>>> >>>>>>>> 以上です。 >>>>>>>> >>>>>>>> >>>>>>>> 2009/2/21 masahito ikuta <coo...@gm...>: >>>>>>>>> 幾田です。 >>>>>>>>> >>>>>>>>> kai-users-ja に参加していなかった事をスッカリ忘れていて >>>>>>>>> 先ほど、慌てて Subscribe しました。申し訳ございません。 >>>>>>>>> >>>>>>>>>>quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop >>>>>>>>>>のいずれの場合にもマッチしないようです. >>>>>>>>> >>>>>>>>> 明日、障害の再現後、修正致します。 >>>>>>>>> >>>>>>>>>>> 橋本です。 >>>>>>>>>>> >>>>>>>>>>> 以前、"接続が問答無用で切断されるようになった" >>>>>>>>>>> >>>>>>>>>>というタイトルで質問させてもらいました。そのときは割り当てるファイルディスクリプタを大きくして解決したと思っていましたが、もしかしたら間違えていたかもしれません。 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>statsの実装を進めていただいているので、ポーリングしてグラフ化するようにcactiのプラグインを動かしてみました。5分おきにstatsをポーリングするだけなのですが、一日ほど動かしただけで先日報告した"接続が問答無用で切断されるようになった" >>>>>>>>>>> >>>>>>>>>>と同じ状態になりました。監視のテストをしただけで実際にデータを突っ込んだりはしていません。今回はファイルディスクリプタの数を明示的に増やしたりはしていません。 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>推測なのですが、kaiから切断するときにquitを送らずに、tcpを切断した場合に問題になるようなことはないでしょうか。先日も、今回のcactiのプラグインもkaiへのアクセスにはpeclのmemcache実装を使っています。 >>>>>>>>>> >>>>>>>>>>ちょっとテストしてみましたが,その推測通りっぽいです. >>>>>>>>>>kai_tcp_server モジュールで処理フローが行方不明になっています.. >>>>>>>>>> >>>>>>>>>>cooldaemon 様: >>>>>>>>>>ここ数日ほど出先で mac >>>>>>>>>>しかなく,十分なチェックができないでいます. >>>>>>>>>>quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop >>>>>>>>>>のいずれの場合にもマッチしないようです. >>>>>>>>>>ただし,mac の netstat >>>>>>>>>>で確認したところ,サーバ側のソケットは正しく閉じられているように見えました. >>>>>>>>>>可能なら,Linux でチェックしてみてください. >>>>>>>>>> >>>>>>>>>>> http://pecl.php.net/package/memcache >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>tcpdumpして確認したのですが、ソースコードで明示的にcloseを行ってもquitコマンドは発行していないようです。以前ご紹介したmcbだとちゃんとquitを送っているようです。そのため、このツールを使って負荷をかけた場合には問題が発生したなかったのではないかと推測しています。 >>>>>>>>>>> >>>>>>>>>>> http://www.interdb.jp/techinfo/mcb/index.html >>>>>>>>>>> >>>>>>>>>>> いかがでしょうか。 >>>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>>>>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>>>>>>>>>> -Strategies to boost innovation and cut costs with open source participation >>>>>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD >>>>>>>>>>> http://p.sf.net/sfu/XcvMzF8H >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Kai-users-ja mailing list >>>>>>>>>>> Kai-users-ja@li... >>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>-- >>>>>>>>>>Takeru INOUE <takeru.inoue@gm...> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> cooldaemon >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> cooldaemon >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>>>>>>> -Strategies to boost innovation and cut costs with open source participation >>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD >>>>>>>> http://p.sf.net/sfu/XcvMzF8H >>>>>>>> _______________________________________________ >>>>>>>> Kai-users-ja mailing list >>>>>>>> Kai...@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Takeru INOUE <tak...@gm...> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> cooldaemon >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> cooldaemon >>>>> ------------------------------------------------------------------------------ >>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>>>> -Strategies to boost innovation and cut costs with open source participation >>>>> -Receive a $600 discount off the registration fee with the source code: SFAD >>>>> http://p.sf.net/sfu/XcvMzF8H >>>>> _______________________________________________ >>>>> Kai-users-ja mailing list >>>>> Kai...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>>>> >>>> >>>> >>>> >>>> -- >>>> Takeru INOUE <tak...@gm...> >>>> >>> >>> >>> >>> -- >>> Takeru INOUE <tak...@gm...> >>> >> >> >> >> -- >> cooldaemon >> > > > > -- > cooldaemon > -- cooldaemon |
From: masahito i. <coo...@gm...> - 2009-02-24 14:02:47
|
コミットしようとしたらエラーになってしまい チェックアウトしようとしたら、下記のエラーが出ました。 % svn co https://kai.svn.sourceforge.net/svnroot/kai kai svn: REPORT リクエスト (相手: '/svnroot/kai/!svn/vcc/default') が失敗しました svn: Can't find a temporary directory: Internal error 誠に申し訳ございませんが コミットまで、もう少々お待ち下さい orz 2009/2/24 masahito ikuta <coo...@gm...>: >> このテストコードのようにものすごい勢いでソケットを廃棄される状況では,再利用までの時間を短くするなどの調整を行わない限り,TCP >> は正常に動作しないように思いました. > > なるほどー。 > > と言う事で > http://www.linux.or.jp/JM/html/LDP_man-pages/man7/socket.7.html > を読んで理解しました。 > > では、今晩あたり trunk にコミットします!お騒がせして申し訳ございませんでした。 > > 2009/2/23 Takeru INOUE <tak...@gm...>: >> 2009/2/23 Takeru INOUE <tak...@gm...>: >>> 必ず次のようなエラーになりますね (16383 回目の connect に失敗). >>> >>> Can not connect:16383 at test.pl line 14. >>> >>> 複数のクライアントを走らせた場合でも,合計の connect 数が 16383 になるとエラーになりました. >>> >>> Can not connect:7152 at test.pl line 14. >>> Can not connect:9231 at test.pl line 14. >>> >>> どうやら,この magic number でリソースが足りなくなるようです. >>> >>>>> 今後は、Acceptor Pooling を止めるとどうなるか >>>>> 試してみる予定です。 >>>> >>>> max_connection = 1 で試していた事を忘れていました。 >>>> Yaws と Mochiweb の Source を見直してみます。 >>> >>> max_connection = 2 でも同じでした. >>> 本家 ML に聞いてみた方がいいかも. >>> 聞いときましょうか. >> >> と思ったのですが,よく考えたら,TCP ソケットは再利用可能になるまでに一定の時間がかかるので,それまで接続できなくなっているのではないでしょうか. >> つまり,gen_tcp:close/1 によってソケットは正常に閉じられているが,再利用できるまで何秒かかかっているということです. >> >> このテストコードのようにものすごい勢いでソケットを廃棄される状況では,再利用までの時間を短くするなどの調整を行わない限り,TCP >> は正常に動作しないように思いました. >> >>>> 2009/2/23 masahito ikuta <coo...@gm...>: >>>>>> コミットされたらこちらでも確認してみますね. >>>>> >>>>> コミットするか否か迷っておりますので、お知恵を拝借させて下さい。 >>>>> >>>>> ▼修正後の状況 >>>>> クライアントから切断された際 >>>>> Active Mode では、メッセージとして {tcp_closed, Socket} が >>>>> Passive Mode では、gen_tcp:recv/3 の戻り値として {error, closed} が >>>>> それぞれ戻って来るのですが >>>>> 両モード共に gen_tcp:close/1 を呼んだとしても >>>>> ある一定回数以上 接続・切断を繰り替えすと >>>>> 数秒間だけ接続できなくなります。 >>>>> >>>>> 以前の版と異なるのは、以下の三点です。 >>>>> ・Erlang Shell ごと落ちない(そもそもプロセスが落ちなくなった) >>>>> ・障害が発生させる為の 接続・切断 の回数が以前より多い(私の環境で 4 倍ほど) >>>>> ・数秒経つと、また接続が可能となる >>>>> >>>>> ▼個人的な希望 >>>>> 以前の状態よりは、マシな状態である為 >>>>> trunk にコミットさせて頂けないでしょうか? >>>>> >>>>> ▼現在、調査して解っている箇所 >>>>> Erlang Shell から i() で、接続できない状態のプロセスを確認すると >>>>> 接続できる状態と同様に prim_inet:accept0/2 で待ち受けており >>>>> gen_tcp:accept/2 で失敗しているようでもありませんでした。 >>>>> >>>>> gen_tcp:close/1 の戻り値を確認しても >>>>> ok が戻されている為、正常に終了できているようでした。 >>>>> >>>>> ※もしかして、gen_tcp:close/1 って非同期で inet 関連のプロセスと通信してる? >>>>> >>>>> ちなみに、Active、Passive 両モード共に >>>>> サーバ側から切断する分には全く問題が発生しません。 >>>>> >>>>> ※クライアントから切断するなんて、普通に行う事なんだけどなぁ・・・ >>>>> >>>>> gen_tcp のドキュメントを読み返しているのですが >>>>> そもそも、ドキュメント内のサンプルコードでは >>>>> {error, closed} を受信しても gen_tcp:close/1 を呼び出してすらいない為 >>>>> 完全に手詰まりです。 >>>>> >>>>> 本メールにテストに必要なファイル一式を添付致しましたので >>>>> いろいろお試し頂けると助かります。 >>>>> >>>>> 今後は、Acceptor Pooling を止めるとどうなるか >>>>> 試してみる予定です。 >>>>> >>>>> 以上です。 >>>>> >>>>> 2009/2/22 Takeru INOUE <tak...@gm...>: >>>>>> 深夜までお疲れ様でした m(_ _)m >>>>>> >>>>>> コミットされたらこちらでも確認してみますね. >>>>>> >>>>>> 2009/2/21 masahito ikuta <coo...@gm...>: >>>>>>> 幾田です。 >>>>>>> 原因が判明しました。 >>>>>>> >>>>>>> ▼対処 >>>>>>> クライアントから切断された際の処理に gen_tcp:close/1 を加え >>>>>>> 障害が再現しない事を確認しました。 >>>>>>> >>>>>>> 後で、コミットしておきます。 >>>>>>> >>>>>>> ▼障害内容 >>>>>>> クライアントから切断されたのだから >>>>>>> gen_tcp:close/1 は不要だろうと思い込んでいたのですが >>>>>>> gen_tcp:close/1 は、諸々の後始末をしているようで >>>>>>> これを呼ばずに、クライアント側で接続・切断を繰り返すと >>>>>>> 一定回数後に、 Erlang Shell ごと落ちていました。 >>>>>>> >>>>>>> ▼検証用のクライアントコード >>>>>>> kai_tcp_server で echo server を作り >>>>>>> 下記の Perl Script で接続・切断を繰り返すと >>>>>>> サーバが落ちます。 >>>>>>> (対処済みのサーバは落ちませんでした) >>>>>>> >>>>>>> #!/usr/bin/env perl >>>>>>> >>>>>>> use strict; >>>>>>> use warnings; >>>>>>> >>>>>>> use IO::Socket; >>>>>>> >>>>>>> for (1..10000) { >>>>>>> test(); >>>>>>> } >>>>>>> >>>>>>> sub test { >>>>>>> my $socket = IO::Socket::INET->new( >>>>>>> PeerAddr => 'localhost', >>>>>>> PeerPort => 11211, >>>>>>> Proto => 'tcp', >>>>>>> ) or die 'Can not connect.'; >>>>>>> >>>>>>> $socket->print('aaa', "\r\n"); >>>>>>> $socket->flush(); >>>>>>> my $return = <$socket>; >>>>>>> $socket->close(); >>>>>>> } >>>>>>> >>>>>>> >>>>>>> 以上です。 >>>>>>> >>>>>>> >>>>>>> 2009/2/21 masahito ikuta <coo...@gm...>: >>>>>>>> 幾田です。 >>>>>>>> >>>>>>>> kai-users-ja に参加していなかった事をスッカリ忘れていて >>>>>>>> 先ほど、慌てて Subscribe しました。申し訳ございません。 >>>>>>>> >>>>>>>>>quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop >>>>>>>>>のいずれの場合にもマッチしないようです. >>>>>>>> >>>>>>>> 明日、障害の再現後、修正致します。 >>>>>>>> >>>>>>>>>> 橋本です。 >>>>>>>>>> >>>>>>>>>> 以前、"接続が問答無用で切断されるようになった" >>>>>>>>>> >>>>>>>>>というタイトルで質問させてもらいました。そのときは割り当てるファイルディスクリプタを大きくして解決したと思っていましたが、もしかしたら間違えていたかもしれません。 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>statsの実装を進めていただいているので、ポーリングしてグラフ化するようにcactiのプラグインを動かしてみました。5分おきにstatsをポーリングするだけなのですが、一日ほど動かしただけで先日報告した"接続が問答無用で切断されるようになった" >>>>>>>>>> >>>>>>>>>と同じ状態になりました。監視のテストをしただけで実際にデータを突っ込んだりはしていません。今回はファイルディスクリプタの数を明示的に増やしたりはしていません。 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>推測なのですが、kaiから切断するときにquitを送らずに、tcpを切断した場合に問題になるようなことはないでしょうか。先日も、今回のcactiのプラグインもkaiへのアクセスにはpeclのmemcache実装を使っています。 >>>>>>>>> >>>>>>>>>ちょっとテストしてみましたが,その推測通りっぽいです. >>>>>>>>>kai_tcp_server モジュールで処理フローが行方不明になっています.. >>>>>>>>> >>>>>>>>>cooldaemon 様: >>>>>>>>>ここ数日ほど出先で mac >>>>>>>>>しかなく,十分なチェックができないでいます. >>>>>>>>>quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop >>>>>>>>>のいずれの場合にもマッチしないようです. >>>>>>>>>ただし,mac の netstat >>>>>>>>>で確認したところ,サーバ側のソケットは正しく閉じられているように見えました. >>>>>>>>>可能なら,Linux でチェックしてみてください. >>>>>>>>> >>>>>>>>>> http://pecl.php.net/package/memcache >>>>>>>>>> >>>>>>>>>> >>>>>>>>>tcpdumpして確認したのですが、ソースコードで明示的にcloseを行ってもquitコマンドは発行していないようです。以前ご紹介したmcbだとちゃんとquitを送っているようです。そのため、このツールを使って負荷をかけた場合には問題が発生したなかったのではないかと推測しています。 >>>>>>>>>> >>>>>>>>>> http://www.interdb.jp/techinfo/mcb/index.html >>>>>>>>>> >>>>>>>>>> いかがでしょうか。 >>>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>>>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>>>>>>>>> -Strategies to boost innovation and cut costs with open source participation >>>>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD >>>>>>>>>> http://p.sf.net/sfu/XcvMzF8H >>>>>>>>>> _______________________________________________ >>>>>>>>>> Kai-users-ja mailing list >>>>>>>>>> Kai-users-ja@li... >>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>-- >>>>>>>>>Takeru INOUE <takeru.inoue@gm...> >>>>>>>> >>>>>>>> -- >>>>>>>> cooldaemon >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> cooldaemon >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>>>>>> -Strategies to boost innovation and cut costs with open source participation >>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD >>>>>>> http://p.sf.net/sfu/XcvMzF8H >>>>>>> _______________________________________________ >>>>>>> Kai-users-ja mailing list >>>>>>> Kai...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Takeru INOUE <tak...@gm...> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> cooldaemon >>>>> >>>> >>>> >>>> >>>> -- >>>> cooldaemon >>>> ------------------------------------------------------------------------------ >>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>>> -Strategies to boost innovation and cut costs with open source participation >>>> -Receive a $600 discount off the registration fee with the source code: SFAD >>>> http://p.sf.net/sfu/XcvMzF8H >>>> _______________________________________________ >>>> Kai-users-ja mailing list >>>> Kai...@li... >>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>>> >>> >>> >>> >>> -- >>> Takeru INOUE <tak...@gm...> >>> >> >> >> >> -- >> Takeru INOUE <tak...@gm...> >> > > > > -- > cooldaemon > -- cooldaemon |
From: masahito i. <coo...@gm...> - 2009-02-24 03:04:23
|
> このテストコードのようにものすごい勢いでソケットを廃棄される状況では,再利用までの時間を短くするなどの調整を行わない限り,TCP > は正常に動作しないように思いました. なるほどー。 と言う事で http://www.linux.or.jp/JM/html/LDP_man-pages/man7/socket.7.html を読んで理解しました。 では、今晩あたり trunk にコミットします!お騒がせして申し訳ございませんでした。 2009/2/23 Takeru INOUE <tak...@gm...>: > 2009/2/23 Takeru INOUE <tak...@gm...>: >> 必ず次のようなエラーになりますね (16383 回目の connect に失敗). >> >> Can not connect:16383 at test.pl line 14. >> >> 複数のクライアントを走らせた場合でも,合計の connect 数が 16383 になるとエラーになりました. >> >> Can not connect:7152 at test.pl line 14. >> Can not connect:9231 at test.pl line 14. >> >> どうやら,この magic number でリソースが足りなくなるようです. >> >>>> 今後は、Acceptor Pooling を止めるとどうなるか >>>> 試してみる予定です。 >>> >>> max_connection = 1 で試していた事を忘れていました。 >>> Yaws と Mochiweb の Source を見直してみます。 >> >> max_connection = 2 でも同じでした. >> 本家 ML に聞いてみた方がいいかも. >> 聞いときましょうか. > > と思ったのですが,よく考えたら,TCP ソケットは再利用可能になるまでに一定の時間がかかるので,それまで接続できなくなっているのではないでしょうか. > つまり,gen_tcp:close/1 によってソケットは正常に閉じられているが,再利用できるまで何秒かかかっているということです. > > このテストコードのようにものすごい勢いでソケットを廃棄される状況では,再利用までの時間を短くするなどの調整を行わない限り,TCP > は正常に動作しないように思いました. > >>> 2009/2/23 masahito ikuta <coo...@gm...>: >>>>> コミットされたらこちらでも確認してみますね. >>>> >>>> コミットするか否か迷っておりますので、お知恵を拝借させて下さい。 >>>> >>>> ▼修正後の状況 >>>> クライアントから切断された際 >>>> Active Mode では、メッセージとして {tcp_closed, Socket} が >>>> Passive Mode では、gen_tcp:recv/3 の戻り値として {error, closed} が >>>> それぞれ戻って来るのですが >>>> 両モード共に gen_tcp:close/1 を呼んだとしても >>>> ある一定回数以上 接続・切断を繰り替えすと >>>> 数秒間だけ接続できなくなります。 >>>> >>>> 以前の版と異なるのは、以下の三点です。 >>>> ・Erlang Shell ごと落ちない(そもそもプロセスが落ちなくなった) >>>> ・障害が発生させる為の 接続・切断 の回数が以前より多い(私の環境で 4 倍ほど) >>>> ・数秒経つと、また接続が可能となる >>>> >>>> ▼個人的な希望 >>>> 以前の状態よりは、マシな状態である為 >>>> trunk にコミットさせて頂けないでしょうか? >>>> >>>> ▼現在、調査して解っている箇所 >>>> Erlang Shell から i() で、接続できない状態のプロセスを確認すると >>>> 接続できる状態と同様に prim_inet:accept0/2 で待ち受けており >>>> gen_tcp:accept/2 で失敗しているようでもありませんでした。 >>>> >>>> gen_tcp:close/1 の戻り値を確認しても >>>> ok が戻されている為、正常に終了できているようでした。 >>>> >>>> ※もしかして、gen_tcp:close/1 って非同期で inet 関連のプロセスと通信してる? >>>> >>>> ちなみに、Active、Passive 両モード共に >>>> サーバ側から切断する分には全く問題が発生しません。 >>>> >>>> ※クライアントから切断するなんて、普通に行う事なんだけどなぁ・・・ >>>> >>>> gen_tcp のドキュメントを読み返しているのですが >>>> そもそも、ドキュメント内のサンプルコードでは >>>> {error, closed} を受信しても gen_tcp:close/1 を呼び出してすらいない為 >>>> 完全に手詰まりです。 >>>> >>>> 本メールにテストに必要なファイル一式を添付致しましたので >>>> いろいろお試し頂けると助かります。 >>>> >>>> 今後は、Acceptor Pooling を止めるとどうなるか >>>> 試してみる予定です。 >>>> >>>> 以上です。 >>>> >>>> 2009/2/22 Takeru INOUE <tak...@gm...>: >>>>> 深夜までお疲れ様でした m(_ _)m >>>>> >>>>> コミットされたらこちらでも確認してみますね. >>>>> >>>>> 2009/2/21 masahito ikuta <coo...@gm...>: >>>>>> 幾田です。 >>>>>> 原因が判明しました。 >>>>>> >>>>>> ▼対処 >>>>>> クライアントから切断された際の処理に gen_tcp:close/1 を加え >>>>>> 障害が再現しない事を確認しました。 >>>>>> >>>>>> 後で、コミットしておきます。 >>>>>> >>>>>> ▼障害内容 >>>>>> クライアントから切断されたのだから >>>>>> gen_tcp:close/1 は不要だろうと思い込んでいたのですが >>>>>> gen_tcp:close/1 は、諸々の後始末をしているようで >>>>>> これを呼ばずに、クライアント側で接続・切断を繰り返すと >>>>>> 一定回数後に、 Erlang Shell ごと落ちていました。 >>>>>> >>>>>> ▼検証用のクライアントコード >>>>>> kai_tcp_server で echo server を作り >>>>>> 下記の Perl Script で接続・切断を繰り返すと >>>>>> サーバが落ちます。 >>>>>> (対処済みのサーバは落ちませんでした) >>>>>> >>>>>> #!/usr/bin/env perl >>>>>> >>>>>> use strict; >>>>>> use warnings; >>>>>> >>>>>> use IO::Socket; >>>>>> >>>>>> for (1..10000) { >>>>>> test(); >>>>>> } >>>>>> >>>>>> sub test { >>>>>> my $socket = IO::Socket::INET->new( >>>>>> PeerAddr => 'localhost', >>>>>> PeerPort => 11211, >>>>>> Proto => 'tcp', >>>>>> ) or die 'Can not connect.'; >>>>>> >>>>>> $socket->print('aaa', "\r\n"); >>>>>> $socket->flush(); >>>>>> my $return = <$socket>; >>>>>> $socket->close(); >>>>>> } >>>>>> >>>>>> >>>>>> 以上です。 >>>>>> >>>>>> >>>>>> 2009/2/21 masahito ikuta <coo...@gm...>: >>>>>>> 幾田です。 >>>>>>> >>>>>>> kai-users-ja に参加していなかった事をスッカリ忘れていて >>>>>>> 先ほど、慌てて Subscribe しました。申し訳ございません。 >>>>>>> >>>>>>>>quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop >>>>>>>>のいずれの場合にもマッチしないようです. >>>>>>> >>>>>>> 明日、障害の再現後、修正致します。 >>>>>>> >>>>>>>>> 橋本です。 >>>>>>>>> >>>>>>>>> 以前、"接続が問答無用で切断されるようになった" >>>>>>>>> >>>>>>>>というタイトルで質問させてもらいました。そのときは割り当てるファイルディスクリプタを大きくして解決したと思っていましたが、もしかしたら間違えていたかもしれません。 >>>>>>>>> >>>>>>>>> >>>>>>>>statsの実装を進めていただいているので、ポーリングしてグラフ化するようにcactiのプラグインを動かしてみました。5分おきにstatsをポーリングするだけなのですが、一日ほど動かしただけで先日報告した"接続が問答無用で切断されるようになった" >>>>>>>>> >>>>>>>>と同じ状態になりました。監視のテストをしただけで実際にデータを突っ込んだりはしていません。今回はファイルディスクリプタの数を明示的に増やしたりはしていません。 >>>>>>>>> >>>>>>>>> >>>>>>>>推測なのですが、kaiから切断するときにquitを送らずに、tcpを切断した場合に問題になるようなことはないでしょうか。先日も、今回のcactiのプラグインもkaiへのアクセスにはpeclのmemcache実装を使っています。 >>>>>>>> >>>>>>>>ちょっとテストしてみましたが,その推測通りっぽいです. >>>>>>>>kai_tcp_server モジュールで処理フローが行方不明になっています.. >>>>>>>> >>>>>>>>cooldaemon 様: >>>>>>>>ここ数日ほど出先で mac >>>>>>>>しかなく,十分なチェックができないでいます. >>>>>>>>quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop >>>>>>>>のいずれの場合にもマッチしないようです. >>>>>>>>ただし,mac の netstat >>>>>>>>で確認したところ,サーバ側のソケットは正しく閉じられているように見えました. >>>>>>>>可能なら,Linux でチェックしてみてください. >>>>>>>> >>>>>>>>> http://pecl.php.net/package/memcache >>>>>>>>> >>>>>>>>> >>>>>>>>tcpdumpして確認したのですが、ソースコードで明示的にcloseを行ってもquitコマンドは発行していないようです。以前ご紹介したmcbだとちゃんとquitを送っているようです。そのため、このツールを使って負荷をかけた場合には問題が発生したなかったのではないかと推測しています。 >>>>>>>>> >>>>>>>>> http://www.interdb.jp/techinfo/mcb/index.html >>>>>>>>> >>>>>>>>> いかがでしょうか。 >>>>>>>>> ------------------------------------------------------------------------------ >>>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>>>>>>>> -Strategies to boost innovation and cut costs with open source participation >>>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD >>>>>>>>> http://p.sf.net/sfu/XcvMzF8H >>>>>>>>> _______________________________________________ >>>>>>>>> Kai-users-ja mailing list >>>>>>>>> Kai-users-ja@li... >>>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>-- >>>>>>>>Takeru INOUE <takeru.inoue@gm...> >>>>>>> >>>>>>> -- >>>>>>> cooldaemon >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> cooldaemon >>>>>> ------------------------------------------------------------------------------ >>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>>>>> -Strategies to boost innovation and cut costs with open source participation >>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD >>>>>> http://p.sf.net/sfu/XcvMzF8H >>>>>> _______________________________________________ >>>>>> Kai-users-ja mailing list >>>>>> Kai...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Takeru INOUE <tak...@gm...> >>>>> >>>> >>>> >>>> >>>> -- >>>> cooldaemon >>>> >>> >>> >>> >>> -- >>> cooldaemon >>> ------------------------------------------------------------------------------ >>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>> -Strategies to boost innovation and cut costs with open source participation >>> -Receive a $600 discount off the registration fee with the source code: SFAD >>> http://p.sf.net/sfu/XcvMzF8H >>> _______________________________________________ >>> Kai-users-ja mailing list >>> Kai...@li... >>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>> >> >> >> >> -- >> Takeru INOUE <tak...@gm...> >> > > > > -- > Takeru INOUE <tak...@gm...> > -- cooldaemon |
From: Takeru I. <tak...@gm...> - 2009-02-23 13:55:58
|
2009/2/23 Takeru INOUE <tak...@gm...>: > 必ず次のようなエラーになりますね (16383 回目の connect に失敗). > > Can not connect:16383 at test.pl line 14. > > 複数のクライアントを走らせた場合でも,合計の connect 数が 16383 になるとエラーになりました. > > Can not connect:7152 at test.pl line 14. > Can not connect:9231 at test.pl line 14. > > どうやら,この magic number でリソースが足りなくなるようです. > >>> 今後は、Acceptor Pooling を止めるとどうなるか >>> 試してみる予定です。 >> >> max_connection = 1 で試していた事を忘れていました。 >> Yaws と Mochiweb の Source を見直してみます。 > > max_connection = 2 でも同じでした. > 本家 ML に聞いてみた方がいいかも. > 聞いときましょうか. と思ったのですが,よく考えたら,TCP ソケットは再利用可能になるまでに一定の時間がかかるので,それまで接続できなくなっているのではないでしょうか. つまり,gen_tcp:close/1 によってソケットは正常に閉じられているが,再利用できるまで何秒かかかっているということです. このテストコードのようにものすごい勢いでソケットを廃棄される状況では,再利用までの時間を短くするなどの調整を行わない限り,TCP は正常に動作しないように思いました. >> 2009/2/23 masahito ikuta <coo...@gm...>: >>>> コミットされたらこちらでも確認してみますね. >>> >>> コミットするか否か迷っておりますので、お知恵を拝借させて下さい。 >>> >>> ▼修正後の状況 >>> クライアントから切断された際 >>> Active Mode では、メッセージとして {tcp_closed, Socket} が >>> Passive Mode では、gen_tcp:recv/3 の戻り値として {error, closed} が >>> それぞれ戻って来るのですが >>> 両モード共に gen_tcp:close/1 を呼んだとしても >>> ある一定回数以上 接続・切断を繰り替えすと >>> 数秒間だけ接続できなくなります。 >>> >>> 以前の版と異なるのは、以下の三点です。 >>> ・Erlang Shell ごと落ちない(そもそもプロセスが落ちなくなった) >>> ・障害が発生させる為の 接続・切断 の回数が以前より多い(私の環境で 4 倍ほど) >>> ・数秒経つと、また接続が可能となる >>> >>> ▼個人的な希望 >>> 以前の状態よりは、マシな状態である為 >>> trunk にコミットさせて頂けないでしょうか? >>> >>> ▼現在、調査して解っている箇所 >>> Erlang Shell から i() で、接続できない状態のプロセスを確認すると >>> 接続できる状態と同様に prim_inet:accept0/2 で待ち受けており >>> gen_tcp:accept/2 で失敗しているようでもありませんでした。 >>> >>> gen_tcp:close/1 の戻り値を確認しても >>> ok が戻されている為、正常に終了できているようでした。 >>> >>> ※もしかして、gen_tcp:close/1 って非同期で inet 関連のプロセスと通信してる? >>> >>> ちなみに、Active、Passive 両モード共に >>> サーバ側から切断する分には全く問題が発生しません。 >>> >>> ※クライアントから切断するなんて、普通に行う事なんだけどなぁ・・・ >>> >>> gen_tcp のドキュメントを読み返しているのですが >>> そもそも、ドキュメント内のサンプルコードでは >>> {error, closed} を受信しても gen_tcp:close/1 を呼び出してすらいない為 >>> 完全に手詰まりです。 >>> >>> 本メールにテストに必要なファイル一式を添付致しましたので >>> いろいろお試し頂けると助かります。 >>> >>> 今後は、Acceptor Pooling を止めるとどうなるか >>> 試してみる予定です。 >>> >>> 以上です。 >>> >>> 2009/2/22 Takeru INOUE <tak...@gm...>: >>>> 深夜までお疲れ様でした m(_ _)m >>>> >>>> コミットされたらこちらでも確認してみますね. >>>> >>>> 2009/2/21 masahito ikuta <coo...@gm...>: >>>>> 幾田です。 >>>>> 原因が判明しました。 >>>>> >>>>> ▼対処 >>>>> クライアントから切断された際の処理に gen_tcp:close/1 を加え >>>>> 障害が再現しない事を確認しました。 >>>>> >>>>> 後で、コミットしておきます。 >>>>> >>>>> ▼障害内容 >>>>> クライアントから切断されたのだから >>>>> gen_tcp:close/1 は不要だろうと思い込んでいたのですが >>>>> gen_tcp:close/1 は、諸々の後始末をしているようで >>>>> これを呼ばずに、クライアント側で接続・切断を繰り返すと >>>>> 一定回数後に、 Erlang Shell ごと落ちていました。 >>>>> >>>>> ▼検証用のクライアントコード >>>>> kai_tcp_server で echo server を作り >>>>> 下記の Perl Script で接続・切断を繰り返すと >>>>> サーバが落ちます。 >>>>> (対処済みのサーバは落ちませんでした) >>>>> >>>>> #!/usr/bin/env perl >>>>> >>>>> use strict; >>>>> use warnings; >>>>> >>>>> use IO::Socket; >>>>> >>>>> for (1..10000) { >>>>> test(); >>>>> } >>>>> >>>>> sub test { >>>>> my $socket = IO::Socket::INET->new( >>>>> PeerAddr => 'localhost', >>>>> PeerPort => 11211, >>>>> Proto => 'tcp', >>>>> ) or die 'Can not connect.'; >>>>> >>>>> $socket->print('aaa', "\r\n"); >>>>> $socket->flush(); >>>>> my $return = <$socket>; >>>>> $socket->close(); >>>>> } >>>>> >>>>> >>>>> 以上です。 >>>>> >>>>> >>>>> 2009/2/21 masahito ikuta <coo...@gm...>: >>>>>> 幾田です。 >>>>>> >>>>>> kai-users-ja に参加していなかった事をスッカリ忘れていて >>>>>> 先ほど、慌てて Subscribe しました。申し訳ございません。 >>>>>> >>>>>>>quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop >>>>>>>のいずれの場合にもマッチしないようです. >>>>>> >>>>>> 明日、障害の再現後、修正致します。 >>>>>> >>>>>>>> 橋本です。 >>>>>>>> >>>>>>>> 以前、"接続が問答無用で切断されるようになった" >>>>>>>> >>>>>>>というタイトルで質問させてもらいました。そのときは割り当てるファイルディスクリプタを大きくして解決したと思っていましたが、もしかしたら間違えていたかもしれません。 >>>>>>>> >>>>>>>> >>>>>>>statsの実装を進めていただいているので、ポーリングしてグラフ化するようにcactiのプラグインを動かしてみました。5分おきにstatsをポーリングするだけなのですが、一日ほど動かしただけで先日報告した"接続が問答無用で切断されるようになった" >>>>>>>> >>>>>>>と同じ状態になりました。監視のテストをしただけで実際にデータを突っ込んだりはしていません。今回はファイルディスクリプタの数を明示的に増やしたりはしていません。 >>>>>>>> >>>>>>>> >>>>>>>推測なのですが、kaiから切断するときにquitを送らずに、tcpを切断した場合に問題になるようなことはないでしょうか。先日も、今回のcactiのプラグインもkaiへのアクセスにはpeclのmemcache実装を使っています。 >>>>>>> >>>>>>>ちょっとテストしてみましたが,その推測通りっぽいです. >>>>>>>kai_tcp_server モジュールで処理フローが行方不明になっています.. >>>>>>> >>>>>>>cooldaemon 様: >>>>>>>ここ数日ほど出先で mac >>>>>>>しかなく,十分なチェックができないでいます. >>>>>>>quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop >>>>>>>のいずれの場合にもマッチしないようです. >>>>>>>ただし,mac の netstat >>>>>>>で確認したところ,サーバ側のソケットは正しく閉じられているように見えました. >>>>>>>可能なら,Linux でチェックしてみてください. >>>>>>> >>>>>>>> http://pecl.php.net/package/memcache >>>>>>>> >>>>>>>> >>>>>>>tcpdumpして確認したのですが、ソースコードで明示的にcloseを行ってもquitコマンドは発行していないようです。以前ご紹介したmcbだとちゃんとquitを送っているようです。そのため、このツールを使って負荷をかけた場合には問題が発生したなかったのではないかと推測しています。 >>>>>>>> >>>>>>>> http://www.interdb.jp/techinfo/mcb/index.html >>>>>>>> >>>>>>>> いかがでしょうか。 >>>>>>>> ------------------------------------------------------------------------------ >>>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>>>>>>> -Strategies to boost innovation and cut costs with open source participation >>>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD >>>>>>>> http://p.sf.net/sfu/XcvMzF8H >>>>>>>> _______________________________________________ >>>>>>>> Kai-users-ja mailing list >>>>>>>> Kai-users-ja@li... >>>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>-- >>>>>>>Takeru INOUE <takeru.inoue@gm...> >>>>>> >>>>>> -- >>>>>> cooldaemon >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> cooldaemon >>>>> ------------------------------------------------------------------------------ >>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>>>> -Strategies to boost innovation and cut costs with open source participation >>>>> -Receive a $600 discount off the registration fee with the source code: SFAD >>>>> http://p.sf.net/sfu/XcvMzF8H >>>>> _______________________________________________ >>>>> Kai-users-ja mailing list >>>>> Kai...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>>>> >>>> >>>> >>>> >>>> -- >>>> Takeru INOUE <tak...@gm...> >>>> >>> >>> >>> >>> -- >>> cooldaemon >>> >> >> >> >> -- >> cooldaemon >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >> -Strategies to boost innovation and cut costs with open source participation >> -Receive a $600 discount off the registration fee with the source code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Kai-users-ja mailing list >> Kai...@li... >> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >> > > > > -- > Takeru INOUE <tak...@gm...> > -- Takeru INOUE <tak...@gm...> |
From: Takeru I. <tak...@gm...> - 2009-02-23 13:41:34
|
必ず次のようなエラーになりますね (16383 回目の connect に失敗). Can not connect:16383 at test.pl line 14. 複数のクライアントを走らせた場合でも,合計の connect 数が 16383 になるとエラーになりました. Can not connect:7152 at test.pl line 14. Can not connect:9231 at test.pl line 14. どうやら,この magic number でリソースが足りなくなるようです. >> 今後は、Acceptor Pooling を止めるとどうなるか >> 試してみる予定です。 > > max_connection = 1 で試していた事を忘れていました。 > Yaws と Mochiweb の Source を見直してみます。 max_connection = 2 でも同じでした. 本家 ML に聞いてみた方がいいかも. 聞いときましょうか. > 2009/2/23 masahito ikuta <coo...@gm...>: >>> コミットされたらこちらでも確認してみますね. >> >> コミットするか否か迷っておりますので、お知恵を拝借させて下さい。 >> >> ▼修正後の状況 >> クライアントから切断された際 >> Active Mode では、メッセージとして {tcp_closed, Socket} が >> Passive Mode では、gen_tcp:recv/3 の戻り値として {error, closed} が >> それぞれ戻って来るのですが >> 両モード共に gen_tcp:close/1 を呼んだとしても >> ある一定回数以上 接続・切断を繰り替えすと >> 数秒間だけ接続できなくなります。 >> >> 以前の版と異なるのは、以下の三点です。 >> ・Erlang Shell ごと落ちない(そもそもプロセスが落ちなくなった) >> ・障害が発生させる為の 接続・切断 の回数が以前より多い(私の環境で 4 倍ほど) >> ・数秒経つと、また接続が可能となる >> >> ▼個人的な希望 >> 以前の状態よりは、マシな状態である為 >> trunk にコミットさせて頂けないでしょうか? >> >> ▼現在、調査して解っている箇所 >> Erlang Shell から i() で、接続できない状態のプロセスを確認すると >> 接続できる状態と同様に prim_inet:accept0/2 で待ち受けており >> gen_tcp:accept/2 で失敗しているようでもありませんでした。 >> >> gen_tcp:close/1 の戻り値を確認しても >> ok が戻されている為、正常に終了できているようでした。 >> >> ※もしかして、gen_tcp:close/1 って非同期で inet 関連のプロセスと通信してる? >> >> ちなみに、Active、Passive 両モード共に >> サーバ側から切断する分には全く問題が発生しません。 >> >> ※クライアントから切断するなんて、普通に行う事なんだけどなぁ・・・ >> >> gen_tcp のドキュメントを読み返しているのですが >> そもそも、ドキュメント内のサンプルコードでは >> {error, closed} を受信しても gen_tcp:close/1 を呼び出してすらいない為 >> 完全に手詰まりです。 >> >> 本メールにテストに必要なファイル一式を添付致しましたので >> いろいろお試し頂けると助かります。 >> >> 今後は、Acceptor Pooling を止めるとどうなるか >> 試してみる予定です。 >> >> 以上です。 >> >> 2009/2/22 Takeru INOUE <tak...@gm...>: >>> 深夜までお疲れ様でした m(_ _)m >>> >>> コミットされたらこちらでも確認してみますね. >>> >>> 2009/2/21 masahito ikuta <coo...@gm...>: >>>> 幾田です。 >>>> 原因が判明しました。 >>>> >>>> ▼対処 >>>> クライアントから切断された際の処理に gen_tcp:close/1 を加え >>>> 障害が再現しない事を確認しました。 >>>> >>>> 後で、コミットしておきます。 >>>> >>>> ▼障害内容 >>>> クライアントから切断されたのだから >>>> gen_tcp:close/1 は不要だろうと思い込んでいたのですが >>>> gen_tcp:close/1 は、諸々の後始末をしているようで >>>> これを呼ばずに、クライアント側で接続・切断を繰り返すと >>>> 一定回数後に、 Erlang Shell ごと落ちていました。 >>>> >>>> ▼検証用のクライアントコード >>>> kai_tcp_server で echo server を作り >>>> 下記の Perl Script で接続・切断を繰り返すと >>>> サーバが落ちます。 >>>> (対処済みのサーバは落ちませんでした) >>>> >>>> #!/usr/bin/env perl >>>> >>>> use strict; >>>> use warnings; >>>> >>>> use IO::Socket; >>>> >>>> for (1..10000) { >>>> test(); >>>> } >>>> >>>> sub test { >>>> my $socket = IO::Socket::INET->new( >>>> PeerAddr => 'localhost', >>>> PeerPort => 11211, >>>> Proto => 'tcp', >>>> ) or die 'Can not connect.'; >>>> >>>> $socket->print('aaa', "\r\n"); >>>> $socket->flush(); >>>> my $return = <$socket>; >>>> $socket->close(); >>>> } >>>> >>>> >>>> 以上です。 >>>> >>>> >>>> 2009/2/21 masahito ikuta <coo...@gm...>: >>>>> 幾田です。 >>>>> >>>>> kai-users-ja に参加していなかった事をスッカリ忘れていて >>>>> 先ほど、慌てて Subscribe しました。申し訳ございません。 >>>>> >>>>>>quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop >>>>>>のいずれの場合にもマッチしないようです. >>>>> >>>>> 明日、障害の再現後、修正致します。 >>>>> >>>>>>> 橋本です。 >>>>>>> >>>>>>> 以前、"接続が問答無用で切断されるようになった" >>>>>>> >>>>>>というタイトルで質問させてもらいました。そのときは割り当てるファイルディスクリプタを大きくして解決したと思っていましたが、もしかしたら間違えていたかもしれません。 >>>>>>> >>>>>>> >>>>>>statsの実装を進めていただいているので、ポーリングしてグラフ化するようにcactiのプラグインを動かしてみました。5分おきにstatsをポーリングするだけなのですが、一日ほど動かしただけで先日報告した"接続が問答無用で切断されるようになった" >>>>>>> >>>>>>と同じ状態になりました。監視のテストをしただけで実際にデータを突っ込んだりはしていません。今回はファイルディスクリプタの数を明示的に増やしたりはしていません。 >>>>>>> >>>>>>> >>>>>>推測なのですが、kaiから切断するときにquitを送らずに、tcpを切断した場合に問題になるようなことはないでしょうか。先日も、今回のcactiのプラグインもkaiへのアクセスにはpeclのmemcache実装を使っています。 >>>>>> >>>>>>ちょっとテストしてみましたが,その推測通りっぽいです. >>>>>>kai_tcp_server モジュールで処理フローが行方不明になっています.. >>>>>> >>>>>>cooldaemon 様: >>>>>>ここ数日ほど出先で mac >>>>>>しかなく,十分なチェックができないでいます. >>>>>>quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop >>>>>>のいずれの場合にもマッチしないようです. >>>>>>ただし,mac の netstat >>>>>>で確認したところ,サーバ側のソケットは正しく閉じられているように見えました. >>>>>>可能なら,Linux でチェックしてみてください. >>>>>> >>>>>>> http://pecl.php.net/package/memcache >>>>>>> >>>>>>> >>>>>>tcpdumpして確認したのですが、ソースコードで明示的にcloseを行ってもquitコマンドは発行していないようです。以前ご紹介したmcbだとちゃんとquitを送っているようです。そのため、このツールを使って負荷をかけた場合には問題が発生したなかったのではないかと推測しています。 >>>>>>> >>>>>>> http://www.interdb.jp/techinfo/mcb/index.html >>>>>>> >>>>>>> いかがでしょうか。 >>>>>>> ------------------------------------------------------------------------------ >>>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>>>>>> -Strategies to boost innovation and cut costs with open source participation >>>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD >>>>>>> http://p.sf.net/sfu/XcvMzF8H >>>>>>> _______________________________________________ >>>>>>> Kai-users-ja mailing list >>>>>>> Kai-users-ja@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>>-- >>>>>>Takeru INOUE <takeru.inoue@gm...> >>>>> >>>>> -- >>>>> cooldaemon >>>>> >>>> >>>> >>>> >>>> -- >>>> cooldaemon >>>> ------------------------------------------------------------------------------ >>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>>> -Strategies to boost innovation and cut costs with open source participation >>>> -Receive a $600 discount off the registration fee with the source code: SFAD >>>> http://p.sf.net/sfu/XcvMzF8H >>>> _______________________________________________ >>>> Kai-users-ja mailing list >>>> Kai...@li... >>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>>> >>> >>> >>> >>> -- >>> Takeru INOUE <tak...@gm...> >>> >> >> >> >> -- >> cooldaemon >> > > > > -- > cooldaemon > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Kai-users-ja mailing list > Kai...@li... > https://lists.sourceforge.net/lists/listinfo/kai-users-ja > -- Takeru INOUE <tak...@gm...> |
From: masahito i. <coo...@gm...> - 2009-02-23 12:18:49
|
> 今後は、Acceptor Pooling を止めるとどうなるか > 試してみる予定です。 max_connection = 1 で試していた事を忘れていました。 Yaws と Mochiweb の Source を見直してみます。 2009/2/23 masahito ikuta <coo...@gm...>: >> コミットされたらこちらでも確認してみますね. > > コミットするか否か迷っておりますので、お知恵を拝借させて下さい。 > > ▼修正後の状況 > クライアントから切断された際 > Active Mode では、メッセージとして {tcp_closed, Socket} が > Passive Mode では、gen_tcp:recv/3 の戻り値として {error, closed} が > それぞれ戻って来るのですが > 両モード共に gen_tcp:close/1 を呼んだとしても > ある一定回数以上 接続・切断を繰り替えすと > 数秒間だけ接続できなくなります。 > > 以前の版と異なるのは、以下の三点です。 > ・Erlang Shell ごと落ちない(そもそもプロセスが落ちなくなった) > ・障害が発生させる為の 接続・切断 の回数が以前より多い(私の環境で 4 倍ほど) > ・数秒経つと、また接続が可能となる > > ▼個人的な希望 > 以前の状態よりは、マシな状態である為 > trunk にコミットさせて頂けないでしょうか? > > ▼現在、調査して解っている箇所 > Erlang Shell から i() で、接続できない状態のプロセスを確認すると > 接続できる状態と同様に prim_inet:accept0/2 で待ち受けており > gen_tcp:accept/2 で失敗しているようでもありませんでした。 > > gen_tcp:close/1 の戻り値を確認しても > ok が戻されている為、正常に終了できているようでした。 > > ※もしかして、gen_tcp:close/1 って非同期で inet 関連のプロセスと通信してる? > > ちなみに、Active、Passive 両モード共に > サーバ側から切断する分には全く問題が発生しません。 > > ※クライアントから切断するなんて、普通に行う事なんだけどなぁ・・・ > > gen_tcp のドキュメントを読み返しているのですが > そもそも、ドキュメント内のサンプルコードでは > {error, closed} を受信しても gen_tcp:close/1 を呼び出してすらいない為 > 完全に手詰まりです。 > > 本メールにテストに必要なファイル一式を添付致しましたので > いろいろお試し頂けると助かります。 > > 今後は、Acceptor Pooling を止めるとどうなるか > 試してみる予定です。 > > 以上です。 > > 2009/2/22 Takeru INOUE <tak...@gm...>: >> 深夜までお疲れ様でした m(_ _)m >> >> コミットされたらこちらでも確認してみますね. >> >> 2009/2/21 masahito ikuta <coo...@gm...>: >>> 幾田です。 >>> 原因が判明しました。 >>> >>> ▼対処 >>> クライアントから切断された際の処理に gen_tcp:close/1 を加え >>> 障害が再現しない事を確認しました。 >>> >>> 後で、コミットしておきます。 >>> >>> ▼障害内容 >>> クライアントから切断されたのだから >>> gen_tcp:close/1 は不要だろうと思い込んでいたのですが >>> gen_tcp:close/1 は、諸々の後始末をしているようで >>> これを呼ばずに、クライアント側で接続・切断を繰り返すと >>> 一定回数後に、 Erlang Shell ごと落ちていました。 >>> >>> ▼検証用のクライアントコード >>> kai_tcp_server で echo server を作り >>> 下記の Perl Script で接続・切断を繰り返すと >>> サーバが落ちます。 >>> (対処済みのサーバは落ちませんでした) >>> >>> #!/usr/bin/env perl >>> >>> use strict; >>> use warnings; >>> >>> use IO::Socket; >>> >>> for (1..10000) { >>> test(); >>> } >>> >>> sub test { >>> my $socket = IO::Socket::INET->new( >>> PeerAddr => 'localhost', >>> PeerPort => 11211, >>> Proto => 'tcp', >>> ) or die 'Can not connect.'; >>> >>> $socket->print('aaa', "\r\n"); >>> $socket->flush(); >>> my $return = <$socket>; >>> $socket->close(); >>> } >>> >>> >>> 以上です。 >>> >>> >>> 2009/2/21 masahito ikuta <coo...@gm...>: >>>> 幾田です。 >>>> >>>> kai-users-ja に参加していなかった事をスッカリ忘れていて >>>> 先ほど、慌てて Subscribe しました。申し訳ございません。 >>>> >>>>>quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop >>>>>のいずれの場合にもマッチしないようです. >>>> >>>> 明日、障害の再現後、修正致します。 >>>> >>>>>> 橋本です。 >>>>>> >>>>>> 以前、"接続が問答無用で切断されるようになった" >>>>>> >>>>>というタイトルで質問させてもらいました。そのときは割り当てるファイルディスクリプタを大きくして解決したと思っていましたが、もしかしたら間違えていたかもしれません。 >>>>>> >>>>>> >>>>>statsの実装を進めていただいているので、ポーリングしてグラフ化するようにcactiのプラグインを動かしてみました。5分おきにstatsをポーリングするだけなのですが、一日ほど動かしただけで先日報告した"接続が問答無用で切断されるようになった" >>>>>> >>>>>と同じ状態になりました。監視のテストをしただけで実際にデータを突っ込んだりはしていません。今回はファイルディスクリプタの数を明示的に増やしたりはしていません。 >>>>>> >>>>>> >>>>>推測なのですが、kaiから切断するときにquitを送らずに、tcpを切断した場合に問題になるようなことはないでしょうか。先日も、今回のcactiのプラグインもkaiへのアクセスにはpeclのmemcache実装を使っています。 >>>>> >>>>>ちょっとテストしてみましたが,その推測通りっぽいです. >>>>>kai_tcp_server モジュールで処理フローが行方不明になっています.. >>>>> >>>>>cooldaemon 様: >>>>>ここ数日ほど出先で mac >>>>>しかなく,十分なチェックができないでいます. >>>>>quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop >>>>>のいずれの場合にもマッチしないようです. >>>>>ただし,mac の netstat >>>>>で確認したところ,サーバ側のソケットは正しく閉じられているように見えました. >>>>>可能なら,Linux でチェックしてみてください. >>>>> >>>>>> http://pecl.php.net/package/memcache >>>>>> >>>>>> >>>>>tcpdumpして確認したのですが、ソースコードで明示的にcloseを行ってもquitコマンドは発行していないようです。以前ご紹介したmcbだとちゃんとquitを送っているようです。そのため、このツールを使って負荷をかけた場合には問題が発生したなかったのではないかと推測しています。 >>>>>> >>>>>> http://www.interdb.jp/techinfo/mcb/index.html >>>>>> >>>>>> いかがでしょうか。 >>>>>> ------------------------------------------------------------------------------ >>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>>>>> -Strategies to boost innovation and cut costs with open source participation >>>>>> -Receive a $600 discount off the registration fee with the source code: SFAD >>>>>> http://p.sf.net/sfu/XcvMzF8H >>>>>> _______________________________________________ >>>>>> Kai-users-ja mailing list >>>>>> Kai-users-ja@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>>>>> >>>>> >>>>> >>>>> >>>>>-- >>>>>Takeru INOUE <takeru.inoue@gm...> >>>> >>>> -- >>>> cooldaemon >>>> >>> >>> >>> >>> -- >>> cooldaemon >>> ------------------------------------------------------------------------------ >>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>> -Strategies to boost innovation and cut costs with open source participation >>> -Receive a $600 discount off the registration fee with the source code: SFAD >>> http://p.sf.net/sfu/XcvMzF8H >>> _______________________________________________ >>> Kai-users-ja mailing list >>> Kai...@li... >>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>> >> >> >> >> -- >> Takeru INOUE <tak...@gm...> >> > > > > -- > cooldaemon > -- cooldaemon |
From: masahito i. <coo...@gm...> - 2009-02-23 08:59:05
|
> コミットされたらこちらでも確認してみますね. コミットするか否か迷っておりますので、お知恵を拝借させて下さい。 ▼修正後の状況 クライアントから切断された際 Active Mode では、メッセージとして {tcp_closed, Socket} が Passive Mode では、gen_tcp:recv/3 の戻り値として {error, closed} が それぞれ戻って来るのですが 両モード共に gen_tcp:close/1 を呼んだとしても ある一定回数以上 接続・切断を繰り替えすと 数秒間だけ接続できなくなります。 以前の版と異なるのは、以下の三点です。 ・Erlang Shell ごと落ちない(そもそもプロセスが落ちなくなった) ・障害が発生させる為の 接続・切断 の回数が以前より多い(私の環境で 4 倍ほど) ・数秒経つと、また接続が可能となる ▼個人的な希望 以前の状態よりは、マシな状態である為 trunk にコミットさせて頂けないでしょうか? ▼現在、調査して解っている箇所 Erlang Shell から i() で、接続できない状態のプロセスを確認すると 接続できる状態と同様に prim_inet:accept0/2 で待ち受けており gen_tcp:accept/2 で失敗しているようでもありませんでした。 gen_tcp:close/1 の戻り値を確認しても ok が戻されている為、正常に終了できているようでした。 ※もしかして、gen_tcp:close/1 って非同期で inet 関連のプロセスと通信してる? ちなみに、Active、Passive 両モード共に サーバ側から切断する分には全く問題が発生しません。 ※クライアントから切断するなんて、普通に行う事なんだけどなぁ・・・ gen_tcp のドキュメントを読み返しているのですが そもそも、ドキュメント内のサンプルコードでは {error, closed} を受信しても gen_tcp:close/1 を呼び出してすらいない為 完全に手詰まりです。 本メールにテストに必要なファイル一式を添付致しましたので いろいろお試し頂けると助かります。 今後は、Acceptor Pooling を止めるとどうなるか 試してみる予定です。 以上です。 2009/2/22 Takeru INOUE <tak...@gm...>: > 深夜までお疲れ様でした m(_ _)m > > コミットされたらこちらでも確認してみますね. > > 2009/2/21 masahito ikuta <coo...@gm...>: >> 幾田です。 >> 原因が判明しました。 >> >> ▼対処 >> クライアントから切断された際の処理に gen_tcp:close/1 を加え >> 障害が再現しない事を確認しました。 >> >> 後で、コミットしておきます。 >> >> ▼障害内容 >> クライアントから切断されたのだから >> gen_tcp:close/1 は不要だろうと思い込んでいたのですが >> gen_tcp:close/1 は、諸々の後始末をしているようで >> これを呼ばずに、クライアント側で接続・切断を繰り返すと >> 一定回数後に、 Erlang Shell ごと落ちていました。 >> >> ▼検証用のクライアントコード >> kai_tcp_server で echo server を作り >> 下記の Perl Script で接続・切断を繰り返すと >> サーバが落ちます。 >> (対処済みのサーバは落ちませんでした) >> >> #!/usr/bin/env perl >> >> use strict; >> use warnings; >> >> use IO::Socket; >> >> for (1..10000) { >> test(); >> } >> >> sub test { >> my $socket = IO::Socket::INET->new( >> PeerAddr => 'localhost', >> PeerPort => 11211, >> Proto => 'tcp', >> ) or die 'Can not connect.'; >> >> $socket->print('aaa', "\r\n"); >> $socket->flush(); >> my $return = <$socket>; >> $socket->close(); >> } >> >> >> 以上です。 >> >> >> 2009/2/21 masahito ikuta <coo...@gm...>: >>> 幾田です。 >>> >>> kai-users-ja に参加していなかった事をスッカリ忘れていて >>> 先ほど、慌てて Subscribe しました。申し訳ございません。 >>> >>>>quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop >>>>のいずれの場合にもマッチしないようです. >>> >>> 明日、障害の再現後、修正致します。 >>> >>>>> 橋本です。 >>>>> >>>>> 以前、"接続が問答無用で切断されるようになった" >>>>> >>>>というタイトルで質問させてもらいました。そのときは割り当てるファイルディスクリプタを大きくして解決したと思っていましたが、もしかしたら間違えていたかもしれません。 >>>>> >>>>> >>>>statsの実装を進めていただいているので、ポーリングしてグラフ化するようにcactiのプラグインを動かしてみました。5分おきにstatsをポーリングするだけなのですが、一日ほど動かしただけで先日報告した"接続が問答無用で切断されるようになった" >>>>> >>>>と同じ状態になりました。監視のテストをしただけで実際にデータを突っ込んだりはしていません。今回はファイルディスクリプタの数を明示的に増やしたりはしていません。 >>>>> >>>>> >>>>推測なのですが、kaiから切断するときにquitを送らずに、tcpを切断した場合に問題になるようなことはないでしょうか。先日も、今回のcactiのプラグインもkaiへのアクセスにはpeclのmemcache実装を使っています。 >>>> >>>>ちょっとテストしてみましたが,その推測通りっぽいです. >>>>kai_tcp_server モジュールで処理フローが行方不明になっています.. >>>> >>>>cooldaemon 様: >>>>ここ数日ほど出先で mac >>>>しかなく,十分なチェックができないでいます. >>>>quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop >>>>のいずれの場合にもマッチしないようです. >>>>ただし,mac の netstat >>>>で確認したところ,サーバ側のソケットは正しく閉じられているように見えました. >>>>可能なら,Linux でチェックしてみてください. >>>> >>>>> http://pecl.php.net/package/memcache >>>>> >>>>> >>>>tcpdumpして確認したのですが、ソースコードで明示的にcloseを行ってもquitコマンドは発行していないようです。以前ご紹介したmcbだとちゃんとquitを送っているようです。そのため、このツールを使って負荷をかけた場合には問題が発生したなかったのではないかと推測しています。 >>>>> >>>>> http://www.interdb.jp/techinfo/mcb/index.html >>>>> >>>>> いかがでしょうか。 >>>>> ------------------------------------------------------------------------------ >>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>>>> -Strategies to boost innovation and cut costs with open source participation >>>>> -Receive a $600 discount off the registration fee with the source code: SFAD >>>>> http://p.sf.net/sfu/XcvMzF8H >>>>> _______________________________________________ >>>>> Kai-users-ja mailing list >>>>> Kai-users-ja@li... >>>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>>>> >>>> >>>> >>>> >>>>-- >>>>Takeru INOUE <takeru.inoue@gm...> >>> >>> -- >>> cooldaemon >>> >> >> >> >> -- >> cooldaemon >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >> -Strategies to boost innovation and cut costs with open source participation >> -Receive a $600 discount off the registration fee with the source code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Kai-users-ja mailing list >> Kai...@li... >> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >> > > > > -- > Takeru INOUE <tak...@gm...> > -- cooldaemon |
From: Takeru I. <tak...@gm...> - 2009-02-22 03:04:01
|
深夜までお疲れ様でした m(_ _)m コミットされたらこちらでも確認してみますね. 2009/2/21 masahito ikuta <coo...@gm...>: > 幾田です。 > 原因が判明しました。 > > ▼対処 > クライアントから切断された際の処理に gen_tcp:close/1 を加え > 障害が再現しない事を確認しました。 > > 後で、コミットしておきます。 > > ▼障害内容 > クライアントから切断されたのだから > gen_tcp:close/1 は不要だろうと思い込んでいたのですが > gen_tcp:close/1 は、諸々の後始末をしているようで > これを呼ばずに、クライアント側で接続・切断を繰り返すと > 一定回数後に、 Erlang Shell ごと落ちていました。 > > ▼検証用のクライアントコード > kai_tcp_server で echo server を作り > 下記の Perl Script で接続・切断を繰り返すと > サーバが落ちます。 > (対処済みのサーバは落ちませんでした) > > #!/usr/bin/env perl > > use strict; > use warnings; > > use IO::Socket; > > for (1..10000) { > test(); > } > > sub test { > my $socket = IO::Socket::INET->new( > PeerAddr => 'localhost', > PeerPort => 11211, > Proto => 'tcp', > ) or die 'Can not connect.'; > > $socket->print('aaa', "\r\n"); > $socket->flush(); > my $return = <$socket>; > $socket->close(); > } > > > 以上です。 > > > 2009/2/21 masahito ikuta <coo...@gm...>: >> 幾田です。 >> >> kai-users-ja に参加していなかった事をスッカリ忘れていて >> 先ほど、慌てて Subscribe しました。申し訳ございません。 >> >>>quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop >>>のいずれの場合にもマッチしないようです. >> >> 明日、障害の再現後、修正致します。 >> >>>> 橋本です。 >>>> >>>> 以前、"接続が問答無用で切断されるようになった" >>>> >>>というタイトルで質問させてもらいました。そのときは割り当てるファイルディスクリプタを大きくして解決したと思っていましたが、もしかしたら間違えていたかもしれません。 >>>> >>>> >>>statsの実装を進めていただいているので、ポーリングしてグラフ化するようにcactiのプラグインを動かしてみました。5分おきにstatsをポーリングするだけなのですが、一日ほど動かしただけで先日報告した"接続が問答無用で切断されるようになった" >>>> >>>と同じ状態になりました。監視のテストをしただけで実際にデータを突っ込んだりはしていません。今回はファイルディスクリプタの数を明示的に増やしたりはしていません。 >>>> >>>> >>>推測なのですが、kaiから切断するときにquitを送らずに、tcpを切断した場合に問題になるようなことはないでしょうか。先日も、今回のcactiのプラグインもkaiへのアクセスにはpeclのmemcache実装を使っています。 >>> >>>ちょっとテストしてみましたが,その推測通りっぽいです. >>>kai_tcp_server モジュールで処理フローが行方不明になっています.. >>> >>>cooldaemon 様: >>>ここ数日ほど出先で mac >>>しかなく,十分なチェックができないでいます. >>>quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop >>>のいずれの場合にもマッチしないようです. >>>ただし,mac の netstat >>>で確認したところ,サーバ側のソケットは正しく閉じられているように見えました. >>>可能なら,Linux でチェックしてみてください. >>> >>>> http://pecl.php.net/package/memcache >>>> >>>> >>>tcpdumpして確認したのですが、ソースコードで明示的にcloseを行ってもquitコマンドは発行していないようです。以前ご紹介したmcbだとちゃんとquitを送っているようです。そのため、このツールを使って負荷をかけた場合には問題が発生したなかったのではないかと推測しています。 >>>> >>>> http://www.interdb.jp/techinfo/mcb/index.html >>>> >>>> いかがでしょうか。 >>>> ------------------------------------------------------------------------------ >>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>>> -Strategies to boost innovation and cut costs with open source participation >>>> -Receive a $600 discount off the registration fee with the source code: SFAD >>>> http://p.sf.net/sfu/XcvMzF8H >>>> _______________________________________________ >>>> Kai-users-ja mailing list >>>> Kai-users-ja@li... >>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>>> >>> >>> >>> >>>-- >>>Takeru INOUE <takeru.inoue@gm...> >> >> -- >> cooldaemon >> > > > > -- > cooldaemon > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Kai-users-ja mailing list > Kai...@li... > https://lists.sourceforge.net/lists/listinfo/kai-users-ja > -- Takeru INOUE <tak...@gm...> |
From: masahito i. <coo...@gm...> - 2009-02-20 19:31:51
|
幾田です。 原因が判明しました。 ▼対処 クライアントから切断された際の処理に gen_tcp:close/1 を加え 障害が再現しない事を確認しました。 後で、コミットしておきます。 ▼障害内容 クライアントから切断されたのだから gen_tcp:close/1 は不要だろうと思い込んでいたのですが gen_tcp:close/1 は、諸々の後始末をしているようで これを呼ばずに、クライアント側で接続・切断を繰り返すと 一定回数後に、 Erlang Shell ごと落ちていました。 ▼検証用のクライアントコード kai_tcp_server で echo server を作り 下記の Perl Script で接続・切断を繰り返すと サーバが落ちます。 (対処済みのサーバは落ちませんでした) #!/usr/bin/env perl use strict; use warnings; use IO::Socket; for (1..10000) { test(); } sub test { my $socket = IO::Socket::INET->new( PeerAddr => 'localhost', PeerPort => 11211, Proto => 'tcp', ) or die 'Can not connect.'; $socket->print('aaa', "\r\n"); $socket->flush(); my $return = <$socket>; $socket->close(); } 以上です。 2009/2/21 masahito ikuta <coo...@gm...>: > 幾田です。 > > kai-users-ja に参加していなかった事をスッカリ忘れていて > 先ほど、慌てて Subscribe しました。申し訳ございません。 > >>quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop >>のいずれの場合にもマッチしないようです. > > 明日、障害の再現後、修正致します。 > >>> 橋本です。 >>> >>> 以前、"接続が問答無用で切断されるようになった" >>> >>というタイトルで質問させてもらいました。そのときは割り当てるファイルディスクリプタを大きくして解決したと思っていましたが、もしかしたら間違えていたかもしれません。 >>> >>> >>statsの実装を進めていただいているので、ポーリングしてグラフ化するようにcactiのプラグインを動かしてみました。5分おきにstatsをポーリングするだけなのですが、一日ほど動かしただけで先日報告した"接続が問答無用で切断されるようになった" >>> >>と同じ状態になりました。監視のテストをしただけで実際にデータを突っ込んだりはしていません。今回はファイルディスクリプタの数を明示的に増やしたりはしていません。 >>> >>> >>推測なのですが、kaiから切断するときにquitを送らずに、tcpを切断した場合に問題になるようなことはないでしょうか。先日も、今回のcactiのプラグインもkaiへのアクセスにはpeclのmemcache実装を使っています。 >> >>ちょっとテストしてみましたが,その推測通りっぽいです. >>kai_tcp_server モジュールで処理フローが行方不明になっています.. >> >>cooldaemon 様: >>ここ数日ほど出先で mac >>しかなく,十分なチェックができないでいます. >>quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop >>のいずれの場合にもマッチしないようです. >>ただし,mac の netstat >>で確認したところ,サーバ側のソケットは正しく閉じられているように見えました. >>可能なら,Linux でチェックしてみてください. >> >>> http://pecl.php.net/package/memcache >>> >>> >>tcpdumpして確認したのですが、ソースコードで明示的にcloseを行ってもquitコマンドは発行していないようです。以前ご紹介したmcbだとちゃんとquitを送っているようです。そのため、このツールを使って負荷をかけた場合には問題が発生したなかったのではないかと推測しています。 >>> >>> http://www.interdb.jp/techinfo/mcb/index.html >>> >>> いかがでしょうか。 >>> ------------------------------------------------------------------------------ >>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>> -Strategies to boost innovation and cut costs with open source participation >>> -Receive a $600 discount off the registration fee with the source code: SFAD >>> http://p.sf.net/sfu/XcvMzF8H >>> _______________________________________________ >>> Kai-users-ja mailing list >>> Kai-users-ja@li... >>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>> >> >> >> >>-- >>Takeru INOUE <takeru.inoue@gm...> > > -- > cooldaemon > -- cooldaemon |
From: masahito i. <coo...@gm...> - 2009-02-20 15:37:24
|
幾田です。 kai-users-ja に参加していなかった事をスッカリ忘れていて 先ほど、慌てて Subscribe しました。申し訳ございません。 >quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop >のいずれの場合にもマッチしないようです. 明日、障害の再現後、修正致します。 >> 橋本です。 >> >> 以前、"接続が問答無用で切断されるようになった" >> >というタイトルで質問させてもらいました。そのときは割り当てるファイルディスクリプタを大きくして解決したと思っていましたが、もしかしたら間違えていたかもしれません。 >> >> >statsの実装を進めていただいているので、ポーリングしてグラフ化するようにcactiのプラグインを動かしてみました。5分おきにstatsをポーリングするだけなのですが、一日ほど動かしただけで先日報告した"接続が問答無用で切断されるようになった" >> >と同じ状態になりました。監視のテストをしただけで実際にデータを突っ込んだりはしていません。今回はファイルディスクリプタの数を明示的に増やしたりはしていません。 >> >> >推測なのですが、kaiから切断するときにquitを送らずに、tcpを切断した場合に問題になるようなことはないでしょうか。先日も、今回のcactiのプラグインもkaiへのアクセスにはpeclのmemcache実装を使っています。 > >ちょっとテストしてみましたが,その推測通りっぽいです. >kai_tcp_server モジュールで処理フローが行方不明になっています.. > >cooldaemon 様: >ここ数日ほど出先で mac >しかなく,十分なチェックができないでいます. >quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop >のいずれの場合にもマッチしないようです. >ただし,mac の netstat >で確認したところ,サーバ側のソケットは正しく閉じられているように見えました. >可能なら,Linux でチェックしてみてください. > >> http://pecl.php.net/package/memcache >> >> >tcpdumpして確認したのですが、ソースコードで明示的にcloseを行ってもquitコマンドは発行していないようです。以前ご紹介したmcbだとちゃんとquitを送っているようです。そのため、このツールを使って負荷をかけた場合には問題が発生したなかったのではないかと推測しています。 >> >> http://www.interdb.jp/techinfo/mcb/index.html >> >> いかがでしょうか。 >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >> -Strategies to boost innovation and cut costs with open source participation >> -Receive a $600 discount off the registration fee with the source code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Kai-users-ja mailing list >> Kai-users-ja@li... >> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >> > > > >-- >Takeru INOUE <takeru.inoue@gm...> -- cooldaemon |
From: Takeru I. <tak...@gm...> - 2009-02-19 14:30:46
|
2009/2/19 Tomoya Hashimoto <tom...@gm...>: > 橋本です。 > > 以前、"接続が問答無用で切断されるようになった" > というタイトルで質問させてもらいました。そのときは割り当てるファイルディスクリプタを大きくして解決したと思っていましたが、もしかしたら間違えていたかもしれません。 > > statsの実装を進めていただいているので、ポーリングしてグラフ化するようにcactiのプラグインを動かしてみました。5分おきにstatsをポーリングするだけなのですが、一日ほど動かしただけで先日報告した"接続が問答無用で切断されるようになった" > と同じ状態になりました。監視のテストをしただけで実際にデータを突っ込んだりはしていません。今回はファイルディスクリプタの数を明示的に増やしたりはしていません。 > > 推測なのですが、kaiから切断するときにquitを送らずに、tcpを切断した場合に問題になるようなことはないでしょうか。先日も、今回のcactiのプラグインもkaiへのアクセスにはpeclのmemcache実装を使っています。 ちょっとテストしてみましたが,その推測通りっぽいです. kai_tcp_server モジュールで処理フローが行方不明になっています.. cooldaemon 様: ここ数日ほど出先で mac しかなく,十分なチェックができないでいます. quit なしに TCP を切断すると,kai_tcp_server:acceptor_loop のいずれの場合にもマッチしないようです. ただし,mac の netstat で確認したところ,サーバ側のソケットは正しく閉じられているように見えました. 可能なら,Linux でチェックしてみてください. > http://pecl.php.net/package/memcache > > tcpdumpして確認したのですが、ソースコードで明示的にcloseを行ってもquitコマンドは発行していないようです。以前ご紹介したmcbだとちゃんとquitを送っているようです。そのため、このツールを使って負荷をかけた場合には問題が発生したなかったのではないかと推測しています。 > > http://www.interdb.jp/techinfo/mcb/index.html > > いかがでしょうか。 > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Kai-users-ja mailing list > Kai...@li... > https://lists.sourceforge.net/lists/listinfo/kai-users-ja > -- Takeru INOUE <tak...@gm...> |
From: Tomoya H. <tom...@gm...> - 2009-02-19 03:33:18
|
橋本です。 以前、"接続が問答無用で切断されるようになった" というタイトルで質問させてもらいました。そのときは割り当てるファイルディスクリプタを大きくして解決したと思っていましたが、もしかしたら間違えていたかもしれません。 statsの実装を進めていただいているので、ポーリングしてグラフ化するようにcactiのプラグインを動かしてみました。5分おきにstatsをポーリングするだけなのですが、一日ほど動かしただけで先日報告した"接続が問答無用で切断されるようになった" と同じ状態になりました。監視のテストをしただけで実際にデータを突っ込んだりはしていません。今回はファイルディスクリプタの数を明示的に増やしたりはしていません。 推測なのですが、kaiから切断するときにquitを送らずに、tcpを切断した場合に問題になるようなことはないでしょうか。先日も、今回のcactiのプラグインもkaiへのアクセスにはpeclのmemcache実装を使っています。 http://pecl.php.net/package/memcache tcpdumpして確認したのですが、ソースコードで明示的にcloseを行ってもquitコマンドは発行していないようです。以前ご紹介したmcbだとちゃんとquitを送っているようです。そのため、このツールを使って負荷をかけた場合には問題が発生したなかったのではないかと推測しています。 http://www.interdb.jp/techinfo/mcb/index.html いかがでしょうか。 |
From: Takeru I. <tak...@gm...> - 2009-02-17 13:16:53
|
2009/2/17 Tomoya Hashimoto <tom...@gm...>: > 橋本です。 > > 井上さん、しのはらさん、ありがとうございました。とりあえず8ノードで起動しました。 > {n,8} はノードの"n"だと誤解して8を書いていました。3になおして、hostnameはコメントアウトして無事に動きました。 おぉ,よかったです. > 実際の運用ではノード毎に微妙に内容の違うファイルを管理することは最大限避けます。ですのでhostnameを指定することはないと思います。そんなことを考えているうちにhostnameは必要ないのでは、と思ったりします。 ネットワークカードを複数持つコンピュータがあったときに,ID として使いたいアドレスを指定できるように作ってあります. ほとんどの場合は設定しないでも大丈夫ですね. > 2009/02/16 23:12 Takeru INOUE <tak...@gm...>: >> 井上です. >> >> 昨年末に「join の方法を簡単にする」と言ったきり,放置していてすみません m(_ _)m >> やろうやろうと思ってはいるのですが,データ同期の高速化とまとめてやろうとしていて,後回しになってしまっています. >> なるべく早くに取り組みます. >> >>> 8台のサーバでクラスターを組もうとしているのですが、いまいち設定方法がわかりません。 >>> >>> configには以下のように書いています。 >>> >>> [{kai, [ >>> % {logfile, "kai.log"}, >>> {hostname, "hmd000"}, >>> {rpc_port, 14010}, >>> {rpc_max_processes, 30}, >>> {memcache_port, 14011}, >>> {memcache_max_processes, 10}, >>> {max_connections, 32}, >>> {n, 8}, >>> {r, 2}, >>> {w, 2}, >>> {number_of_buckets, 1024}, >>> {number_of_virtual_nodes, 128}, >>> {store, dets}, >>> {dets_dir, "/data/kai"}, >>> {number_of_tables, 256} >>> ]}]. >> >> hostname の値はすべてのノードで違えていますでしょうか. >> それぞれで別のホスト名を設定するか,コメントアウトしてください. >> コメントアウトすると,hostname コマンドのホスト名が使われます. >> >>> 172.20.200.16 〜 .23 までの8台のサーバがあって、check_nodeは以下の様になるのかと思っています。 >>> >>> kai_rpc:check_node({{172,20,200,16}, 14010}, {{172,20,200,17}, 14010}). >>> kai_rpc:check_node({{172,20,200,17}, 14010}, {{172,20,200,18}, 14010}). >>> kai_rpc:check_node({{172,20,200,18}, 14010}, {{172,20,200,19}, 14010}). >>> kai_rpc:check_node({{172,20,200,19}, 14010}, {{172,20,200,20}, 14010}). >>> kai_rpc:check_node({{172,20,200,20}, 14010}, {{172,20,200,21}, 14010}). >>> kai_rpc:check_node({{172,20,200,21}, 14010}, {{172,20,200,22}, 14010}). >>> kai_rpc:check_node({{172,20,200,22}, 14010}, {{172,20,200,23}, 14010}). >>> kai_rpc:check_node({{172,20,200,23}, 14010}, {{172,20,200,17}, 14010}). >>> >>> これを8台のうちの1台で実行したのですが、うまくいっていない感じです。以下のようなメッセージが >>> 延々と流れます。 >>> >>> 2009-02-16 20:26:13.316081 [info] (<0.42.0>) ./kai_hash.erl:183: {update, >>> [{{{172,20, >>> 200,22}, >>> 14010}, >>> >>> [{number_of_virtual_nodes, >>> 128}]}], >> >> ひょっとしたら,hmd000 というホスト名のアドレスが,172.20.200.22 でしょうか. >> クラスタ内に 1台のホストしか存在しないように見えているのだと思います. >> >> >>> そもそもやり方が正しいのかいまいち自信がないのですが、いかがでしょうか。 >>> >>> ------------------------------------------------------------------------------ >>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >>> -Strategies to boost innovation and cut costs with open source participation >>> -Receive a $600 discount off the registration fee with the source code: SFAD >>> http://p.sf.net/sfu/XcvMzF8H >>> _______________________________________________ >>> Kai-users-ja mailing list >>> Kai...@li... >>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>> >> >> >> >> -- >> Takeru INOUE <tak...@gm...> >> > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Kai-users-ja mailing list > Kai...@li... > https://lists.sourceforge.net/lists/listinfo/kai-users-ja > -- Takeru INOUE <tak...@gm...> |
From: Tomoya H. <tom...@gm...> - 2009-02-17 04:05:19
|
橋本です。 井上さん、しのはらさん、ありがとうございました。とりあえず8ノードで起動しました。 {n,8} はノードの"n"だと誤解して8を書いていました。3になおして、hostnameはコメントアウトして無事に動きました。 実際の運用ではノード毎に微妙に内容の違うファイルを管理することは最大限避けます。ですのでhostnameを指定することはないと思います。そんなことを考えているうちにhostnameは必要ないのでは、と思ったりします。 2009/02/16 23:12 Takeru INOUE <tak...@gm...>: > 井上です. > > 昨年末に「join の方法を簡単にする」と言ったきり,放置していてすみません m(_ _)m > やろうやろうと思ってはいるのですが,データ同期の高速化とまとめてやろうとしていて,後回しになってしまっています. > なるべく早くに取り組みます. > >> 8台のサーバでクラスターを組もうとしているのですが、いまいち設定方法がわかりません。 >> >> configには以下のように書いています。 >> >> [{kai, [ >> % {logfile, "kai.log"}, >> {hostname, "hmd000"}, >> {rpc_port, 14010}, >> {rpc_max_processes, 30}, >> {memcache_port, 14011}, >> {memcache_max_processes, 10}, >> {max_connections, 32}, >> {n, 8}, >> {r, 2}, >> {w, 2}, >> {number_of_buckets, 1024}, >> {number_of_virtual_nodes, 128}, >> {store, dets}, >> {dets_dir, "/data/kai"}, >> {number_of_tables, 256} >> ]}]. > > hostname の値はすべてのノードで違えていますでしょうか. > それぞれで別のホスト名を設定するか,コメントアウトしてください. > コメントアウトすると,hostname コマンドのホスト名が使われます. > >> 172.20.200.16 〜 .23 までの8台のサーバがあって、check_nodeは以下の様になるのかと思っています。 >> >> kai_rpc:check_node({{172,20,200,16}, 14010}, {{172,20,200,17}, 14010}). >> kai_rpc:check_node({{172,20,200,17}, 14010}, {{172,20,200,18}, 14010}). >> kai_rpc:check_node({{172,20,200,18}, 14010}, {{172,20,200,19}, 14010}). >> kai_rpc:check_node({{172,20,200,19}, 14010}, {{172,20,200,20}, 14010}). >> kai_rpc:check_node({{172,20,200,20}, 14010}, {{172,20,200,21}, 14010}). >> kai_rpc:check_node({{172,20,200,21}, 14010}, {{172,20,200,22}, 14010}). >> kai_rpc:check_node({{172,20,200,22}, 14010}, {{172,20,200,23}, 14010}). >> kai_rpc:check_node({{172,20,200,23}, 14010}, {{172,20,200,17}, 14010}). >> >> これを8台のうちの1台で実行したのですが、うまくいっていない感じです。以下のようなメッセージが >> 延々と流れます。 >> >> 2009-02-16 20:26:13.316081 [info] (<0.42.0>) ./kai_hash.erl:183: {update, >> [{{{172,20, >> 200,22}, >> 14010}, >> >> [{number_of_virtual_nodes, >> 128}]}], > > ひょっとしたら,hmd000 というホスト名のアドレスが,172.20.200.22 でしょうか. > クラスタ内に 1台のホストしか存在しないように見えているのだと思います. > > >> そもそもやり方が正しいのかいまいち自信がないのですが、いかがでしょうか。 >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise >> -Strategies to boost innovation and cut costs with open source participation >> -Receive a $600 discount off the registration fee with the source code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Kai-users-ja mailing list >> Kai...@li... >> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >> > > > > -- > Takeru INOUE <tak...@gm...> > |
From: shunichi s. <shi...@gm...> - 2009-02-16 22:58:40
|
しのはらです。 2009/2/16 Takeru INOUE <tak...@gm...>: > # やはり設定名を {quorum, 3, 2 , 2} に変更するかな.. Dyanmo を知っていることは前提ではないとおもうので、quorum でまとめるほうが 分かりやすいですね。 > kai_hash:update_nodes の引数なら,1 で統一されていると思う. > さすがに,ここがずれていると複数ノードでまったく動作しないので,テストで気づくかなと. ごめんなさい、誤読でした m(_ _)m -- shino |
From: Takeru I. <tak...@gm...> - 2009-02-16 14:53:16
|
2009/2/16 shunichi shinohara <shi...@gm...>: > しのはらです。 > > 2009/2/16 Takeru INOUE <tak...@gm...>: >> 井上です. >> >> 昨年末に「join の方法を簡単にする」と言ったきり,放置していてすみません m(_ _)m >> やろうやろうと思ってはいるのですが,データ同期の高速化とまとめてやろうとしていて,後回しになってしまっています. >> なるべく早くに取り組みます. >> >>> 8台のサーバでクラスターを組もうとしているのですが、いまいち設定方法がわかりません。 >>> >>> configには以下のように書いています。 >>> >>> [{kai, [ >>> % {logfile, "kai.log"}, >>> {hostname, "hmd000"}, >>> {rpc_port, 14010}, >>> {rpc_max_processes, 30}, >>> {memcache_port, 14011}, >>> {memcache_max_processes, 10}, >>> {max_connections, 32}, >>> {n, 8}, >>> {r, 2}, >>> {w, 2}, >>> {number_of_buckets, 1024}, >>> {number_of_virtual_nodes, 128}, >>> {store, dets}, >>> {dets_dir, "/data/kai"}, >>> {number_of_tables, 256} >>> ]}]. >> >> hostname の値はすべてのノードで違えていますでしょうか. >> それぞれで別のホスト名を設定するか,コメントアウトしてください. >> コメントアウトすると,hostname コマンドのホスト名が使われます. > > 今回の問題とは関係ないですが、 n は 3 を意図しているのかな?とおもいました。 > n は全体のノード数ではなくてデータのレプリカの数になります。 > # あまり良い名前ではないのかな? その通りです. n は複製数です. クラスタを構成するノード数は設定する必要がありません. # やはり設定名を {quorum, 3, 2 , 2} に変更するかな.. >>> 延々と流れます。 >>> >>> 2009-02-16 20:26:13.316081 [info] (<0.42.0>) ./kai_hash.erl:183: {update, >>> [{{{172,20, >>> 200,22}, >>> 14010}, >>> >>> [{number_of_virtual_nodes, >>> 128}]}], >> > > ちょっとソースをおっていたのですが、update_node に入るパターン 2 つでノード情報の > 形式がずれているようにおもいます。 > 1. 一発目 kai_hash:init > [{{IP,Port}, Info}] > 2. 定期的なほう kai_membershipretreive_node_list -> kai_hash:node_list > [{IP,Port}] > > ぱっと見て、1 を修正するか、と思ったら、kai_hash:add_nodes/1 は 1. の形を > 期待しているみたいなので、 2 を修正する必要があることに気がつきました。 > # もしくは、add_nodes/1 も変更する。 > > どこまで絡んでいるかわかりませんが、ひとまず備忘として。 kai_hash:update_nodes の引数なら,1 で統一されていると思う. さすがに,ここがずれていると複数ノードでまったく動作しないので,テストで気づくかなと. -- Takeru INOUE <tak...@gm...> |
From: shunichi s. <shi...@gm...> - 2009-02-16 14:37:15
|
しのはらです。 2009/2/16 Takeru INOUE <tak...@gm...>: > 井上です. > > 昨年末に「join の方法を簡単にする」と言ったきり,放置していてすみません m(_ _)m > やろうやろうと思ってはいるのですが,データ同期の高速化とまとめてやろうとしていて,後回しになってしまっています. > なるべく早くに取り組みます. > >> 8台のサーバでクラスターを組もうとしているのですが、いまいち設定方法がわかりません。 >> >> configには以下のように書いています。 >> >> [{kai, [ >> % {logfile, "kai.log"}, >> {hostname, "hmd000"}, >> {rpc_port, 14010}, >> {rpc_max_processes, 30}, >> {memcache_port, 14011}, >> {memcache_max_processes, 10}, >> {max_connections, 32}, >> {n, 8}, >> {r, 2}, >> {w, 2}, >> {number_of_buckets, 1024}, >> {number_of_virtual_nodes, 128}, >> {store, dets}, >> {dets_dir, "/data/kai"}, >> {number_of_tables, 256} >> ]}]. > > hostname の値はすべてのノードで違えていますでしょうか. > それぞれで別のホスト名を設定するか,コメントアウトしてください. > コメントアウトすると,hostname コマンドのホスト名が使われます. 今回の問題とは関係ないですが、 n は 3 を意図しているのかな?とおもいました。 n は全体のノード数ではなくてデータのレプリカの数になります。 # あまり良い名前ではないのかな? >> 延々と流れます。 >> >> 2009-02-16 20:26:13.316081 [info] (<0.42.0>) ./kai_hash.erl:183: {update, >> [{{{172,20, >> 200,22}, >> 14010}, >> >> [{number_of_virtual_nodes, >> 128}]}], > ちょっとソースをおっていたのですが、update_node に入るパターン 2 つでノード情報の 形式がずれているようにおもいます。 1. 一発目 kai_hash:init [{{IP,Port}, Info}] 2. 定期的なほう kai_membershipretreive_node_list -> kai_hash:node_list [{IP,Port}] ぱっと見て、1 を修正するか、と思ったら、kai_hash:add_nodes/1 は 1. の形を 期待しているみたいなので、 2 を修正する必要があることに気がつきました。 # もしくは、add_nodes/1 も変更する。 どこまで絡んでいるかわかりませんが、ひとまず備忘として。 -- shino |
From: Takeru I. <tak...@gm...> - 2009-02-16 14:12:36
|
井上です. 昨年末に「join の方法を簡単にする」と言ったきり,放置していてすみません m(_ _)m やろうやろうと思ってはいるのですが,データ同期の高速化とまとめてやろうとしていて,後回しになってしまっています. なるべく早くに取り組みます. > 8台のサーバでクラスターを組もうとしているのですが、いまいち設定方法がわかりません。 > > configには以下のように書いています。 > > [{kai, [ > % {logfile, "kai.log"}, > {hostname, "hmd000"}, > {rpc_port, 14010}, > {rpc_max_processes, 30}, > {memcache_port, 14011}, > {memcache_max_processes, 10}, > {max_connections, 32}, > {n, 8}, > {r, 2}, > {w, 2}, > {number_of_buckets, 1024}, > {number_of_virtual_nodes, 128}, > {store, dets}, > {dets_dir, "/data/kai"}, > {number_of_tables, 256} > ]}]. hostname の値はすべてのノードで違えていますでしょうか. それぞれで別のホスト名を設定するか,コメントアウトしてください. コメントアウトすると,hostname コマンドのホスト名が使われます. > 172.20.200.16 〜 .23 までの8台のサーバがあって、check_nodeは以下の様になるのかと思っています。 > > kai_rpc:check_node({{172,20,200,16}, 14010}, {{172,20,200,17}, 14010}). > kai_rpc:check_node({{172,20,200,17}, 14010}, {{172,20,200,18}, 14010}). > kai_rpc:check_node({{172,20,200,18}, 14010}, {{172,20,200,19}, 14010}). > kai_rpc:check_node({{172,20,200,19}, 14010}, {{172,20,200,20}, 14010}). > kai_rpc:check_node({{172,20,200,20}, 14010}, {{172,20,200,21}, 14010}). > kai_rpc:check_node({{172,20,200,21}, 14010}, {{172,20,200,22}, 14010}). > kai_rpc:check_node({{172,20,200,22}, 14010}, {{172,20,200,23}, 14010}). > kai_rpc:check_node({{172,20,200,23}, 14010}, {{172,20,200,17}, 14010}). > > これを8台のうちの1台で実行したのですが、うまくいっていない感じです。以下のようなメッセージが > 延々と流れます。 > > 2009-02-16 20:26:13.316081 [info] (<0.42.0>) ./kai_hash.erl:183: {update, > [{{{172,20, > 200,22}, > 14010}, > > [{number_of_virtual_nodes, > 128}]}], ひょっとしたら,hmd000 というホスト名のアドレスが,172.20.200.22 でしょうか. クラスタ内に 1台のホストしか存在しないように見えているのだと思います. > そもそもやり方が正しいのかいまいち自信がないのですが、いかがでしょうか。 > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Kai-users-ja mailing list > Kai...@li... > https://lists.sourceforge.net/lists/listinfo/kai-users-ja > -- Takeru INOUE <tak...@gm...> |
From: Tomoya H. <tom...@gm...> - 2009-02-16 11:27:44
|
橋本です。 8台のサーバでクラスターを組もうとしているのですが、いまいち設定方法がわかりません。 configには以下のように書いています。 [{kai, [ % {logfile, "kai.log"}, {hostname, "hmd000"}, {rpc_port, 14010}, {rpc_max_processes, 30}, {memcache_port, 14011}, {memcache_max_processes, 10}, {max_connections, 32}, {n, 8}, {r, 2}, {w, 2}, {number_of_buckets, 1024}, {number_of_virtual_nodes, 128}, {store, dets}, {dets_dir, "/data/kai"}, {number_of_tables, 256} ]}]. 172.20.200.16 〜 .23 までの8台のサーバがあって、check_nodeは以下の様になるのかと思っています。 kai_rpc:check_node({{172,20,200,16}, 14010}, {{172,20,200,17}, 14010}). kai_rpc:check_node({{172,20,200,17}, 14010}, {{172,20,200,18}, 14010}). kai_rpc:check_node({{172,20,200,18}, 14010}, {{172,20,200,19}, 14010}). kai_rpc:check_node({{172,20,200,19}, 14010}, {{172,20,200,20}, 14010}). kai_rpc:check_node({{172,20,200,20}, 14010}, {{172,20,200,21}, 14010}). kai_rpc:check_node({{172,20,200,21}, 14010}, {{172,20,200,22}, 14010}). kai_rpc:check_node({{172,20,200,22}, 14010}, {{172,20,200,23}, 14010}). kai_rpc:check_node({{172,20,200,23}, 14010}, {{172,20,200,17}, 14010}). これを8台のうちの1台で実行したのですが、うまくいっていない感じです。以下のようなメッセージが 延々と流れます。 2009-02-16 20:26:13.316081 [info] (<0.42.0>) ./kai_hash.erl:183: {update, [{{{172,20, 200,22}, 14010}, [{number_of_virtual_nodes, 128}]}], そもそもやり方が正しいのかいまいち自信がないのですが、いかがでしょうか。 |
From: Takeru I. <tak...@gm...> - 2009-02-08 14:35:05
|
kai/branches/takemaru_stats/ に stats コマンドを実装してみました. 統計値の一覧は次の通りです. なお,memcache と意味が同じものについては説明していません. # 「そのノード」というのは stats を受信したノードのことです. uptime time version: Kai バージョン bytes: ローカルストレージのデータ量 (ガベージコレクション適用前) curr_items cmd_get: そのノードへの get のうち,成功した数 cmd_set: そのノードへの set のうち,成功した数 bytes_read: そのノードへの get により転送されたバイト数 bytes_write: そのノードへの set により転送されたバイト数 kai_node: そのノードを識別するためのソケットアドレス (内部 RPC 用ソケットアドレス) kai_quorum: 複製数と読み書き数 (N,R,W のこと) kai_number_of_buckets: consistent hashing のバケット数 kai_number_of_virtual_nodes: そのノードにおける consistent hashing の仮想ノード数 kai_store: ローカルストレージの種類 (ets or dets) kai_curr_nodes: クラスタを構成しているノード一覧 erlang_procs: Erlang プロセス数 erlang_version: Erlang バージョン # curr_connections と二つのバージョンが返ってしまった数の累計は少々お待ちください. 2009/1/27 Takeru INOUE <ino...@la...>: > ありがとうございます. > > まずは,状態管理が不要なもの (オブジェクトサイズ数) などから実装していこ > うと思います.それを正しく実装できたら,get の累計のように状態管理が必要 > なものにとりかかるのがよさそうですね. > > > Tomoya Hashimoto さんは書きました: >> 橋本です。 >> >> Kaiを運用していく上で必要になるのではないかと思う統計情報などを考えてみました。 >> >> ■ 統計的情報 >> >> 以下の情報がないと、投資判断とか利用状況の改善が測れないと思います。 >> >> その時点のクライアントの接続数 >> getの累計 >> setの累計 >> deleteの累計 >> オブジェクトの総数 >> オブジェクトのサイズ合計 >> 二つのバージョンが返ってしまった数の累計 >> 送信したbyteの累計 >> 受信したbyteの累計 >> >> ■ 動作情報 >> >> 常時監視して、オペレーターが介入する必要があるかを検知しないといけません。 >> まだなにかありそうな気がするのですが、ちょっと想像がつきません。 >> >> つながっているノードのリスト >> バージョン情報 >> 起動時間 >> >> インターフェースとしては、memcachedにならって、statsで上記の情報が返ってくればいいのではないでしょうか。 >> >> [t-hashi@hom301 ~]$ telnet localhost 35000 >> Trying 127.0.0.1... >> Connected to localhost (127.0.0.1). >> Escape character is '^]'. >> stats >> STAT pid 6850 >> STAT uptime 5403560 >> STAT time 1233021284 >> STAT version 1.2.4 >> STAT pointer_size 64 >> STAT rusage_user 0.212013 >> STAT rusage_system 0.508031 >> STAT curr_items 611 >> STAT total_items 3933 >> STAT bytes 291960 >> STAT curr_connections 1 >> STAT total_connections 1551 >> STAT connection_structures 5 >> STAT cmd_get 7372 >> STAT cmd_set 3941 >> STAT get_hits 6548 >> STAT get_misses 824 >> STAT evictions 0 >> STAT bytes_read 1606018 >> STAT bytes_written 92806482 >> STAT limit_maxbytes 10485760 >> STAT threads 4 >> END >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Kai-users-ja mailing list >> Kai...@li... >> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >> >> > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Kai-users-ja mailing list > Kai...@li... > https://lists.sourceforge.net/lists/listinfo/kai-users-ja > -- Takeru INOUE <tak...@gm...> |
From: Takeru I. <ino...@la...> - 2009-01-27 09:20:54
|
ありがとうございます. まずは,状態管理が不要なもの (オブジェクトサイズ数) などから実装していこ うと思います.それを正しく実装できたら,get の累計のように状態管理が必要 なものにとりかかるのがよさそうですね. Tomoya Hashimoto さんは書きました: > 橋本です。 > > Kaiを運用していく上で必要になるのではないかと思う統計情報などを考えてみました。 > > ■ 統計的情報 > > 以下の情報がないと、投資判断とか利用状況の改善が測れないと思います。 > > その時点のクライアントの接続数 > getの累計 > setの累計 > deleteの累計 > オブジェクトの総数 > オブジェクトのサイズ合計 > 二つのバージョンが返ってしまった数の累計 > 送信したbyteの累計 > 受信したbyteの累計 > > ■ 動作情報 > > 常時監視して、オペレーターが介入する必要があるかを検知しないといけません。 > まだなにかありそうな気がするのですが、ちょっと想像がつきません。 > > つながっているノードのリスト > バージョン情報 > 起動時間 > > インターフェースとしては、memcachedにならって、statsで上記の情報が返ってくればいいのではないでしょうか。 > > [t-hashi@hom301 ~]$ telnet localhost 35000 > Trying 127.0.0.1... > Connected to localhost (127.0.0.1). > Escape character is '^]'. > stats > STAT pid 6850 > STAT uptime 5403560 > STAT time 1233021284 > STAT version 1.2.4 > STAT pointer_size 64 > STAT rusage_user 0.212013 > STAT rusage_system 0.508031 > STAT curr_items 611 > STAT total_items 3933 > STAT bytes 291960 > STAT curr_connections 1 > STAT total_connections 1551 > STAT connection_structures 5 > STAT cmd_get 7372 > STAT cmd_set 3941 > STAT get_hits 6548 > STAT get_misses 824 > STAT evictions 0 > STAT bytes_read 1606018 > STAT bytes_written 92806482 > STAT limit_maxbytes 10485760 > STAT threads 4 > END > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Kai-users-ja mailing list > Kai...@li... > https://lists.sourceforge.net/lists/listinfo/kai-users-ja > > |
From: Tomoya H. <tom...@gm...> - 2009-01-27 02:57:19
|
橋本です。 Kaiを運用していく上で必要になるのではないかと思う統計情報などを考えてみました。 ■ 統計的情報 以下の情報がないと、投資判断とか利用状況の改善が測れないと思います。 その時点のクライアントの接続数 getの累計 setの累計 deleteの累計 オブジェクトの総数 オブジェクトのサイズ合計 二つのバージョンが返ってしまった数の累計 送信したbyteの累計 受信したbyteの累計 ■ 動作情報 常時監視して、オペレーターが介入する必要があるかを検知しないといけません。 まだなにかありそうな気がするのですが、ちょっと想像がつきません。 つながっているノードのリスト バージョン情報 起動時間 インターフェースとしては、memcachedにならって、statsで上記の情報が返ってくればいいのではないでしょうか。 [t-hashi@hom301 ~]$ telnet localhost 35000 Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'. stats STAT pid 6850 STAT uptime 5403560 STAT time 1233021284 STAT version 1.2.4 STAT pointer_size 64 STAT rusage_user 0.212013 STAT rusage_system 0.508031 STAT curr_items 611 STAT total_items 3933 STAT bytes 291960 STAT curr_connections 1 STAT total_connections 1551 STAT connection_structures 5 STAT cmd_get 7372 STAT cmd_set 3941 STAT get_hits 6548 STAT get_misses 824 STAT evictions 0 STAT bytes_read 1606018 STAT bytes_written 92806482 STAT limit_maxbytes 10485760 STAT threads 4 END |
From: Takeru I. <tak...@gm...> - 2009-01-23 14:33:09
|
Voluntas さんのブログにあるように,Kai が海外のブログで紹介されてました. Kai 紹介されてます - Twisted Mind http://d.hatena.ne.jp/Voluntas/20090121/1232506539 ドキュメントが貧弱と言われてしまいましたので,いい加減がんばって書かないとなぁと心を入れ替えています. 年末から時間がとれなくて Kai を放置していたのですが,そろそろ再開します. というわけで,今年もよろしくお願いします. -- Takeru INOUE <tak...@gm...> |
From: Takeru I. <tak...@gm...> - 2009-01-23 14:30:20
|
詳細にありがとうございます. 「二度と接続できるようにならなかった」というのが気になるところではありますが,直接的な原因はファイルディスクリプタ不足なので,数を増やすことで改善するのではないかと思います. また問題などありましたらお知らせください. 2009/1/23 Tomoya Hashimoto <tom...@gm...>: > 橋本です. > > お返事遅くなりました. > > 最初にkaiを起動したのが1月7日でした。エラーが発生していることに気づいたのが18日でした。前日までは動いていることを確認していたので、エラーが起きたのもこの時点です. > > 切断が発生しているホストではもう二度と接続できるようになりませんでした。 > > アドバイスいただいたとおり、ファイルディスクリプタが足りなくなっているようでしたので、制限を大きくした上でkaiを再起動しました。これが19日です。 > > /etc/security/limits.conf に以下のように変更を加えました. > > t-hashi soft nofile 49152 > t-hashi hard nofile 49152 > > 現時点ではエラーが発生している様子はありません。特にデータが欠損したような様子もありません。 > > 環境はCentOS 5.1のx86_64です。erlangはR12B5です。 > > 短時間(1時間程度)で大量のリクエストを投げていたときは発生していませんでした。 > > いまのところ様子見です. > > -- > Tomoya Hashimoto <tom...@gm...> > > 2009/01/22 23:28 Takeru INOUE <tak...@gm...>: >> 表題の件ですが,解決しましたでしょうか. >> アーカイブに残ると他の方の参考にもなりますので,お返事いただけると嬉しいです. >> >> 2009/1/19 Takeru INOUE <tak...@gm...>: >>> 井上です. >>> >>> 比較的,長い時間にわたって運用したときに発生しますでしょうか. >>> また,しばらくは切断され続けるでしょうか. >>> >>> enfile はファイルの不足を意味します (error on the number of files). >>> おそらく,file descriptor が足りなくなったのだと思います. >>> 次のようなことを行って,file descriptor を再利用しやすくしたり,上限を大きくしてみてください. >>> 僕が実験するときは,下記の設定にしていることが多いです. >>> >>> ■ TIME_WAIT 状態にあるソケットの再利用 >>> >>> % echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle >>> >>> ■ /etc/security/limits.conf >>> >>> # ユーザごとの上限値を設定.再ログインが必要. >>> --- >>> inoue soft nofile 49152 >>> inoue hard nofile 49152 >>> --- >>> >>> ■ /proc/sys/fs/file-max >>> >>> 通常は初期値が大きい (数万) ので,変更の必要なし. >>> >>> >>> これで様子を見ていただけますでしょうか. >>> なお,この方法は Kai に限らずすべての TCP サーバに利用できます. >>> >>> >>> 2009/1/19 Tomoya Hashimoto <tom...@gm...>: >>>> 橋本です。 >>>> >>>> kaiを同一の物理サーバに3つ起動してクラスターを組んでいたのですが、ある時点からクライアントからの接続をいきなり切断されるようになってしまいました。 >>>> >>>> >>>> [t-hashi@hom301 ~]$ telnet hom302 14010 >>>> Trying 172.20.202.17... >>>> Connected to hom302 (172.20.202.17). >>>> Escape character is '^]'. >>>> Connection closed by foreign host. >>>> [t-hashi@hom301 ~]$ >>>> >>>> 該当のkaiをのぞいてみると、以下のような警告を出力しています。 >>>> >>>> 2009-01-19 18:27:33.740007 [warning] (<0.596.0>) >>>> ./kai_tcp_server.erl:122: "acceptor_accept(kai_memcache) >>>> {error,enfile}" >>>> >>>> クラスターを組んでいる残り2つのkaiは問題なく動作しているように見えます。 >>>> >>>> 実運用で起きても困るのでなんとか原因を追いたいのですが、なにか思い当たらないでしょうか。 >>>> >>>> よろしくお願いします。 >>>> >>>> -- >>>> Tomoya Hashimoto <tom...@gm...> >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.net email is sponsored by: >>>> SourcForge Community >>>> SourceForge wants to tell your story. >>>> http://p.sf.net/sfu/sf-spreadtheword >>>> _______________________________________________ >>>> Kai-users-ja mailing list >>>> Kai...@li... >>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>>> >>> >>> >>> >>> -- >>> Takeru INOUE <tak...@gm...> >>> >> >> >> >> -- >> Takeru INOUE <tak...@gm...> >> > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Kai-users-ja mailing list > Kai...@li... > https://lists.sourceforge.net/lists/listinfo/kai-users-ja > -- Takeru INOUE <tak...@gm...> |