kai-users-ja — For Kai users in Japanese

Re: [Kai-users-ja] Failed to write?

[Tomoya H. <tom...@gm...>]

橋本です。

configの内容はどうなっているでしょうか。差し支えない範囲で教えてもらえると有益なアドバイスがもらえるかと思います。

あとは、iptablesやSELinuxが邪魔しているのかもしれません。

2009/07/14 15:30 に Masaki SAWAMURA<mas...@gm...> さんは書きました:
> はじまめて。澤村です。
>
> gihyo.jpの記事を見ながらKaiをためしているのですが、
> うまく動かなくて困っています。
>
> 現象としてはkaiの起動には成功するのですが、
> 書き込みを行おうとするとfailed to writeといったエラーになっています。
>
> 参考にしているのは下記のページです。
> http://gihyo.jp/dev/feature/01/kai/0002?page=2
>
> 何かヒントいただけると幸いです。
> よろしくおねがいします
>
>
>
> $ erl -pa ebin -config kai -kai n 1 -kai r 1 -kai w 1 -eval
> 'application:start(kai).'
> Erlang R13B01 (erts-5.7.2) [source] [rq:1] [async-threads:0] [hipe]
> [kernel-poll:false]
>
> Eshell V5.7.2  (abort with ^G)
> 1> 2009-07-14 15:24:31.313725 [info] (<0.42.0>) ./kai_hash.erl:181: {update,
>                                                                  [{{{172,22,
>                                                                      148,152},
>                                                                     11011},
>
> [{virtual_nodes,
>                                                                      128}]}],
>                                                                  []}
> 2009-07-14 15:24:40.061078 [warning] (<0.113.0>)
> ./kai_coordinator.erl:30: "route(\"foo\"): timeout"
> 2009-07-14 15:24:40.061174 [warning] (<0.113.0>)
> ./kai_memcache.erl:158: "send_error_and_close/2: \"Failed to write.\""
> 2009-07-14 15:24:40.062005 [warning] (<0.133.0>)
> ./kai_coordinator.erl:168: "gather_in_put/3: timeout"
> 2009-07-14 15:24:41.053788 [warning] (<0.135.0>)
> ./kai_coordinator.erl:117: "gather_in_get/4: timeout"
> 2009-07-14 15:24:41.053890 [warning] (<0.114.0>)
> ./kai_coordinator.erl:30: "route(\"foo\"): timeout"
> 2009-07-14 15:24:41.053957 [warning] (<0.114.0>)
> ./kai_tcp_server_acceptor.erl:54: "accept(kai_memcache)
> {error,badarith}"
> 2009-07-14 15:24:42.056424 [warning] (<0.137.0>)
> ./kai_coordinator.erl:210: "gather_in_delete/4: timeout"
> 2009-07-14 15:24:42.056542 [warning] (<0.115.0>)
> ./kai_coordinator.erl:30: "route(\"foo\"): timeout"
> 2009-07-14 15:24:42.056609 [warning] (<0.115.0>)
> ./kai_memcache.erl:158: "send_error_and_close/2:
> {state,{{172,22,148,152},11011},{3,2,2}}"
> 2009-07-14 15:24:42.056703 [warning] (<0.115.0>)
> ./kai_tcp_server_acceptor.erl:109: "call_mod(kai_memcache)
> {unexpected_result,\n                           {close,\n
>                 [\"SERVER_ERROR \",\n
> {state,{{172,22,148,152},11011},{3,2,2}},\n
>    \"\\r\\n\"],\n                               \"Failed to
> delete.\"}}"
> 2009-07-14 15:24:43.053087 [warning] (<0.139.0>)
> ./kai_coordinator.erl:117: "gather_in_get/4: timeout"
> 2009-07-14 15:24:43.053164 [warning] (<0.116.0>)
> ./kai_coordinator.erl:30: "route(\"foo\"): timeout"
> 2009-07-14 15:24:43.053216 [warning] (<0.116.0>)
> ./kai_tcp_server_acceptor.erl:54: "accept(kai_memcache)
> {error,badarith}"
> 2009-07-14 15:24:44.056432 [warning] (<0.141.0>)
> ./kai_coordinator.erl:168: "gather_in_put/3: timeout"
> 2009-07-14 15:24:44.056516 [warning] (<0.117.0>)
> ./kai_coordinator.erl:30: "route(\"baz\"): timeout"
> 2009-07-14 15:24:44.056573 [warning] (<0.117.0>)
> ./kai_memcache.erl:158: "send_error_and_close/2: \"Failed to write.\""
> 2009-07-14 15:24:45.053091 [warning] (<0.143.0>)
> ./kai_coordinator.erl:117: "gather_in_get/4: timeout"
> 2009-07-14 15:24:45.053173 [warning] (<0.118.0>)
> ./kai_coordinator.erl:30: "route(\"baz\"): timeout"
> 2009-07-14 15:24:45.053224 [warning] (<0.118.0>)
> ./kai_tcp_server_acceptor.erl:54: "accept(kai_memcache)
> {error,badarith}"
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Kai-users-ja mailing list
> Kai...@li...
> https://lists.sourceforge.net/lists/listinfo/kai-users-ja
>

[Kai-users-ja] Failed to write?

[Masaki S. <mas...@gm...>]

はじまめて。澤村です。

gihyo.jpの記事を見ながらKaiをためしているのですが、
うまく動かなくて困っています。

現象としてはkaiの起動には成功するのですが、
書き込みを行おうとするとfailed to writeといったエラーになっています。

参考にしているのは下記のページです。
http://gihyo.jp/dev/feature/01/kai/0002?page=2

何かヒントいただけると幸いです。
よろしくおねがいします



$ erl -pa ebin -config kai -kai n 1 -kai r 1 -kai w 1 -eval
'application:start(kai).'
Erlang R13B01 (erts-5.7.2) [source] [rq:1] [async-threads:0] [hipe]
[kernel-poll:false]

Eshell V5.7.2  (abort with ^G)
1> 2009-07-14 15:24:31.313725 [info] (<0.42.0>) ./kai_hash.erl:181: {update,
                                                                  [{{{172,22,
                                                                      148,152},
                                                                     11011},

[{virtual_nodes,
                                                                      128}]}],
                                                                  []}
2009-07-14 15:24:40.061078 [warning] (<0.113.0>)
./kai_coordinator.erl:30: "route(\"foo\"): timeout"
2009-07-14 15:24:40.061174 [warning] (<0.113.0>)
./kai_memcache.erl:158: "send_error_and_close/2: \"Failed to write.\""
2009-07-14 15:24:40.062005 [warning] (<0.133.0>)
./kai_coordinator.erl:168: "gather_in_put/3: timeout"
2009-07-14 15:24:41.053788 [warning] (<0.135.0>)
./kai_coordinator.erl:117: "gather_in_get/4: timeout"
2009-07-14 15:24:41.053890 [warning] (<0.114.0>)
./kai_coordinator.erl:30: "route(\"foo\"): timeout"
2009-07-14 15:24:41.053957 [warning] (<0.114.0>)
./kai_tcp_server_acceptor.erl:54: "accept(kai_memcache)
{error,badarith}"
2009-07-14 15:24:42.056424 [warning] (<0.137.0>)
./kai_coordinator.erl:210: "gather_in_delete/4: timeout"
2009-07-14 15:24:42.056542 [warning] (<0.115.0>)
./kai_coordinator.erl:30: "route(\"foo\"): timeout"
2009-07-14 15:24:42.056609 [warning] (<0.115.0>)
./kai_memcache.erl:158: "send_error_and_close/2:
{state,{{172,22,148,152},11011},{3,2,2}}"
2009-07-14 15:24:42.056703 [warning] (<0.115.0>)
./kai_tcp_server_acceptor.erl:109: "call_mod(kai_memcache)
{unexpected_result,\n                           {close,\n
                 [\"SERVER_ERROR \",\n
{state,{{172,22,148,152},11011},{3,2,2}},\n
    \"\\r\\n\"],\n                               \"Failed to
delete.\"}}"
2009-07-14 15:24:43.053087 [warning] (<0.139.0>)
./kai_coordinator.erl:117: "gather_in_get/4: timeout"
2009-07-14 15:24:43.053164 [warning] (<0.116.0>)
./kai_coordinator.erl:30: "route(\"foo\"): timeout"
2009-07-14 15:24:43.053216 [warning] (<0.116.0>)
./kai_tcp_server_acceptor.erl:54: "accept(kai_memcache)
{error,badarith}"
2009-07-14 15:24:44.056432 [warning] (<0.141.0>)
./kai_coordinator.erl:168: "gather_in_put/3: timeout"
2009-07-14 15:24:44.056516 [warning] (<0.117.0>)
./kai_coordinator.erl:30: "route(\"baz\"): timeout"
2009-07-14 15:24:44.056573 [warning] (<0.117.0>)
./kai_memcache.erl:158: "send_error_and_close/2: \"Failed to write.\""
2009-07-14 15:24:45.053091 [warning] (<0.143.0>)
./kai_coordinator.erl:117: "gather_in_get/4: timeout"
2009-07-14 15:24:45.053173 [warning] (<0.118.0>)
./kai_coordinator.erl:30: "route(\"baz\"): timeout"
2009-07-14 15:24:45.053224 [warning] (<0.118.0>)
./kai_tcp_server_acceptor.erl:54: "accept(kai_memcache)
{error,badarith}"

Re: [Kai-users-ja] オブジェクトが二重になってしまった場合のSET

[Takeru I. <tak...@gm...>]

kai-devel-ja に報告があったように，branches/shino_data_in_bag/ でこの問題が修正されたと思います．
衝突する複数のバージョンを共存できるようにしました (衝突解決はクライアントが行う必要がありますが，これはまた改めて)．


2009/3/14 shunichi shinohara <shi...@gm...>:
> 2009/3/14 Takeru INOUE <tak...@gm...>:
>> 二つの解決策があって，どちらも対応する必要がありそうです．
>>
>> 1. 途中になっているデータ同期のメカニズムを同期する．
>> Kai では，ノード間で定期的にデータを同期します．
>> ただし，現在は，あるデータを持っていなければ他ノードから取得しますが，持っていればバージョンが古くでも同期しません．
>> この同期を行うことで，ある程度時間が経て箱の問題は解決されるようになります．
>>
>> 2. ある程度時間が経つまではどうするか．
>> shino さんが言うように，複数バージョンのデータを格納してしまう，というのが根本的な解決策になると思います．
>> ets/dets を set から bag に変更する必要がありますねぇ．
>> 性能が落ちないか心配．．
>
> bag にまではしなくても、set のままで、
> 現状の data が入っている部分を、data のリストにすれば良いかと考えています。
> 新規のキー/値の set の場合には、
>
>    ets:insert(?MODULE, Data),
>
> のところが、
>
>    ets:insert(?MODULE, [Data]),
>
> となるイメージです。
> # この方法と bag のどちらが性能が良いかは試さないと分からないですが f(--)
>
> --
> shino
>



-- 
Takeru INOUE

Re: [Kai-users-ja] エラーが発生して終了もできなくなる

[Tomoya H. <tom...@gm...>]

橋本です。

いろいろありがとうございます。早速試してといきたいところなのですが、明日やってみます。

> 蛇足ですが、コンフィグの値を拝見し、非常に大きな値に驚きました。
> number_of_tables の値が小さく見えます（w；

Kaiを呼ぶApacheのプロセス数に安全係数をかけたりしたのですが、ちょっと多すぎるようです。ノード間の同期と思われるCPU負荷が無視できないのですが、もしかしてこれが原因？


2009/06/02 17:41 masahito ikuta <coo...@gm...>:
> 幾田です。
>
>> screen を使って起動したままにしてあります。
>
> では、もし機会があれば、下記をお試し頂いてもよろしいでしょうか？
>
> ▼起動
> Kai を起動する際に erl コマンドの引数に -sname を指定して下さい。
>
> e.g.
> erl -sname kai
>
> ▼停止
> コマンドを受け付けない状態になった際には
> erl コマンドの引数 -remsh を使って接続して q(). を評価して下さい。
>
> e.g.
> erl -sname kai_controller -remsh kai@`hostname -s`
>
> kai@xxxxx 1> q().
>
>> 改めて/etc/security/limits.confを確認したのですが、ファイルディスクリプタの数を増やしていなかったようです・・・・・。なんと初歩的な。このあたりを見直して様子をみます。
>
> 操作を受け付けない事は問題だと思うので、tcp_server 自体に問題がないか、もう少し調べてみます。
>
> 蛇足ですが、コンフィグの値を拝見し、非常に大きな値に驚きました。
> number_of_tables の値が小さく見えます（w；
>
>
> 2009/6/2 Tomoya Hashimoto <tom...@gm...>:
>> 橋本です。
>>
>> 早速ありがとうございます。いただいた質問にお答えします。
>>
>>>コンフィグファイルの下記の設定値をお教え頂いてもよろしいでしょうか？
>>
>>>number_of_tables
>>
>>    {number_of_tables, 256}
>>
>>>rpc_max_processes
>>
>>    {rpc_max_processes, 1200},
>>
>>>memcache_max_processes
>>
>>    {memcache_max_processes, 1200},
>>
>>>max_connections
>>
>>    {max_connections, 4096},
>>
>>> １．ご利用中の Kai のバージョンをお教え下さい
>>
>> リビジョン117のtrunkです。
>>
>>> ２．実際に行なった、Erlang の起動と停止の手順をお教え下さい
>>> GNU Screen を利用されていますでしょうか？
>>> それとも erl -detached でデタッチし、erl -remsh で接続して q(). を送りましたでしょうか？
>>
>> screen を使って起動したままにしてあります。
>>
>> 改めて/etc/security/limits.confを確認したのですが、ファイルディスクリプタの数を増やしていなかったようです・・・・・。なんと初歩的な。このあたりを見直して様子をみます。
>>
>>
>> 2009/06/02 14:33 masahito ikuta <coo...@gm...>:
>>> 幾田です。
>>>
>>>>> 2009-05-22 19:22:01.630645 [warning] (<0.4099.0>)
>>>>> ./kai_tcp_server.erl:123: "acceptor_accept(kai_memcache)
>>>>> {error,emfile}"
>>>>
>>>> ▼ Kai 側での対応
>>>> Erlang が応答しないのは運用上問題があるので
>>>> kai_tcp_server のエラー処理部分を早々に見直してみます。
>>>
>>> 上記のエラーメッセージは、accept に失敗した際に出るのですが
>>> その場合、3 秒 sleep してから再び accept します。
>>>
>>> ※EMFILE エラーが解決されない限り、繰り返しエラーになります
>>>
>>> Erlang 上の一つのプロセスが sleep したとしても
>>> Erlang VM 全体が sleep するわけではない為
>>> リモートシェルで接続する事で終了できます。
>>>
>>> そこで、追加で二つ質問がありますので
>>> ご回答をよろしくお願い申し上げます。
>>>
>>> １．ご利用中の Kai のバージョンをお教え下さい
>>> 多分、0.3.0 だと思うのですが、リポジトリから直接取得されている場合は
>>> リビジョン番号もお教え頂けないでしょうか？
>>>
>>> ２．実際に行なった、Erlang の起動と停止の手順をお教え下さい
>>> GNU Screen を利用されていますでしょうか？
>>> それとも erl -detached でデタッチし、erl -remsh で接続して q(). を送りましたでしょうか？
>>>
>>> 以上、お手数ではございますが
>>> よろしくお願い申し上げます。
>>>
>>> 2009/6/2 masahito ikuta <coo...@gm...>:
>>>> 幾田です。
>>>>
>>>>> 2009-05-22 19:22:01.630645 [warning] (<0.4099.0>)
>>>>> ./kai_tcp_server.erl:123: "acceptor_accept(kai_memcache)
>>>>> {error,emfile}"
>>>>
>>>> ▼ Kai 側での対応
>>>> Erlang が応答しないのは運用上問題があるので
>>>> kai_tcp_server のエラー処理部分を早々に見直してみます。
>>>>
>>>> ▼ お願いごと
>>>> OS 上で一つのプロセスが開けるファイル数がオーバーした際に出るエラーです。
>>>>
>>>> dets を利用する場合，number_of_tables で指定した数だけファイルを開いたままにするので
>>>> EMFILE エラーが出やすくなります。
>>>>
>>>> コンフィグファイルの下記の設定値をお教え頂いてもよろしいでしょうか？
>>>>
>>>> number_of_tables
>>>> rpc_max_processes
>>>> memcache_max_processes
>>>> max_connections
>>>>
>>>> 以上、よろしくお願い致します。
>>>>
>>>> 2009/6/2 Tomoya Hashimoto <tom...@gm...>:
>>>>> 橋本です。
>>>>>
>>>>> 10日ほどkaiを本格的に使い始めましたが、ときどきノードがダウンする現象に見舞われています。
>>>>>
>>>>> ３つのノードでクラスターを組んでいます。データの格納はdetsです。そのうちのひとつが突然以下のようなエラーを吐いています。この状態では、q().
>>>>> を送っても終了しません。しかたがないので、シェルからkillして終了させています。
>>>>>
>>>>> 2009-05-22 19:22:01.630645 [warning] (<0.4099.0>)
>>>>> ./kai_tcp_server.erl:123: "acceptor_accept(kai_memcache)
>>>>> {error,emfile}"
>>>>>
>>>>> 2009-05-22 19:22:01.630835 [warning] (<0.3117.0>)
>>>>> ./kai_tcp_server.erl:123: "acceptor_accept(kai_memcache)
>>>>> {error,emfile}"
>>>>>
>>>>> 2009-05-22 19:22:01.631022 [warning] (<0.3941.0>)
>>>>> ./kai_tcp_server.erl:123: "acceptor_accept(kai_memcache)
>>>>> {error,emfile}"
>>>>>
>>>>> 2009-05
>>>>>
>>>>> 二日に一回ぐらいでこの現象に見舞われています。何か想定できることはありますでしょうか。
>>>>>
>>>>> よろしくお願いします。
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
>>>>> looking to deploy the next generation of Solaris that includes the latest
>>>>> innovations from Sun and the OpenSource community. Download a copy and
>>>>> enjoy capabilities such as Networking, Storage and Virtualization.
>>>>> Go to: http://p.sf.net/sfu/opensolaris-get
>>>>> _______________________________________________
>>>>> Kai-users-ja mailing list
>>>>> Kai...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> cooldaemon
>>>>
>>>
>>>
>>>
>>> --
>>> cooldaemon
>>>
>>
>> ------------------------------------------------------------------------------
>> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
>> looking to deploy the next generation of Solaris that includes the latest
>> innovations from Sun and the OpenSource community. Download a copy and
>> enjoy capabilities such as Networking, Storage and Virtualization.
>> Go to: http://p.sf.net/sfu/opensolaris-get
>> _______________________________________________
>> Kai-users-ja mailing list
>> Kai...@li...
>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja
>>
>
>
>
> --
> cooldaemon
>

Re: [Kai-users-ja] エラーが発生して終了もできなくなる

[masahito i. <coo...@gm...>]

幾田です。

> screen を使って起動したままにしてあります。

では、もし機会があれば、下記をお試し頂いてもよろしいでしょうか？

▼起動
Kai を起動する際に erl コマンドの引数に -sname を指定して下さい。

e.g.
erl -sname kai

▼停止
コマンドを受け付けない状態になった際には
erl コマンドの引数 -remsh を使って接続して q(). を評価して下さい。

e.g.
erl -sname kai_controller -remsh kai@`hostname -s`

kai@xxxxx 1> q().

> 改めて/etc/security/limits.confを確認したのですが、ファイルディスクリプタの数を増やしていなかったようです・・・・・。なんと初歩的な。このあたりを見直して様子をみます。

操作を受け付けない事は問題だと思うので、tcp_server 自体に問題がないか、もう少し調べてみます。

蛇足ですが、コンフィグの値を拝見し、非常に大きな値に驚きました。
number_of_tables の値が小さく見えます（w；


2009/6/2 Tomoya Hashimoto <tom...@gm...>:
> 橋本です。
>
> 早速ありがとうございます。いただいた質問にお答えします。
>
>>コンフィグファイルの下記の設定値をお教え頂いてもよろしいでしょうか？
>
>>number_of_tables
>
>    {number_of_tables, 256}
>
>>rpc_max_processes
>
>    {rpc_max_processes, 1200},
>
>>memcache_max_processes
>
>    {memcache_max_processes, 1200},
>
>>max_connections
>
>    {max_connections, 4096},
>
>> １．ご利用中の Kai のバージョンをお教え下さい
>
> リビジョン117のtrunkです。
>
>> ２．実際に行なった、Erlang の起動と停止の手順をお教え下さい
>> GNU Screen を利用されていますでしょうか？
>> それとも erl -detached でデタッチし、erl -remsh で接続して q(). を送りましたでしょうか？
>
> screen を使って起動したままにしてあります。
>
> 改めて/etc/security/limits.confを確認したのですが、ファイルディスクリプタの数を増やしていなかったようです・・・・・。なんと初歩的な。このあたりを見直して様子をみます。
>
>
> 2009/06/02 14:33 masahito ikuta <coo...@gm...>:
>> 幾田です。
>>
>>>> 2009-05-22 19:22:01.630645 [warning] (<0.4099.0>)
>>>> ./kai_tcp_server.erl:123: "acceptor_accept(kai_memcache)
>>>> {error,emfile}"
>>>
>>> ▼ Kai 側での対応
>>> Erlang が応答しないのは運用上問題があるので
>>> kai_tcp_server のエラー処理部分を早々に見直してみます。
>>
>> 上記のエラーメッセージは、accept に失敗した際に出るのですが
>> その場合、3 秒 sleep してから再び accept します。
>>
>> ※EMFILE エラーが解決されない限り、繰り返しエラーになります
>>
>> Erlang 上の一つのプロセスが sleep したとしても
>> Erlang VM 全体が sleep するわけではない為
>> リモートシェルで接続する事で終了できます。
>>
>> そこで、追加で二つ質問がありますので
>> ご回答をよろしくお願い申し上げます。
>>
>> １．ご利用中の Kai のバージョンをお教え下さい
>> 多分、0.3.0 だと思うのですが、リポジトリから直接取得されている場合は
>> リビジョン番号もお教え頂けないでしょうか？
>>
>> ２．実際に行なった、Erlang の起動と停止の手順をお教え下さい
>> GNU Screen を利用されていますでしょうか？
>> それとも erl -detached でデタッチし、erl -remsh で接続して q(). を送りましたでしょうか？
>>
>> 以上、お手数ではございますが
>> よろしくお願い申し上げます。
>>
>> 2009/6/2 masahito ikuta <coo...@gm...>:
>>> 幾田です。
>>>
>>>> 2009-05-22 19:22:01.630645 [warning] (<0.4099.0>)
>>>> ./kai_tcp_server.erl:123: "acceptor_accept(kai_memcache)
>>>> {error,emfile}"
>>>
>>> ▼ Kai 側での対応
>>> Erlang が応答しないのは運用上問題があるので
>>> kai_tcp_server のエラー処理部分を早々に見直してみます。
>>>
>>> ▼ お願いごと
>>> OS 上で一つのプロセスが開けるファイル数がオーバーした際に出るエラーです。
>>>
>>> dets を利用する場合，number_of_tables で指定した数だけファイルを開いたままにするので
>>> EMFILE エラーが出やすくなります。
>>>
>>> コンフィグファイルの下記の設定値をお教え頂いてもよろしいでしょうか？
>>>
>>> number_of_tables
>>> rpc_max_processes
>>> memcache_max_processes
>>> max_connections
>>>
>>> 以上、よろしくお願い致します。
>>>
>>> 2009/6/2 Tomoya Hashimoto <tom...@gm...>:
>>>> 橋本です。
>>>>
>>>> 10日ほどkaiを本格的に使い始めましたが、ときどきノードがダウンする現象に見舞われています。
>>>>
>>>> ３つのノードでクラスターを組んでいます。データの格納はdetsです。そのうちのひとつが突然以下のようなエラーを吐いています。この状態では、q().
>>>> を送っても終了しません。しかたがないので、シェルからkillして終了させています。
>>>>
>>>> 2009-05-22 19:22:01.630645 [warning] (<0.4099.0>)
>>>> ./kai_tcp_server.erl:123: "acceptor_accept(kai_memcache)
>>>> {error,emfile}"
>>>>
>>>> 2009-05-22 19:22:01.630835 [warning] (<0.3117.0>)
>>>> ./kai_tcp_server.erl:123: "acceptor_accept(kai_memcache)
>>>> {error,emfile}"
>>>>
>>>> 2009-05-22 19:22:01.631022 [warning] (<0.3941.0>)
>>>> ./kai_tcp_server.erl:123: "acceptor_accept(kai_memcache)
>>>> {error,emfile}"
>>>>
>>>> 2009-05
>>>>
>>>> 二日に一回ぐらいでこの現象に見舞われています。何か想定できることはありますでしょうか。
>>>>
>>>> よろしくお願いします。
>>>>
>>>> ------------------------------------------------------------------------------
>>>> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
>>>> looking to deploy the next generation of Solaris that includes the latest
>>>> innovations from Sun and the OpenSource community. Download a copy and
>>>> enjoy capabilities such as Networking, Storage and Virtualization.
>>>> Go to: http://p.sf.net/sfu/opensolaris-get
>>>> _______________________________________________
>>>> Kai-users-ja mailing list
>>>> Kai...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja
>>>>
>>>
>>>
>>>
>>> --
>>> cooldaemon
>>>
>>
>>
>>
>> --
>> cooldaemon
>>
>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> Kai-users-ja mailing list
> Kai...@li...
> https://lists.sourceforge.net/lists/listinfo/kai-users-ja
>



-- 
cooldaemon

Re: [Kai-users-ja] エラーが発生して終了もできなくなる

[Tomoya H. <tom...@gm...>]

橋本です。

早速ありがとうございます。いただいた質問にお答えします。

>コンフィグファイルの下記の設定値をお教え頂いてもよろしいでしょうか？

>number_of_tables

    {number_of_tables, 256}

>rpc_max_processes

    {rpc_max_processes, 1200},

>memcache_max_processes

    {memcache_max_processes, 1200},

>max_connections

    {max_connections, 4096},

> １．ご利用中の Kai のバージョンをお教え下さい

リビジョン117のtrunkです。

> ２．実際に行なった、Erlang の起動と停止の手順をお教え下さい
> GNU Screen を利用されていますでしょうか？
> それとも erl -detached でデタッチし、erl -remsh で接続して q(). を送りましたでしょうか？

screen を使って起動したままにしてあります。

改めて/etc/security/limits.confを確認したのですが、ファイルディスクリプタの数を増やしていなかったようです・・・・・。なんと初歩的な。このあたりを見直して様子をみます。


2009/06/02 14:33 masahito ikuta <coo...@gm...>:
> 幾田です。
>
>>> 2009-05-22 19:22:01.630645 [warning] (<0.4099.0>)
>>> ./kai_tcp_server.erl:123: "acceptor_accept(kai_memcache)
>>> {error,emfile}"
>>
>> ▼ Kai 側での対応
>> Erlang が応答しないのは運用上問題があるので
>> kai_tcp_server のエラー処理部分を早々に見直してみます。
>
> 上記のエラーメッセージは、accept に失敗した際に出るのですが
> その場合、3 秒 sleep してから再び accept します。
>
> ※EMFILE エラーが解決されない限り、繰り返しエラーになります
>
> Erlang 上の一つのプロセスが sleep したとしても
> Erlang VM 全体が sleep するわけではない為
> リモートシェルで接続する事で終了できます。
>
> そこで、追加で二つ質問がありますので
> ご回答をよろしくお願い申し上げます。
>
> １．ご利用中の Kai のバージョンをお教え下さい
> 多分、0.3.0 だと思うのですが、リポジトリから直接取得されている場合は
> リビジョン番号もお教え頂けないでしょうか？
>
> ２．実際に行なった、Erlang の起動と停止の手順をお教え下さい
> GNU Screen を利用されていますでしょうか？
> それとも erl -detached でデタッチし、erl -remsh で接続して q(). を送りましたでしょうか？
>
> 以上、お手数ではございますが
> よろしくお願い申し上げます。
>
> 2009/6/2 masahito ikuta <coo...@gm...>:
>> 幾田です。
>>
>>> 2009-05-22 19:22:01.630645 [warning] (<0.4099.0>)
>>> ./kai_tcp_server.erl:123: "acceptor_accept(kai_memcache)
>>> {error,emfile}"
>>
>> ▼ Kai 側での対応
>> Erlang が応答しないのは運用上問題があるので
>> kai_tcp_server のエラー処理部分を早々に見直してみます。
>>
>> ▼ お願いごと
>> OS 上で一つのプロセスが開けるファイル数がオーバーした際に出るエラーです。
>>
>> dets を利用する場合，number_of_tables で指定した数だけファイルを開いたままにするので
>> EMFILE エラーが出やすくなります。
>>
>> コンフィグファイルの下記の設定値をお教え頂いてもよろしいでしょうか？
>>
>> number_of_tables
>> rpc_max_processes
>> memcache_max_processes
>> max_connections
>>
>> 以上、よろしくお願い致します。
>>
>> 2009/6/2 Tomoya Hashimoto <tom...@gm...>:
>>> 橋本です。
>>>
>>> 10日ほどkaiを本格的に使い始めましたが、ときどきノードがダウンする現象に見舞われています。
>>>
>>> ３つのノードでクラスターを組んでいます。データの格納はdetsです。そのうちのひとつが突然以下のようなエラーを吐いています。この状態では、q().
>>> を送っても終了しません。しかたがないので、シェルからkillして終了させています。
>>>
>>> 2009-05-22 19:22:01.630645 [warning] (<0.4099.0>)
>>> ./kai_tcp_server.erl:123: "acceptor_accept(kai_memcache)
>>> {error,emfile}"
>>>
>>> 2009-05-22 19:22:01.630835 [warning] (<0.3117.0>)
>>> ./kai_tcp_server.erl:123: "acceptor_accept(kai_memcache)
>>> {error,emfile}"
>>>
>>> 2009-05-22 19:22:01.631022 [warning] (<0.3941.0>)
>>> ./kai_tcp_server.erl:123: "acceptor_accept(kai_memcache)
>>> {error,emfile}"
>>>
>>> 2009-05
>>>
>>> 二日に一回ぐらいでこの現象に見舞われています。何か想定できることはありますでしょうか。
>>>
>>> よろしくお願いします。
>>>
>>> ------------------------------------------------------------------------------
>>> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
>>> looking to deploy the next generation of Solaris that includes the latest
>>> innovations from Sun and the OpenSource community. Download a copy and
>>> enjoy capabilities such as Networking, Storage and Virtualization.
>>> Go to: http://p.sf.net/sfu/opensolaris-get
>>> _______________________________________________
>>> Kai-users-ja mailing list
>>> Kai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja
>>>
>>
>>
>>
>> --
>> cooldaemon
>>
>
>
>
> --
> cooldaemon
>

Re: [Kai-users-ja] エラーが発生して終了もできなくなる

[masahito i. <coo...@gm...>]

幾田です。

> 2009-05-22 19:22:01.630645 [warning] (<0.4099.0>)
> ./kai_tcp_server.erl:123: "acceptor_accept(kai_memcache)
> {error,emfile}"

▼ Kai 側での対応
Erlang が応答しないのは運用上問題があるので
kai_tcp_server のエラー処理部分を早々に見直してみます。

▼ お願いごと
OS 上で一つのプロセスが開けるファイル数がオーバーした際に出るエラーです。

dets を利用する場合，number_of_tables で指定した数だけファイルを開いたままにするので
EMFILE エラーが出やすくなります。

コンフィグファイルの下記の設定値をお教え頂いてもよろしいでしょうか？

number_of_tables
rpc_max_processes
memcache_max_processes
max_connections

以上、よろしくお願い致します。

2009/6/2 Tomoya Hashimoto <tom...@gm...>:
> 橋本です。
>
> 10日ほどkaiを本格的に使い始めましたが、ときどきノードがダウンする現象に見舞われています。
>
> ３つのノードでクラスターを組んでいます。データの格納はdetsです。そのうちのひとつが突然以下のようなエラーを吐いています。この状態では、q().
> を送っても終了しません。しかたがないので、シェルからkillして終了させています。
>
> 2009-05-22 19:22:01.630645 [warning] (<0.4099.0>)
> ./kai_tcp_server.erl:123: "acceptor_accept(kai_memcache)
> {error,emfile}"
>
> 2009-05-22 19:22:01.630835 [warning] (<0.3117.0>)
> ./kai_tcp_server.erl:123: "acceptor_accept(kai_memcache)
> {error,emfile}"
>
> 2009-05-22 19:22:01.631022 [warning] (<0.3941.0>)
> ./kai_tcp_server.erl:123: "acceptor_accept(kai_memcache)
> {error,emfile}"
>
> 2009-05
>
> 二日に一回ぐらいでこの現象に見舞われています。何か想定できることはありますでしょうか。
>
> よろしくお願いします。
>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> Kai-users-ja mailing list
> Kai...@li...
> https://lists.sourceforge.net/lists/listinfo/kai-users-ja
>



-- 
cooldaemon

[Kai-users-ja] エラーが発生して終了もできなくなる

[Tomoya H. <tom...@gm...>]

橋本です。

10日ほどkaiを本格的に使い始めましたが、ときどきノードがダウンする現象に見舞われています。

３つのノードでクラスターを組んでいます。データの格納はdetsです。そのうちのひとつが突然以下のようなエラーを吐いています。この状態では、q().
を送っても終了しません。しかたがないので、シェルからkillして終了させています。

2009-05-22 19:22:01.630645 [warning] (<0.4099.0>)
./kai_tcp_server.erl:123: "acceptor_accept(kai_memcache)
{error,emfile}"

2009-05-22 19:22:01.630835 [warning] (<0.3117.0>)
./kai_tcp_server.erl:123: "acceptor_accept(kai_memcache)
{error,emfile}"

2009-05-22 19:22:01.631022 [warning] (<0.3941.0>)
./kai_tcp_server.erl:123: "acceptor_accept(kai_memcache)
{error,emfile}"

2009-05

二日に一回ぐらいでこの現象に見舞われています。何か想定できることはありますでしょうか。

よろしくお願いします。

[Kai-users-ja] Kai 0.4.0 released

[Takeru I. <tak...@gm...>]

Kai 0.4.0 をリリースしました．
このバージョンには運用に関する新機能が含まれています．
たとえば，memcache API の stats や，それを利用した Cacti テンプレートです．
また，このバージョンは goo home (http://home.goo.ne.jp) で運用準備中のようです．
Kai としては初めてのプロダクション利用になりそうです．

Kai の最新版は次の URL からダウンロードできます．
https://sourceforge.net/project/showfiles.php?group_id=228337

さて，6月には詳細なドキュメントを公開する予定です．
たぶん，1万文字を軽く超えるくらいの分量になります．
0.4.0 の運用機能にドキュメントが加われば，Kai を利用するときにかなりのサポートになると思います．

では．

-- 
Takeru INOUE

Re: [Kai-users-ja] quitを送らない場合の後始末

[Takeru I. <tak...@gm...>]

2009/2/26 Tomoya Hashimoto <tom...@gm...>:
> 橋本です。
>
> 対応ありがとうございました。
>
> 早速新しいコードに入れ換えて問題を報告した環境で丸一日使ってみました。問題は発生していません。
>
> cactiのプラグインも動いてます。

そろそろ，次のリリースを使用と思います (いまの trunk/ が v0.4 になります)．
ところで，cacti のプラグインなどの運用ツールをオープンにするつもりはありませんか?
もしそうであれば，contrib/ というディレクトリを作って，そこに同梱したいと思ってます．
使い方のドキュメントがあれば，英訳して sourceforge に載せておきます．

よかったら，ご検討くださいませ．


> 以上報告でした。ありがとうございました。
>
> 2009/02/25 19:12 Takeru INOUE <tak...@gm...>:
>> お疲れ様でした．
>>
>> 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...>
>> ------------------------------------------------------------------------------
>> 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
>>
> ------------------------------------------------------------------------------
> 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
>

Re: [Kai-users-ja] オブジェクトが二重になってしまった場合のSET

[masahito i. <coo...@gm...>]

ありがとうございました！とても参考になります。
さっそく、ブックマークを（w；

2009/3/18 Takeru INOUE <tak...@gm...>:
> cooldaemon さんから希望されたので，bag の性能評価をブログにまとめ直しました．
>
>  http://teahut.sakura.ne.jp/b/
>
> 結論としては，キーあたりの値の数が少ないときは性能差が少ないので，他の条件で決めればよさそうです．
> 基本的には，コードの書きやすさで決めればよいと思います．
> ただし，メモリ使用量が bag のほうが少ないようなので (理由不明，本当かなぁ)，それを基準にしてもいいかもしれません．
>
> 2009/3/15 Takeru INOUE <tak...@gm...>:
>> 2009/3/14 shunichi shinohara <shi...@gm...>:
>>> 2009/3/14 Takeru INOUE <tak...@gm...>:
>>>> 二つの解決策があって，どちらも対応する必要がありそうです．
>>>>
>>>> 1. 途中になっているデータ同期のメカニズムを同期する．
>>>> Kai では，ノード間で定期的にデータを同期します．
>>>> ただし，現在は，あるデータを持っていなければ他ノードから取得しますが，持っていればバージョンが古くでも同期しません．
>>>> この同期を行うことで，ある程度時間が経て箱の問題は解決されるようになります．
>>>>
>>>> 2. ある程度時間が経つまではどうするか．
>>>> shino さんが言うように，複数バージョンのデータを格納してしまう，というのが根本的な解決策になると思います．
>>>> ets/dets を set から bag に変更する必要がありますねぇ．
>>>> 性能が落ちないか心配．．
>>>
>>> bag にまではしなくても、set のままで、
>>> 現状の data が入っている部分を、data のリストにすれば良いかと考えています。
>>> 新規のキー/値の set の場合には、
>>>
>>>    ets:insert(?MODULE, Data),
>>>
>>> のところが、
>>>
>>>    ets:insert(?MODULE, [Data]),
>>>
>>> となるイメージです。
>>
>>> # この方法と bag のどちらが性能が良いかは試さないと分からないですが f(--)
>>
>> 自分の作業メモを見返したら，去年の 5/9 にまさにそのような実験をやってました．
>>
>> # なんでこんなことしたんだろう?
>>
>> 結論としては，今回のように配列長が小さいときは，set に配列を入れるより bag を使うほうが少し速いようです．
>>
>> ■ 前置き
>>
>> bag では一つのキーが複数の値を持つことができる．
>>
>> | key | value
>> | 1   | 1
>> | 1   | 2
>> | 1   | 3
>> | 2   | 1
>> | ... |
>>
>> また，set でもリストを使うことによって，同様のことができる．すでに
>> 存在する値を取り出し，追加して再格納する．
>>
>> | key | value
>> | 1   | [1, 2, 3]
>> | 2   | [1, ...]
>> | ... |
>>
>> キーあたりの値の数を変化させて，insert の性能を評価した．insert 回
>> 数は M=1024 とし，キーあたりの値の数 N を変化させて時間 (usec) を測
>> 定した．
>>
>> ■ 結果
>>
>> | N     | set0 | bag  | set
>> | 1     | 2227 | 1907 | 2668
>> | 3     | 2166 | 2295 | 3872
>> | 16    | 2195 | 3638 | 6122
>> | 64    | 1939 | 7254 | 14912
>> | 256   | 2214 | 22678| 54228
>> | 1024  | 2164 | 78904| 206331
>>
>> 表中の set では，上のようにして一つのキーに複数の値を持たせた．表中
>> の set0 は比較材料であり，set に対して単純に 1024 回のinsert を行っ
>> た (つまり，N の影響を受けない)．
>>
>> 結果より，bag では，キーあたりの値数に比例して時間がかかることがわ
>> かった．また，set も同様の傾向を見せているが，これは insert 時にメ
>> モリ再割り当てが行われるためである．よって，bag でも同じキーに値を
>> 追加するときにはメモリの再割り当てが行われていると予想される．
>>
>> なお，set0 は N の影響を受けないため，一定の時間となっている．
>>
>> 以上より，bag を利用するときは，キーあたりの値の数に注意しなければ
>> ならない．これが多いときには他のアルゴリズムを検討すべきである．
>>
>> ■ ソースコード
>>
>> -module(setbag).
>> -compile(export_all).
>> -define(M, 1024). % 1024, 4096, 16384
>> -define(N, 1024). % 1, 3, 16, 64, 256, 1024
>>
>> set0_insert(0) ->
>>    ok;
>> set0_insert(I) ->
>>    ets:insert(set0, {I, {{127,0,0,1}, I}}),
>>    set0_insert(I-1).
>>
>> bag_insert(0) ->
>>    ok;
>> bag_insert(I) ->
>>    Key = I div ?N,
>>    ets:insert(bag, {Key, {{127,0,0,1}, I}}),
>>    bag_insert(I-1).
>>
>> set_insert(0) ->
>>    ok;
>> set_insert(I) ->
>>    Key = I div ?N,
>>    Nodes =
>>        case ets:lookup(set, Key) of
>>            [{Key, N}|_] -> N;
>>            _Other -> []
>>        end,
>>    ets:insert(set, {Key, [{{127,0,0,1}, I}|Nodes]}),
>>    set_insert(I-1).
>>
>> start() ->
>>    ets:new(set0, [set, named_table]),
>>    {Usec, _} = timer:tc(?MODULE, set0_insert, [?M]),
>>    io:format("set0: ~p [usec]~n", [Usec]),
>>    {Usec2, _} = timer:tc(ets, delete_all_objcets, [set0]),
>>    io:format("set0: ~p [usec]~n", [Usec2]),
>>    ets:delete(set0),
>>
>>    ets:new(bag, [bag, named_table]),
>>    {Usec3, _} = timer:tc(?MODULE, bag_insert, [?M]),
>>    io:format("bag: ~p [usec]~n", [Usec3]),
>>    {Usec4, _} = timer:tc(ets, delete_all_objcets, [bag]),
>>    io:format("bag: ~p [usec]~n", [Usec4]),
>>    ets:delete(bag),
>>
>>    ets:new(set, [set, named_table]),
>>    {Usec5, _} = timer:tc(?MODULE, set_insert, [?M]),
>>    io:format("set: ~p [usec]~n", [Usec5]),
>>    {Usec6, _} = timer:tc(ets, delete_all_objcets, [set]),
>>    io:format("set: ~p [usec]~n", [Usec6]),
>>    ets:delete(set).
>>
>> --
>>  Takeru INOUE <tak...@gm...>
>>
>
>
>
> --
>  Takeru INOUE <tak...@gm...>
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Kai-users-ja mailing list
> Kai...@li...
> https://lists.sourceforge.net/lists/listinfo/kai-users-ja
>



-- 
cooldaemon

Re: [Kai-users-ja] オブジェクトが二重になってしまった場合のSET

[Takeru I. <tak...@gm...>]

cooldaemon さんから希望されたので，bag の性能評価をブログにまとめ直しました．

  http://teahut.sakura.ne.jp/b/

結論としては，キーあたりの値の数が少ないときは性能差が少ないので，他の条件で決めればよさそうです．
基本的には，コードの書きやすさで決めればよいと思います．
ただし，メモリ使用量が bag のほうが少ないようなので (理由不明，本当かなぁ)，それを基準にしてもいいかもしれません．

2009/3/15 Takeru INOUE <tak...@gm...>:
> 2009/3/14 shunichi shinohara <shi...@gm...>:
>> 2009/3/14 Takeru INOUE <tak...@gm...>:
>>> 二つの解決策があって，どちらも対応する必要がありそうです．
>>>
>>> 1. 途中になっているデータ同期のメカニズムを同期する．
>>> Kai では，ノード間で定期的にデータを同期します．
>>> ただし，現在は，あるデータを持っていなければ他ノードから取得しますが，持っていればバージョンが古くでも同期しません．
>>> この同期を行うことで，ある程度時間が経て箱の問題は解決されるようになります．
>>>
>>> 2. ある程度時間が経つまではどうするか．
>>> shino さんが言うように，複数バージョンのデータを格納してしまう，というのが根本的な解決策になると思います．
>>> ets/dets を set から bag に変更する必要がありますねぇ．
>>> 性能が落ちないか心配．．
>>
>> bag にまではしなくても、set のままで、
>> 現状の data が入っている部分を、data のリストにすれば良いかと考えています。
>> 新規のキー/値の set の場合には、
>>
>>    ets:insert(?MODULE, Data),
>>
>> のところが、
>>
>>    ets:insert(?MODULE, [Data]),
>>
>> となるイメージです。
>
>> # この方法と bag のどちらが性能が良いかは試さないと分からないですが f(--)
>
> 自分の作業メモを見返したら，去年の 5/9 にまさにそのような実験をやってました．
>
> # なんでこんなことしたんだろう?
>
> 結論としては，今回のように配列長が小さいときは，set に配列を入れるより bag を使うほうが少し速いようです．
>
> ■ 前置き
>
> bag では一つのキーが複数の値を持つことができる．
>
> | key | value
> | 1   | 1
> | 1   | 2
> | 1   | 3
> | 2   | 1
> | ... |
>
> また，set でもリストを使うことによって，同様のことができる．すでに
> 存在する値を取り出し，追加して再格納する．
>
> | key | value
> | 1   | [1, 2, 3]
> | 2   | [1, ...]
> | ... |
>
> キーあたりの値の数を変化させて，insert の性能を評価した．insert 回
> 数は M=1024 とし，キーあたりの値の数 N を変化させて時間 (usec) を測
> 定した．
>
> ■ 結果
>
> | N     | set0 | bag  | set
> | 1     | 2227 | 1907 | 2668
> | 3     | 2166 | 2295 | 3872
> | 16    | 2195 | 3638 | 6122
> | 64    | 1939 | 7254 | 14912
> | 256   | 2214 | 22678| 54228
> | 1024  | 2164 | 78904| 206331
>
> 表中の set では，上のようにして一つのキーに複数の値を持たせた．表中
> の set0 は比較材料であり，set に対して単純に 1024 回のinsert を行っ
> た (つまり，N の影響を受けない)．
>
> 結果より，bag では，キーあたりの値数に比例して時間がかかることがわ
> かった．また，set も同様の傾向を見せているが，これは insert 時にメ
> モリ再割り当てが行われるためである．よって，bag でも同じキーに値を
> 追加するときにはメモリの再割り当てが行われていると予想される．
>
> なお，set0 は N の影響を受けないため，一定の時間となっている．
>
> 以上より，bag を利用するときは，キーあたりの値の数に注意しなければ
> ならない．これが多いときには他のアルゴリズムを検討すべきである．
>
> ■ ソースコード
>
> -module(setbag).
> -compile(export_all).
> -define(M, 1024). % 1024, 4096, 16384
> -define(N, 1024). % 1, 3, 16, 64, 256, 1024
>
> set0_insert(0) ->
>    ok;
> set0_insert(I) ->
>    ets:insert(set0, {I, {{127,0,0,1}, I}}),
>    set0_insert(I-1).
>
> bag_insert(0) ->
>    ok;
> bag_insert(I) ->
>    Key = I div ?N,
>    ets:insert(bag, {Key, {{127,0,0,1}, I}}),
>    bag_insert(I-1).
>
> set_insert(0) ->
>    ok;
> set_insert(I) ->
>    Key = I div ?N,
>    Nodes =
>        case ets:lookup(set, Key) of
>            [{Key, N}|_] -> N;
>            _Other -> []
>        end,
>    ets:insert(set, {Key, [{{127,0,0,1}, I}|Nodes]}),
>    set_insert(I-1).
>
> start() ->
>    ets:new(set0, [set, named_table]),
>    {Usec, _} = timer:tc(?MODULE, set0_insert, [?M]),
>    io:format("set0: ~p [usec]~n", [Usec]),
>    {Usec2, _} = timer:tc(ets, delete_all_objcets, [set0]),
>    io:format("set0: ~p [usec]~n", [Usec2]),
>    ets:delete(set0),
>
>    ets:new(bag, [bag, named_table]),
>    {Usec3, _} = timer:tc(?MODULE, bag_insert, [?M]),
>    io:format("bag: ~p [usec]~n", [Usec3]),
>    {Usec4, _} = timer:tc(ets, delete_all_objcets, [bag]),
>    io:format("bag: ~p [usec]~n", [Usec4]),
>    ets:delete(bag),
>
>    ets:new(set, [set, named_table]),
>    {Usec5, _} = timer:tc(?MODULE, set_insert, [?M]),
>    io:format("set: ~p [usec]~n", [Usec5]),
>    {Usec6, _} = timer:tc(ets, delete_all_objcets, [set]),
>    io:format("set: ~p [usec]~n", [Usec6]),
>    ets:delete(set).
>
> --
>  Takeru INOUE <tak...@gm...>
>



-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-users-ja] オブジェクトが二重になってしまった場合のSET

[Takeru I. <tak...@gm...>]

2009/3/16 Tomoya Hashimoto <tom...@gm...>:
> 橋本です。
>
> detsについてはあまり理解がないのですが、set->bagにするとデータの互換性がなくなって以前のデータがすべて失われる・・・なんてことがなければよいのですが。

あぁ，そうか．

> 本格的に使うのは恐らくGW前からになりそうです。

それまでなら大きな変更も OK ですか?

> 2009/03/15 22:06 Takeru INOUE <tak...@gm...>:
>> 2009/3/14 shunichi shinohara <shi...@gm...>:
>>> 2009/3/14 Takeru INOUE <tak...@gm...>:
>>>> 二つの解決策があって，どちらも対応する必要がありそうです．
>>>>
>>>> 1. 途中になっているデータ同期のメカニズムを同期する．
>>>> Kai では，ノード間で定期的にデータを同期します．
>>>> ただし，現在は，あるデータを持っていなければ他ノードから取得しますが，持っていればバージョンが古くでも同期しません．
>>>> この同期を行うことで，ある程度時間が経て箱の問題は解決されるようになります．
>>>>
>>>> 2. ある程度時間が経つまではどうするか．
>>>> shino さんが言うように，複数バージョンのデータを格納してしまう，というのが根本的な解決策になると思います．
>>>> ets/dets を set から bag に変更する必要がありますねぇ．
>>>> 性能が落ちないか心配．．
>>>
>>> bag にまではしなくても、set のままで、
>>> 現状の data が入っている部分を、data のリストにすれば良いかと考えています。
>>> 新規のキー/値の set の場合には、
>>>
>>>    ets:insert(?MODULE, Data),
>>>
>>> のところが、
>>>
>>>    ets:insert(?MODULE, [Data]),
>>>
>>> となるイメージです。
>>
>>> # この方法と bag のどちらが性能が良いかは試さないと分からないですが f(--)
>>
>> 自分の作業メモを見返したら，去年の 5/9 にまさにそのような実験をやってました．
>>
>> # なんでこんなことしたんだろう?
>>
>> 結論としては，今回のように配列長が小さいときは，set に配列を入れるより bag を使うほうが少し速いようです．
>>
>> ■ 前置き
>>
>> bag では一つのキーが複数の値を持つことができる．
>>
>> | key | value
>> | 1   | 1
>> | 1   | 2
>> | 1   | 3
>> | 2   | 1
>> | ... |
>>
>> また，set でもリストを使うことによって，同様のことができる．すでに
>> 存在する値を取り出し，追加して再格納する．
>>
>> | key | value
>> | 1   | [1, 2, 3]
>> | 2   | [1, ...]
>> | ... |
>>
>> キーあたりの値の数を変化させて，insert の性能を評価した．insert 回
>> 数は M=1024 とし，キーあたりの値の数 N を変化させて時間 (usec) を測
>> 定した．
>>
>> ■ 結果
>>
>> | N     | set0 | bag  | set
>> | 1     | 2227 | 1907 | 2668
>> | 3     | 2166 | 2295 | 3872
>> | 16    | 2195 | 3638 | 6122
>> | 64    | 1939 | 7254 | 14912
>> | 256   | 2214 | 22678| 54228
>> | 1024  | 2164 | 78904| 206331
>>
>> 表中の set では，上のようにして一つのキーに複数の値を持たせた．表中
>> の set0 は比較材料であり，set に対して単純に 1024 回のinsert を行っ
>> た (つまり，N の影響を受けない)．
>>
>> 結果より，bag では，キーあたりの値数に比例して時間がかかることがわ
>> かった．また，set も同様の傾向を見せているが，これは insert 時にメ
>> モリ再割り当てが行われるためである．よって，bag でも同じキーに値を
>> 追加するときにはメモリの再割り当てが行われていると予想される．
>>
>> なお，set0 は N の影響を受けないため，一定の時間となっている．
>>
>> 以上より，bag を利用するときは，キーあたりの値の数に注意しなければ
>> ならない．これが多いときには他のアルゴリズムを検討すべきである．
>>
>> ■ ソースコード
>>
>> -module(setbag).
>> -compile(export_all).
>> -define(M, 1024). % 1024, 4096, 16384
>> -define(N, 1024). % 1, 3, 16, 64, 256, 1024
>>
>> set0_insert(0) ->
>>    ok;
>> set0_insert(I) ->
>>    ets:insert(set0, {I, {{127,0,0,1}, I}}),
>>    set0_insert(I-1).
>>
>> bag_insert(0) ->
>>    ok;
>> bag_insert(I) ->
>>    Key = I div ?N,
>>    ets:insert(bag, {Key, {{127,0,0,1}, I}}),
>>    bag_insert(I-1).
>>
>> set_insert(0) ->
>>    ok;
>> set_insert(I) ->
>>    Key = I div ?N,
>>    Nodes =
>>        case ets:lookup(set, Key) of
>>            [{Key, N}|_] -> N;
>>            _Other -> []
>>        end,
>>    ets:insert(set, {Key, [{{127,0,0,1}, I}|Nodes]}),
>>    set_insert(I-1).
>>
>> start() ->
>>    ets:new(set0, [set, named_table]),
>>    {Usec, _} = timer:tc(?MODULE, set0_insert, [?M]),
>>    io:format("set0: ~p [usec]~n", [Usec]),
>>    {Usec2, _} = timer:tc(ets, delete_all_objcets, [set0]),
>>    io:format("set0: ~p [usec]~n", [Usec2]),
>>    ets:delete(set0),
>>
>>    ets:new(bag, [bag, named_table]),
>>    {Usec3, _} = timer:tc(?MODULE, bag_insert, [?M]),
>>    io:format("bag: ~p [usec]~n", [Usec3]),
>>    {Usec4, _} = timer:tc(ets, delete_all_objcets, [bag]),
>>    io:format("bag: ~p [usec]~n", [Usec4]),
>>    ets:delete(bag),
>>
>>    ets:new(set, [set, named_table]),
>>    {Usec5, _} = timer:tc(?MODULE, set_insert, [?M]),
>>    io:format("set: ~p [usec]~n", [Usec5]),
>>    {Usec6, _} = timer:tc(ets, delete_all_objcets, [set]),
>>    io:format("set: ~p [usec]~n", [Usec6]),
>>    ets:delete(set).
>>
>> --
>>  Takeru INOUE <tak...@gm...>
>>
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Kai-users-ja mailing list
> Kai...@li...
> https://lists.sourceforge.net/lists/listinfo/kai-users-ja
>



-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-users-ja] オブジェクトが二重になってしまった場合のSET

[Tomoya H. <tom...@gm...>]

橋本です。

detsについてはあまり理解がないのですが、set->bagにするとデータの互換性がなくなって以前のデータがすべて失われる・・・なんてことがなければよいのですが。

本格的に使うのは恐らくGW前からになりそうです。

2009/03/15 22:06 Takeru INOUE <tak...@gm...>:
> 2009/3/14 shunichi shinohara <shi...@gm...>:
>> 2009/3/14 Takeru INOUE <tak...@gm...>:
>>> 二つの解決策があって，どちらも対応する必要がありそうです．
>>>
>>> 1. 途中になっているデータ同期のメカニズムを同期する．
>>> Kai では，ノード間で定期的にデータを同期します．
>>> ただし，現在は，あるデータを持っていなければ他ノードから取得しますが，持っていればバージョンが古くでも同期しません．
>>> この同期を行うことで，ある程度時間が経て箱の問題は解決されるようになります．
>>>
>>> 2. ある程度時間が経つまではどうするか．
>>> shino さんが言うように，複数バージョンのデータを格納してしまう，というのが根本的な解決策になると思います．
>>> ets/dets を set から bag に変更する必要がありますねぇ．
>>> 性能が落ちないか心配．．
>>
>> bag にまではしなくても、set のままで、
>> 現状の data が入っている部分を、data のリストにすれば良いかと考えています。
>> 新規のキー/値の set の場合には、
>>
>>    ets:insert(?MODULE, Data),
>>
>> のところが、
>>
>>    ets:insert(?MODULE, [Data]),
>>
>> となるイメージです。
>
>> # この方法と bag のどちらが性能が良いかは試さないと分からないですが f(--)
>
> 自分の作業メモを見返したら，去年の 5/9 にまさにそのような実験をやってました．
>
> # なんでこんなことしたんだろう?
>
> 結論としては，今回のように配列長が小さいときは，set に配列を入れるより bag を使うほうが少し速いようです．
>
> ■ 前置き
>
> bag では一つのキーが複数の値を持つことができる．
>
> | key | value
> | 1   | 1
> | 1   | 2
> | 1   | 3
> | 2   | 1
> | ... |
>
> また，set でもリストを使うことによって，同様のことができる．すでに
> 存在する値を取り出し，追加して再格納する．
>
> | key | value
> | 1   | [1, 2, 3]
> | 2   | [1, ...]
> | ... |
>
> キーあたりの値の数を変化させて，insert の性能を評価した．insert 回
> 数は M=1024 とし，キーあたりの値の数 N を変化させて時間 (usec) を測
> 定した．
>
> ■ 結果
>
> | N     | set0 | bag  | set
> | 1     | 2227 | 1907 | 2668
> | 3     | 2166 | 2295 | 3872
> | 16    | 2195 | 3638 | 6122
> | 64    | 1939 | 7254 | 14912
> | 256   | 2214 | 22678| 54228
> | 1024  | 2164 | 78904| 206331
>
> 表中の set では，上のようにして一つのキーに複数の値を持たせた．表中
> の set0 は比較材料であり，set に対して単純に 1024 回のinsert を行っ
> た (つまり，N の影響を受けない)．
>
> 結果より，bag では，キーあたりの値数に比例して時間がかかることがわ
> かった．また，set も同様の傾向を見せているが，これは insert 時にメ
> モリ再割り当てが行われるためである．よって，bag でも同じキーに値を
> 追加するときにはメモリの再割り当てが行われていると予想される．
>
> なお，set0 は N の影響を受けないため，一定の時間となっている．
>
> 以上より，bag を利用するときは，キーあたりの値の数に注意しなければ
> ならない．これが多いときには他のアルゴリズムを検討すべきである．
>
> ■ ソースコード
>
> -module(setbag).
> -compile(export_all).
> -define(M, 1024). % 1024, 4096, 16384
> -define(N, 1024). % 1, 3, 16, 64, 256, 1024
>
> set0_insert(0) ->
>    ok;
> set0_insert(I) ->
>    ets:insert(set0, {I, {{127,0,0,1}, I}}),
>    set0_insert(I-1).
>
> bag_insert(0) ->
>    ok;
> bag_insert(I) ->
>    Key = I div ?N,
>    ets:insert(bag, {Key, {{127,0,0,1}, I}}),
>    bag_insert(I-1).
>
> set_insert(0) ->
>    ok;
> set_insert(I) ->
>    Key = I div ?N,
>    Nodes =
>        case ets:lookup(set, Key) of
>            [{Key, N}|_] -> N;
>            _Other -> []
>        end,
>    ets:insert(set, {Key, [{{127,0,0,1}, I}|Nodes]}),
>    set_insert(I-1).
>
> start() ->
>    ets:new(set0, [set, named_table]),
>    {Usec, _} = timer:tc(?MODULE, set0_insert, [?M]),
>    io:format("set0: ~p [usec]~n", [Usec]),
>    {Usec2, _} = timer:tc(ets, delete_all_objcets, [set0]),
>    io:format("set0: ~p [usec]~n", [Usec2]),
>    ets:delete(set0),
>
>    ets:new(bag, [bag, named_table]),
>    {Usec3, _} = timer:tc(?MODULE, bag_insert, [?M]),
>    io:format("bag: ~p [usec]~n", [Usec3]),
>    {Usec4, _} = timer:tc(ets, delete_all_objcets, [bag]),
>    io:format("bag: ~p [usec]~n", [Usec4]),
>    ets:delete(bag),
>
>    ets:new(set, [set, named_table]),
>    {Usec5, _} = timer:tc(?MODULE, set_insert, [?M]),
>    io:format("set: ~p [usec]~n", [Usec5]),
>    {Usec6, _} = timer:tc(ets, delete_all_objcets, [set]),
>    io:format("set: ~p [usec]~n", [Usec6]),
>    ets:delete(set).
>
> --
>  Takeru INOUE <tak...@gm...>
>

Re: [Kai-users-ja] オブジェクトが二重になってしまった場合のSET

[Takeru I. <tak...@gm...>]

2009/3/14 shunichi shinohara <shi...@gm...>:
> 2009/3/14 Takeru INOUE <tak...@gm...>:
>> 二つの解決策があって，どちらも対応する必要がありそうです．
>>
>> 1. 途中になっているデータ同期のメカニズムを同期する．
>> Kai では，ノード間で定期的にデータを同期します．
>> ただし，現在は，あるデータを持っていなければ他ノードから取得しますが，持っていればバージョンが古くでも同期しません．
>> この同期を行うことで，ある程度時間が経て箱の問題は解決されるようになります．
>>
>> 2. ある程度時間が経つまではどうするか．
>> shino さんが言うように，複数バージョンのデータを格納してしまう，というのが根本的な解決策になると思います．
>> ets/dets を set から bag に変更する必要がありますねぇ．
>> 性能が落ちないか心配．．
>
> bag にまではしなくても、set のままで、
> 現状の data が入っている部分を、data のリストにすれば良いかと考えています。
> 新規のキー/値の set の場合には、
>
>    ets:insert(?MODULE, Data),
>
> のところが、
>
>    ets:insert(?MODULE, [Data]),
>
> となるイメージです。

> # この方法と bag のどちらが性能が良いかは試さないと分からないですが f(--)

自分の作業メモを見返したら，去年の 5/9 にまさにそのような実験をやってました．

# なんでこんなことしたんだろう?

結論としては，今回のように配列長が小さいときは，set に配列を入れるより bag を使うほうが少し速いようです．

■ 前置き

bag では一つのキーが複数の値を持つことができる．

| key | value
| 1   | 1
| 1   | 2
| 1   | 3
| 2   | 1
| ... |

また，set でもリストを使うことによって，同様のことができる．すでに
存在する値を取り出し，追加して再格納する．

| key | value
| 1   | [1, 2, 3]
| 2   | [1, ...]
| ... |

キーあたりの値の数を変化させて，insert の性能を評価した．insert 回
数は M=1024 とし，キーあたりの値の数 N を変化させて時間 (usec) を測
定した．

■ 結果

| N	| set0 | bag  | set
| 1	| 2227 | 1907 | 2668
| 3	| 2166 | 2295 | 3872
| 16	| 2195 | 3638 | 6122
| 64	| 1939 | 7254 | 14912
| 256	| 2214 | 22678| 54228
| 1024	| 2164 | 78904| 206331

表中の set では，上のようにして一つのキーに複数の値を持たせた．表中
の set0 は比較材料であり，set に対して単純に 1024 回のinsert を行っ
た (つまり，N の影響を受けない)．

結果より，bag では，キーあたりの値数に比例して時間がかかることがわ
かった．また，set も同様の傾向を見せているが，これは insert 時にメ
モリ再割り当てが行われるためである．よって，bag でも同じキーに値を
追加するときにはメモリの再割り当てが行われていると予想される．

なお，set0 は N の影響を受けないため，一定の時間となっている．

以上より，bag を利用するときは，キーあたりの値の数に注意しなければ
ならない．これが多いときには他のアルゴリズムを検討すべきである．

■ ソースコード

-module(setbag).
-compile(export_all).
-define(M, 1024). % 1024, 4096, 16384
-define(N, 1024). % 1, 3, 16, 64, 256, 1024

set0_insert(0) ->
    ok;
set0_insert(I) ->
    ets:insert(set0, {I, {{127,0,0,1}, I}}),
    set0_insert(I-1).

bag_insert(0) ->
    ok;
bag_insert(I) ->
    Key = I div ?N,
    ets:insert(bag, {Key, {{127,0,0,1}, I}}),
    bag_insert(I-1).

set_insert(0) ->
    ok;
set_insert(I) ->
    Key = I div ?N,
    Nodes =
	case ets:lookup(set, Key) of
	    [{Key, N}|_] -> N;
	    _Other -> []
	end,
    ets:insert(set, {Key, [{{127,0,0,1}, I}|Nodes]}),
    set_insert(I-1).

start() ->
    ets:new(set0, [set, named_table]),
    {Usec, _} = timer:tc(?MODULE, set0_insert, [?M]),
    io:format("set0: ~p [usec]~n", [Usec]),
    {Usec2, _} = timer:tc(ets, delete_all_objcets, [set0]),
    io:format("set0: ~p [usec]~n", [Usec2]),
    ets:delete(set0),

    ets:new(bag, [bag, named_table]),
    {Usec3, _} = timer:tc(?MODULE, bag_insert, [?M]),
    io:format("bag: ~p [usec]~n", [Usec3]),
    {Usec4, _} = timer:tc(ets, delete_all_objcets, [bag]),
    io:format("bag: ~p [usec]~n", [Usec4]),
    ets:delete(bag),

    ets:new(set, [set, named_table]),
    {Usec5, _} = timer:tc(?MODULE, set_insert, [?M]),
    io:format("set: ~p [usec]~n", [Usec5]),
    {Usec6, _} = timer:tc(ets, delete_all_objcets, [set]),
    io:format("set: ~p [usec]~n", [Usec6]),
    ets:delete(set).

-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-users-ja] オブジェクトが二重になってしまった場合のSET

[shunichi s. <shi...@gm...>]

2009/3/14 Takeru INOUE <tak...@gm...>:
> 二つの解決策があって，どちらも対応する必要がありそうです．
>
> 1. 途中になっているデータ同期のメカニズムを同期する．
> Kai では，ノード間で定期的にデータを同期します．
> ただし，現在は，あるデータを持っていなければ他ノードから取得しますが，持っていればバージョンが古くでも同期しません．
> この同期を行うことで，ある程度時間が経て箱の問題は解決されるようになります．
>
> 2. ある程度時間が経つまではどうするか．
> shino さんが言うように，複数バージョンのデータを格納してしまう，というのが根本的な解決策になると思います．
> ets/dets を set から bag に変更する必要がありますねぇ．
> 性能が落ちないか心配．．

bag にまではしなくても、set のままで、
現状の data が入っている部分を、data のリストにすれば良いかと考えています。
新規のキー/値の set の場合には、

    ets:insert(?MODULE, Data),

のところが、

    ets:insert(?MODULE, [Data]),

となるイメージです。
# この方法と bag のどちらが性能が良いかは試さないと分からないですが f(--)

-- 
shino

Re: [Kai-users-ja] オブジェクトが二重になってしまった場合のSET

[Takeru I. <tak...@gm...>]

二つの解決策があって，どちらも対応する必要がありそうです．

1. 途中になっているデータ同期のメカニズムを同期する．
Kai では，ノード間で定期的にデータを同期します．
ただし，現在は，あるデータを持っていなければ他ノードから取得しますが，持っていればバージョンが古くでも同期しません．
この同期を行うことで，ある程度時間が経て箱の問題は解決されるようになります．

2. ある程度時間が経つまではどうするか．
shino さんが言うように，複数バージョンのデータを格納してしまう，というのが根本的な解決策になると思います．
ets/dets を set から bag に変更する必要がありますねぇ．
性能が落ちないか心配．．


2009/3/13 shunichi shinohara <shi...@gm...>:
> しのはらです。
> いつもありがとうございます (o^<^)o
>
> 2009/3/13 Tomoya Hashimoto <tom...@gm...>:
>> ノードA,B,Cでクラスターを組み、ロードバランサーを使ってラウンドロビンで順番にノードA,B,Cにアクセスするような構成を組んでいました。ノードCがクラスターから脱落していた状況に気がつかない状態で、ロードバランサー経由で何度かオブジェクト
>> hoge をSETをすると、ノードA,B上のオブジェクト hogeと、ノードC上のオブジェクト hogeが出来上がります。
>>
>> この状況でノードCが脱落していたことに気付いてクラスターに参加させると、オブジェクト hogeが重なる状態が出来上がります。
>>
>> このように見えました。間違ってますかね？
>
> そのような状況になるとおもいます。
> # ちなみに dets を使っているのでよいでしょうか?
>
>> この後にオブジェクト hogeをSETしようとしてもエラーになるようです。一度DELETEしてからSETすれば入るようです。
>
> これは常にエラーになるのでしょうか? それとも SET をなげるノードによって成功したり失敗したりでしょうか?
> 原因が同じかどうか分からないですが、一つの問題としてtrunk/test にテストケースを追加してみました。
> 意図的に 古いバージョンをつくりだすと、新しいデータを持つノードが coordinate すると成功しますが、
> 古いバージョンを持ったノードが coordinate するとエラーになります。
> 上のケースでいうと C が coordinator になるばあいにはエラーになるとおもいます。
> # エラーにならずに、成功するのが正しい(望ましい)挙動だとおもいます
>
>> SETできなくなってしまうのはちょっとつらいです。
>
> すみません (T-T)
>
>> 二重になってしまったオブジェクトにSETすると二重状態が解消されるのがよいのではないかと思うのですが、いかがでしょうか。
>
> それが望ましいです。
> まず、今回のエラーの原因を特定してからですが、set/cas の挙動(仕様)と、(手をつけられずにいる)1 ノードでの
> 複数バージョンを考える必要があるとおもいます。
>
> --
> shino
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Kai-users-ja mailing list
> Kai...@li...
> https://lists.sourceforge.net/lists/listinfo/kai-users-ja
>



-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-users-ja] VERSIONコマンドを新設できませんか？

[Takeru I. <tak...@gm...>]

テストが通らないのに commit してしまいました．．
修正しました．

2009/3/13 Tomoya Hashimoto <tom...@gm...>:
> 橋本です。
>
> おお〜 早速の修正ありがとうございます。tcpdumpして動作は確認しました。
>
> ノードを落としてから復帰させて、とかやっている最中です。なにか出てきたらまたお願いします。
>
> 2009/03/13 21:22 Takeru INOUE <tak...@gm...>:
>> trunk/ で version をサポートしました．
>>
>>> 立て続けに失礼します。単刀直入にversionコマンドを新設できないでしょうか。
>>>
>>> PECLにあるmemcacheクライアントはversionコマンドを使って接続の維持を確認するコードが入っているようです。
>>
>> そんなことをするのですね．
>> 最初，stats に version が含まれてるのに，なんで必要なんだろうと思いました．．
>>
>> # set の問題の方，わかる? ＞しのさん
>>
>>> http://cvs.php.net/viewvc.cgi/pecl/memcache/memcache.c?revision=1.111&view=markup&pathrev=RELEASE_2_2_5
>>>
>>> ここの1014行目付近あたりだと思われます。
>>>
>>> 現状のkaiはversionが送られるとERRORを返すので挙動が怪しくなっているようです。
>>>
>>> いかがでしょうか。
>>>
>>> ------------------------------------------------------------------------------
>>> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
>>> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
>>> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
>>> software that enables intelligent coding and step-through debugging.
>>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
>>> _______________________________________________
>>> Kai-users-ja mailing list
>>> Kai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja
>>>
>>
>>
>>
>> --
>>  Takeru INOUE <tak...@gm...>
>>
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Kai-users-ja mailing list
> Kai...@li...
> https://lists.sourceforge.net/lists/listinfo/kai-users-ja
>



-- 
  Takeru INOUE <tak...@gm...>

Re: [Kai-users-ja] オブジェクトが二重になってしまった場合のSET

[shunichi s. <shi...@gm...>]

しのはらです。
いつもありがとうございます (o^<^)o

2009/3/13 Tomoya Hashimoto <tom...@gm...>:
> ノードA,B,Cでクラスターを組み、ロードバランサーを使ってラウンドロビンで順番にノードA,B,Cにアクセスするような構成を組んでいました。ノードCがクラスターから脱落していた状況に気がつかない状態で、ロードバランサー経由で何度かオブジェクト
> hoge をSETをすると、ノードA,B上のオブジェクト hogeと、ノードC上のオブジェクト hogeが出来上がります。
>
> この状況でノードCが脱落していたことに気付いてクラスターに参加させると、オブジェクト hogeが重なる状態が出来上がります。
>
> このように見えました。間違ってますかね？

そのような状況になるとおもいます。
# ちなみに dets を使っているのでよいでしょうか?

> この後にオブジェクト hogeをSETしようとしてもエラーになるようです。一度DELETEしてからSETすれば入るようです。

これは常にエラーになるのでしょうか? それとも SET をなげるノードによって成功したり失敗したりでしょうか?
原因が同じかどうか分からないですが、一つの問題としてtrunk/test にテストケースを追加してみました。
意図的に 古いバージョンをつくりだすと、新しいデータを持つノードが coordinate すると成功しますが、
古いバージョンを持ったノードが coordinate するとエラーになります。
上のケースでいうと C が coordinator になるばあいにはエラーになるとおもいます。
# エラーにならずに、成功するのが正しい(望ましい)挙動だとおもいます

> SETできなくなってしまうのはちょっとつらいです。

すみません (T-T)

> 二重になってしまったオブジェクトにSETすると二重状態が解消されるのがよいのではないかと思うのですが、いかがでしょうか。

それが望ましいです。
まず、今回のエラーの原因を特定してからですが、set/cas の挙動(仕様)と、(手をつけられずにいる)1 ノードでの
複数バージョンを考える必要があるとおもいます。

-- 
shino

Re: [Kai-users-ja] VERSIONコマンドを新設できませんか？

[Tomoya H. <tom...@gm...>]

橋本です。

おお〜 早速の修正ありがとうございます。tcpdumpして動作は確認しました。

ノードを落としてから復帰させて、とかやっている最中です。なにか出てきたらまたお願いします。

2009/03/13 21:22 Takeru INOUE <tak...@gm...>:
> trunk/ で version をサポートしました．
>
>> 立て続けに失礼します。単刀直入にversionコマンドを新設できないでしょうか。
>>
>> PECLにあるmemcacheクライアントはversionコマンドを使って接続の維持を確認するコードが入っているようです。
>
> そんなことをするのですね．
> 最初，stats に version が含まれてるのに，なんで必要なんだろうと思いました．．
>
> # set の問題の方，わかる? ＞しのさん
>
>> http://cvs.php.net/viewvc.cgi/pecl/memcache/memcache.c?revision=1.111&view=markup&pathrev=RELEASE_2_2_5
>>
>> ここの1014行目付近あたりだと思われます。
>>
>> 現状のkaiはversionが送られるとERRORを返すので挙動が怪しくなっているようです。
>>
>> いかがでしょうか。
>>
>> ------------------------------------------------------------------------------
>> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
>> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
>> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
>> software that enables intelligent coding and step-through debugging.
>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
>> _______________________________________________
>> Kai-users-ja mailing list
>> Kai...@li...
>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja
>>
>
>
>
> --
>  Takeru INOUE <tak...@gm...>
>

Re: [Kai-users-ja] VERSIONコマンドを新設できませんか？

[Takeru I. <tak...@gm...>]

trunk/ で version をサポートしました．

> 立て続けに失礼します。単刀直入にversionコマンドを新設できないでしょうか。
>
> PECLにあるmemcacheクライアントはversionコマンドを使って接続の維持を確認するコードが入っているようです。

そんなことをするのですね．
最初，stats に version が含まれてるのに，なんで必要なんだろうと思いました．．

# set の問題の方，わかる? ＞しのさん

> http://cvs.php.net/viewvc.cgi/pecl/memcache/memcache.c?revision=1.111&view=markup&pathrev=RELEASE_2_2_5
>
> ここの1014行目付近あたりだと思われます。
>
> 現状のkaiはversionが送られるとERRORを返すので挙動が怪しくなっているようです。
>
> いかがでしょうか。
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Kai-users-ja mailing list
> Kai...@li...
> https://lists.sourceforge.net/lists/listinfo/kai-users-ja
>



-- 
  Takeru INOUE <tak...@gm...>

[Kai-users-ja] VERSIONコマンドを新設できませんか？

[Tomoya H. <tom...@gm...>]

橋本です。

立て続けに失礼します。単刀直入にversionコマンドを新設できないでしょうか。

PECLにあるmemcacheクライアントはversionコマンドを使って接続の維持を確認するコードが入っているようです。

http://cvs.php.net/viewvc.cgi/pecl/memcache/memcache.c?revision=1.111&view=markup&pathrev=RELEASE_2_2_5

ここの1014行目付近あたりだと思われます。

現状のkaiはversionが送られるとERRORを返すので挙動が怪しくなっているようです。

いかがでしょうか。

[Kai-users-ja] オブジェクトが二重になってしまった場合のSET

[Tomoya H. <tom...@gm...>]

橋本です。

オブジェクトがクラスター内で二重になってしまった場合のSETについて教えてください。

クラスター内で同じkeyを持つオブジェクトが存在してしまいました。比較的簡単に発生するようです。

ノードA,B,Cでクラスターを組み、ロードバランサーを使ってラウンドロビンで順番にノードA,B,Cにアクセスするような構成を組んでいました。ノードCがクラスターから脱落していた状況に気がつかない状態で、ロードバランサー経由で何度かオブジェクト
hoge をSETをすると、ノードA,B上のオブジェクト hogeと、ノードC上のオブジェクト hogeが出来上がります。

この状況でノードCが脱落していたことに気付いてクラスターに参加させると、オブジェクト hogeが重なる状態が出来上がります。

このように見えました。間違ってますかね？

この後にオブジェクト hogeをSETしようとしてもエラーになるようです。一度DELETEしてからSETすれば入るようです。

SETできなくなってしまうのはちょっとつらいです。

二重になってしまったオブジェクトにSETすると二重状態が解消されるのがよいのではないかと思うのですが、いかがでしょうか。

Re: [Kai-users-ja] quitを送らない場合の後始末

[masahito i. <coo...@gm...>]

橋本さん

幾田です。
早速の検証ありがとうございました！
今後とも、よろしくお願い致します。

2009/2/26 Tomoya Hashimoto <tom...@gm...>:
> 橋本です。
>
> 対応ありがとうございました。
>
> 早速新しいコードに入れ換えて問題を報告した環境で丸一日使ってみました。問題は発生していません。
>
> cactiのプラグインも動いてます。
>
> 以上報告でした。ありがとうございました。
>
> 2009/02/25 19:12 Takeru INOUE <tak...@gm...>:
>> お疲れ様でした．
>>
>> 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...>
>> ------------------------------------------------------------------------------
>> 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
>>
> ------------------------------------------------------------------------------
> 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
>



-- 
cooldaemon

Re: [Kai-users-ja] quitを送らない場合の後始末

[Tomoya H. <tom...@gm...>]

橋本です。

対応ありがとうございました。

早速新しいコードに入れ換えて問題を報告した環境で丸一日使ってみました。問題は発生していません。

cactiのプラグインも動いてます。

以上報告でした。ありがとうございました。

2009/02/25 19:12 Takeru INOUE <tak...@gm...>:
> お疲れ様でした．
>
> 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...>
> ------------------------------------------------------------------------------
> 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
>