kai-users-ja Mailing List for kai (Page 4)
Kai is a distributed key-value datastore
Status: Beta
Brought to you by:
takemaru
Menu
▾
▴
kai-users-ja — For Kai users in Japanese
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: Tomoya H. <tom...@gm...> - 2009-01-23 10:26:17
|
橋本です.
お返事遅くなりました.
最初に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を同一の物理サーバに３つ起動してクラスターを組んでいたのですが、ある時点からクライアントからの接続をいきなり切断されるようになってしまいました。
>>>
>>>
>>> [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}"
>>>
>>> クラスターを組んでいる残り２つの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...>
>
|
|
From: Takeru I. <tak...@gm...> - 2009-01-22 14:28:54
|
表題の件ですが，解決しましたでしょうか．
アーカイブに残ると他の方の参考にもなりますので，お返事いただけると嬉しいです．
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を同一の物理サーバに３つ起動してクラスターを組んでいたのですが、ある時点からクライアントからの接続をいきなり切断されるようになってしまいました。
>>
>>
>> [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}"
>>
>> クラスターを組んでいる残り２つの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...>
|
|
From: Takeru I. <tak...@gm...> - 2009-01-19 13:30:21
|
井上です．
比較的，長い時間にわたって運用したときに発生しますでしょうか．
また，しばらくは切断され続けるでしょうか．
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を同一の物理サーバに３つ起動してクラスターを組んでいたのですが、ある時点からクライアントからの接続をいきなり切断されるようになってしまいました。
>
>
> [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}"
>
> クラスターを組んでいる残り２つの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...>
|
|
From: Tomoya H. <tom...@gm...> - 2009-01-19 09:33:29
|
橋本です。
kaiを同一の物理サーバに３つ起動してクラスターを組んでいたのですが、ある時点からクライアントからの接続をいきなり切断されるようになってしまいました。
[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}"
クラスターを組んでいる残り２つのkaiは問題なく動作しているように見えます。
実運用で起きても困るのでなんとか原因を追いたいのですが、なにか思い当たらないでしょうか。
よろしくお願いします。
--
Tomoya Hashimoto <tom...@gm...>
|
|
From: Takeru I. <tak...@gm...> - 2008-12-04 14:52:43
|
いつもいつもありがとうございます． 不明コマンドが送られたときの戻り値を，ケアレスミスで間違えていました．． trunk/ (revision 103) で直っています． 2008/12/4 Tomoya Hashimoto <tom...@gm...>: > 橋本です。 > > リビジョン102で試してみたところ、ばっちり動きました。PHPのmemcachedクライアントからも問題なく動作しました。 > > 手動でコマンドをkaiに送っていたときに思ったのですが、エラーの時の動き方がmemcachedと違う場合があります。 > ちゃんと調べていないのですが、memcachedは"ERROR"と返して接続を維持するのに対して、kaiは切断してしまう点が異なります。様々な言語にmemcachedクライアントが実装されていますが、この挙動の違いに引っ掛かる実装があるかもしれないと思いました。 > > 2008/12/03 23:56 Takeru INOUE <tak...@gm...>: >> いつもありがとうございます． >> >>> delete <key> [<time>] [noreply]\r\n >> >> time の存在を考慮していませんでしたので，修正しました． >> 最新の trunk/ をチェックしてください． >> >> time = 0 であれば正常に動作します． >> 0 以外のときには，エラーが返ります． >> >> >> 2008/12/3 Tomoya Hashimoto <tom...@gm...>: >>> 橋本です。 >>> >>> deleteの挙動について質問です。 >>> >>> memcachedのプロトコル仕様書ではdeleteは以下のように定義されています。 >>> >>> delete <key> [<time>] [noreply]\r\n >>> >>> ですが、kaiにこの様式で送るとコネクションを切られます。 >>> >>> [t-hashi@gtp301 work]$ telnet gtp205 11211 >>> Trying 172.20.31.205... >>> Connected to gtp205 (172.20.31.205). >>> Escape character is '^]'. >>> set hoge 0 0 10 >>> 0123456789 >>> STORED >>> get hoge >>> VALUE hoge 0 10 >>> 0123456789 >>> END >>> delete hoge 0 <- ここ >>> Connection closed by foreign host. >>> [t-hashi@gtp301 work]$ >>> >>> timeをつけると問答無用で切断されます。timeをつけないと期待通りに動きます。 >>> >>> [t-hashi@gtp301 work]$ telnet gtp205 11211 >>> Trying 172.20.31.205... >>> Connected to gtp205 (172.20.31.205). >>> Escape character is '^]'. >>> set hoge 0 0 10 >>> 0123456789 >>> STORED >>> get hoge >>> VALUE hoge 0 10 >>> 0123456789 >>> END >>> delete hoge >>> DELETED >>> get hoge >>> END >>> quit >>> Connection closed by foreign host. >>> >>> PHPでサンプルコードを書くとdeleteができないように見えて発見しました。tcpdumpしてみるとPHPのmemcachedクライアントは >>> timeをつけて送信していました。結果的にPHPからdeleteを送った後は予期しない動きになってしまします。 >>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >>> Build the coolest Linux based applications with Moblin SDK & win great prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> _______________________________________________ >>> Kai-users-ja mailing list >>> Kai...@li... >>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>> >> >> >> >> -- >> Takeru INOUE <tak...@gm...> >> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > 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...> - 2008-12-04 07:42:43
|
橋本です。 リビジョン102で試してみたところ、ばっちり動きました。PHPのmemcachedクライアントからも問題なく動作しました。 手動でコマンドをkaiに送っていたときに思ったのですが、エラーの時の動き方がmemcachedと違う場合があります。 ちゃんと調べていないのですが、memcachedは"ERROR"と返して接続を維持するのに対して、kaiは切断してしまう点が異なります。様々な言語にmemcachedクライアントが実装されていますが、この挙動の違いに引っ掛かる実装があるかもしれないと思いました。 2008/12/03 23:56 Takeru INOUE <tak...@gm...>: > いつもありがとうございます． > >> delete <key> [<time>] [noreply]\r\n > > time の存在を考慮していませんでしたので，修正しました． > 最新の trunk/ をチェックしてください． > > time = 0 であれば正常に動作します． > 0 以外のときには，エラーが返ります． > > > 2008/12/3 Tomoya Hashimoto <tom...@gm...>: >> 橋本です。 >> >> deleteの挙動について質問です。 >> >> memcachedのプロトコル仕様書ではdeleteは以下のように定義されています。 >> >> delete <key> [<time>] [noreply]\r\n >> >> ですが、kaiにこの様式で送るとコネクションを切られます。 >> >> [t-hashi@gtp301 work]$ telnet gtp205 11211 >> Trying 172.20.31.205... >> Connected to gtp205 (172.20.31.205). >> Escape character is '^]'. >> set hoge 0 0 10 >> 0123456789 >> STORED >> get hoge >> VALUE hoge 0 10 >> 0123456789 >> END >> delete hoge 0 <- ここ >> Connection closed by foreign host. >> [t-hashi@gtp301 work]$ >> >> timeをつけると問答無用で切断されます。timeをつけないと期待通りに動きます。 >> >> [t-hashi@gtp301 work]$ telnet gtp205 11211 >> Trying 172.20.31.205... >> Connected to gtp205 (172.20.31.205). >> Escape character is '^]'. >> set hoge 0 0 10 >> 0123456789 >> STORED >> get hoge >> VALUE hoge 0 10 >> 0123456789 >> END >> delete hoge >> DELETED >> get hoge >> END >> quit >> Connection closed by foreign host. >> >> PHPでサンプルコードを書くとdeleteができないように見えて発見しました。tcpdumpしてみるとPHPのmemcachedクライアントは >> timeをつけて送信していました。結果的にPHPからdeleteを送った後は予期しない動きになってしまします。 >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Kai-users-ja mailing list >> Kai...@li... >> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >> > > > > -- > Takeru INOUE <tak...@gm...> > |
|
From: Takeru I. <tak...@gm...> - 2008-12-03 14:56:12
|
いつもありがとうございます． > delete <key> [<time>] [noreply]\r\n time の存在を考慮していませんでしたので，修正しました． 最新の trunk/ をチェックしてください． time = 0 であれば正常に動作します． 0 以外のときには，エラーが返ります． 2008/12/3 Tomoya Hashimoto <tom...@gm...>: > 橋本です。 > > deleteの挙動について質問です。 > > memcachedのプロトコル仕様書ではdeleteは以下のように定義されています。 > > delete <key> [<time>] [noreply]\r\n > > ですが、kaiにこの様式で送るとコネクションを切られます。 > > [t-hashi@gtp301 work]$ telnet gtp205 11211 > Trying 172.20.31.205... > Connected to gtp205 (172.20.31.205). > Escape character is '^]'. > set hoge 0 0 10 > 0123456789 > STORED > get hoge > VALUE hoge 0 10 > 0123456789 > END > delete hoge 0 <- ここ > Connection closed by foreign host. > [t-hashi@gtp301 work]$ > > timeをつけると問答無用で切断されます。timeをつけないと期待通りに動きます。 > > [t-hashi@gtp301 work]$ telnet gtp205 11211 > Trying 172.20.31.205... > Connected to gtp205 (172.20.31.205). > Escape character is '^]'. > set hoge 0 0 10 > 0123456789 > STORED > get hoge > VALUE hoge 0 10 > 0123456789 > END > delete hoge > DELETED > get hoge > END > quit > Connection closed by foreign host. > > PHPでサンプルコードを書くとdeleteができないように見えて発見しました。tcpdumpしてみるとPHPのmemcachedクライアントは > timeをつけて送信していました。結果的にPHPからdeleteを送った後は予期しない動きになってしまします。 > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > 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...> - 2008-12-03 07:53:40
|
橋本です。 deleteの挙動について質問です。 memcachedのプロトコル仕様書ではdeleteは以下のように定義されています。 delete <key> [<time>] [noreply]\r\n ですが、kaiにこの様式で送るとコネクションを切られます。 [t-hashi@gtp301 work]$ telnet gtp205 11211 Trying 172.20.31.205... Connected to gtp205 (172.20.31.205). Escape character is '^]'. set hoge 0 0 10 0123456789 STORED get hoge VALUE hoge 0 10 0123456789 END delete hoge 0 <- ここ Connection closed by foreign host. [t-hashi@gtp301 work]$ timeをつけると問答無用で切断されます。timeをつけないと期待通りに動きます。 [t-hashi@gtp301 work]$ telnet gtp205 11211 Trying 172.20.31.205... Connected to gtp205 (172.20.31.205). Escape character is '^]'. set hoge 0 0 10 0123456789 STORED get hoge VALUE hoge 0 10 0123456789 END delete hoge DELETED get hoge END quit Connection closed by foreign host. PHPでサンプルコードを書くとdeleteができないように見えて発見しました。tcpdumpしてみるとPHPのmemcachedクライアントは timeをつけて送信していました。結果的にPHPからdeleteを送った後は予期しない動きになってしまします。 |
|
From: Takeru I. <ino...@la...> - 2008-11-18 07:05:11
|
詳細なログをありがとうございます． ets のときの CPU 使用率は，1 台が 60 % くらいで，もう 1 台が 3 % くらい ですね．1 台にしかリクエストを送ってないので，大きく負荷が偏っているよう です． この負荷試験では，ツールの制約により 1 台にしかリクエストが送れませんで したが，実際にはクラスタの各 PC に分散させると思うので，もう少しスルー プットが上がると思います． Tomoya Hashimoto さんは書きました: > 橋本です。 > > マシンスペックは以下の通りです。 > > * CPU > > Processor Brand : Intel(R) Xeon(R) CPU 5148 @ 2.33GHz > Processor Version : Model 15 Stepping 6 > Current Speed : 2333 MHz > > これが二つ。 > > * memory > > 4GB > > ネットワークは1000BASE-TXです。負荷をかけたときのネットワークの使用状況はモニターできて > いないのですが、このホストが900Mbpsまで行けることは確認してます。 > > この状態で負荷をかけたときのvmstatです。 > > [t-hashi@gtp301 ~]$ ./mcb -c get -a 172.20.31.205 -p 11211 -t 50 -n > 2000 -l 1024 -s -m 10000 > condition => > memcached = 172.20.31.205:11211 > command = get > 50 thread run > send 2000 command a thread, total 100000 command > data length = 1024 > result => > interval = 43.806301 [sec] > performance = 2282.776620 [command/sec] > thread info: > ave. = 42.160808[sec], min = 40.160611[sec], max = 43.804653[sec] > > > [t-hashi@gtp205 ~]$ vmstat -S m -n 2 > procs -----------memory---------- ---swap-- -----io---- --system-- > -----cpu------ > r b swpd free buff cache si so bi bo in cs us sy id wa st > 5 0 0 3526 18 270 0 0 13 7 122 234 0 > 0 100 0 0 > 3 0 0 3526 18 270 0 0 0 0 31016 38199 49 > 15 35 0 1 > 5 0 0 3525 18 270 0 0 0 16 31519 38553 48 > 15 36 0 1 > 4 0 0 3525 18 270 0 0 0 2 26418 32052 48 > 14 37 0 1 > 5 0 0 3525 18 270 0 0 0 0 30790 37966 47 > 18 35 0 1 > 7 0 0 3525 18 270 0 0 0 0 32458 40062 50 > 20 29 0 1 > 7 0 0 3525 18 270 0 0 0 22 33013 40854 51 > 19 29 0 1 > 5 0 0 3525 18 270 0 0 0 0 32784 40440 51 > 18 31 0 1 > 4 0 0 3525 18 270 0 0 0 6 31287 38188 50 > 16 33 0 1 > 4 0 0 3525 18 270 0 0 0 0 32566 40348 49 > 18 32 0 1 > 5 0 0 3525 18 270 0 0 0 0 32992 40846 51 > 16 33 0 1 > 5 0 0 3525 18 270 0 0 0 0 32861 40580 50 > 18 32 0 1 > 5 0 0 3525 18 270 0 0 0 0 32189 39737 46 > 19 34 0 1 > 5 0 0 3525 18 270 0 0 0 4 32994 40807 49 > 19 32 0 1 > 3 0 0 3525 18 270 0 0 0 0 33136 40862 50 > 17 33 0 1 > 3 0 0 3525 18 270 0 0 0 0 33312 41332 50 > 18 31 0 1 > 2 0 0 3525 18 270 0 0 0 12 31582 38786 48 > 18 34 0 1 > 4 0 0 3525 18 270 0 0 0 0 33237 40898 49 > 19 31 0 1 > 2 0 0 3525 18 270 0 0 0 0 33156 40825 48 > 18 33 0 1 > 6 0 0 3525 18 270 0 0 0 0 33395 40956 50 > 17 32 0 1 > 5 0 0 3525 18 270 0 0 0 6 31706 38739 53 > 16 30 0 1 > 1 0 0 3525 18 270 0 0 0 0 19777 24406 29 > 10 61 0 0 > 1 0 0 3525 18 270 0 0 0 0 735 1088 0 > 0 100 0 0 > 1 0 0 3525 18 270 0 0 0 8 721 1084 0 > 0 100 0 0 > 1 0 0 3525 18 270 0 0 0 0 730 1089 0 > 0 100 0 0 > > > [t-hashi@gtp206 ~]$ vmstat -S m 2 > procs -----------memory---------- ---swap-- -----io---- --system-- > -----cpu------ > r b swpd free buff cache si so bi bo in cs us sy id wa st > 1 0 0 3533 17 263 0 0 18 9 228 373 1 0 99 0 0 > 0 0 0 3533 17 263 0 0 0 0 2912 4254 1 1 98 0 0 > 3 0 0 3533 17 263 0 0 0 0 6042 8320 1 2 97 0 0 > 3 0 0 3533 17 263 0 0 0 12 5241 7352 1 2 97 0 0 > 5 0 0 3533 17 263 0 0 0 0 5564 7788 2 2 96 0 0 > 3 0 0 3533 17 263 0 0 0 0 5565 7708 1 2 97 0 0 > 3 0 0 3533 17 263 0 0 0 0 5427 7618 1 2 97 0 0 > 3 0 0 3533 17 263 0 0 0 0 5286 7386 1 2 97 0 0 > 3 0 0 3533 17 263 0 0 0 40 5532 7714 1 2 97 0 0 > 3 0 0 3533 17 263 0 0 0 0 5391 7587 1 2 96 0 0 > 3 0 0 3533 17 263 0 0 0 72 4742 6587 0 2 98 0 0 > 3 0 0 3533 17 263 0 0 0 0 5353 7485 2 2 96 0 0 > 3 0 0 3533 17 263 0 0 0 0 5450 7573 1 2 97 0 0 > 5 0 0 3533 17 263 0 0 0 4 5502 7693 1 2 96 0 0 > 3 0 0 3533 17 263 0 0 0 0 5385 7528 1 2 97 0 0 > 3 0 0 3533 17 263 0 0 0 6 5459 7575 1 2 97 0 0 > 3 0 0 3533 17 263 0 0 0 0 5385 7612 1 2 96 0 0 > 5 0 0 3533 17 263 0 0 0 0 5657 7738 1 2 97 0 0 > 5 0 0 3533 17 263 0 0 0 0 5559 7671 1 2 96 0 0 > 5 0 0 3533 17 263 0 0 0 0 5584 7745 1 2 97 0 0 > 5 0 0 3533 17 263 0 0 0 0 5560 7723 2 2 97 0 0 > 7 0 0 3533 17 263 0 0 0 0 5363 7408 1 1 98 0 0 > 3 0 0 3533 17 263 0 0 0 0 4960 6685 1 2 97 0 0 > 3 0 0 3533 17 263 0 0 0 8 490 847 0 > 0 100 0 0 > 3 0 0 3533 17 263 0 0 0 0 502 907 0 > 0 100 0 0 > 3 0 0 3533 17 263 0 0 0 0 500 846 0 > 0 100 0 0 > > [t-hashi@gtp301 ~]$ ./mcb -c get -a 172.20.31.205 -p 11211 -t 50 -n > 2000 -l 1024 -s -m 10000 > condition => > memcached = 172.20.31.205:11211 > command = get > 50 thread run > send 2000 command a thread, total 100000 command > data length = 1024 > result => > interval = 43.806301 [sec] > performance = 2282.776620 [command/sec] > thread info: > ave. = 42.160808[sec], min = 40.160611[sec], max = 43.804653[sec] > > > [t-hashi@gtp205 ~]$ vmstat -S m -n 2 > procs -----------memory---------- ---swap-- -----io---- --system-- > -----cpu------ > r b swpd free buff cache si so bi bo in cs us sy id wa st > 5 0 0 3526 18 270 0 0 13 7 122 234 0 > 0 100 0 0 > 3 0 0 3526 18 270 0 0 0 0 31016 38199 49 > 15 35 0 1 > 5 0 0 3525 18 270 0 0 0 16 31519 38553 48 > 15 36 0 1 > 4 0 0 3525 18 270 0 0 0 2 26418 32052 48 > 14 37 0 1 > 5 0 0 3525 18 270 0 0 0 0 30790 37966 47 > 18 35 0 1 > 7 0 0 3525 18 270 0 0 0 0 32458 40062 50 > 20 29 0 1 > 7 0 0 3525 18 270 0 0 0 22 33013 40854 51 > 19 29 0 1 > 5 0 0 3525 18 270 0 0 0 0 32784 40440 51 > 18 31 0 1 > 4 0 0 3525 18 270 0 0 0 6 31287 38188 50 > 16 33 0 1 > 4 0 0 3525 18 270 0 0 0 0 32566 40348 49 > 18 32 0 1 > 5 0 0 3525 18 270 0 0 0 0 32992 40846 51 > 16 33 0 1 > 5 0 0 3525 18 270 0 0 0 0 32861 40580 50 > 18 32 0 1 > 5 0 0 3525 18 270 0 0 0 0 32189 39737 46 > 19 34 0 1 > 5 0 0 3525 18 270 0 0 0 4 32994 40807 49 > 19 32 0 1 > 3 0 0 3525 18 270 0 0 0 0 33136 40862 50 > 17 33 0 1 > 3 0 0 3525 18 270 0 0 0 0 33312 41332 50 > 18 31 0 1 > 2 0 0 3525 18 270 0 0 0 12 31582 38786 48 > 18 34 0 1 > 4 0 0 3525 18 270 0 0 0 0 33237 40898 49 > 19 31 0 1 > 2 0 0 3525 18 270 0 0 0 0 33156 40825 48 > 18 33 0 1 > 6 0 0 3525 18 270 0 0 0 0 33395 40956 50 > 17 32 0 1 > 5 0 0 3525 18 270 0 0 0 6 31706 38739 53 > 16 30 0 1 > 1 0 0 3525 18 270 0 0 0 0 19777 24406 29 > 10 61 0 0 > 1 0 0 3525 18 270 0 0 0 0 735 1088 0 > 0 100 0 0 > 1 0 0 3525 18 270 0 0 0 8 721 1084 0 > 0 100 0 0 > 1 0 0 3525 18 270 0 0 0 0 730 1089 0 > 0 100 0 0 > > > [t-hashi@gtp206 ~]$ vmstat -S m 2 > procs -----------memory---------- ---swap-- -----io---- --system-- > -----cpu------ > r b swpd free buff cache si so bi bo in cs us sy id wa st > 1 0 0 3533 17 263 0 0 18 9 228 373 1 0 99 0 0 > 0 0 0 3533 17 263 0 0 0 0 2912 4254 1 1 98 0 0 > 3 0 0 3533 17 263 0 0 0 0 6042 8320 1 2 97 0 0 > 3 0 0 3533 17 263 0 0 0 12 5241 7352 1 2 97 0 0 > 5 0 0 3533 17 263 0 0 0 0 5564 7788 2 2 96 0 0 > 3 0 0 3533 17 263 0 0 0 0 5565 7708 1 2 97 0 0 > 3 0 0 3533 17 263 0 0 0 0 5427 7618 1 2 97 0 0 > 3 0 0 3533 17 263 0 0 0 0 5286 7386 1 2 97 0 0 > 3 0 0 3533 17 263 0 0 0 40 5532 7714 1 2 97 0 0 > 3 0 0 3533 17 263 0 0 0 0 5391 7587 1 2 96 0 0 > 3 0 0 3533 17 263 0 0 0 72 4742 6587 0 2 98 0 0 > 3 0 0 3533 17 263 0 0 0 0 5353 7485 2 2 96 0 0 > 3 0 0 3533 17 263 0 0 0 0 5450 7573 1 2 97 0 0 > 5 0 0 3533 17 263 0 0 0 4 5502 7693 1 2 96 0 0 > 3 0 0 3533 17 263 0 0 0 0 5385 7528 1 2 97 0 0 > 3 0 0 3533 17 263 0 0 0 6 5459 7575 1 2 97 0 0 > 3 0 0 3533 17 263 0 0 0 0 5385 7612 1 2 96 0 0 > 5 0 0 3533 17 263 0 0 0 0 5657 7738 1 2 97 0 0 > 5 0 0 3533 17 263 0 0 0 0 5559 7671 1 2 96 0 0 > 5 0 0 3533 17 263 0 0 0 0 5584 7745 1 2 97 0 0 > 5 0 0 3533 17 263 0 0 0 0 5560 7723 2 2 97 0 0 > 7 0 0 3533 17 263 0 0 0 0 5363 7408 1 1 98 0 0 > 3 0 0 3533 17 263 0 0 0 0 4960 6685 1 2 97 0 0 > 3 0 0 3533 17 263 0 0 0 8 490 847 0 > 0 100 0 0 > 3 0 0 3533 17 263 0 0 0 0 502 907 0 > 0 100 0 0 > 3 0 0 3533 17 263 0 0 0 0 500 846 0 > 0 100 0 0 > > --- > Tomoya Hashimoto > > > 2008/11/18 9:04 Takeru INOUE <tak...@gm...>: >> ets のスループットはもう少し上がりそうな気もします． >> >> 差し支えなければ，PC のスペックはどのくらいか教えていただけますでしょうか． >> あと，CPU 使用率と，ネットワークの状況 (Gbit?) はどうでしたでしょうか． >> >> >> 2008/11/17 Tomoya Hashimoto <tom...@gm...>: >>> 橋本です。 >>> >>> 早速Rev 99で同様に試してみました。こちらではエラーが発生しなくなりました。大体以下のような >>> 数字が得られました。detsはetsの1/3ぐらい、という結果でした。 >>> >>> ■ ets >>> >>> [t-hashi@gtp301 ~]$ ./mcb -c set -a 172.20.31.207 -p 11211 -t 200 -n >>> 100 -l 1024 -s -m 10000 >>> condition => >>> memcached = 172.20.31.207:11211 >>> command = set >>> 200 thread run >>> send 100 command a thread, total 20000 command >>> data length = 1024 >>> result => >>> interval = 12.847524 [sec] >>> performance = 1556.720199 [command/sec] >>> thread info: >>> ave. = 10.303019[sec], min = 2.445050[sec], max = 12.843495[sec] >>> >>> ■ dets >>> >>> [t-hashi@gtp301 ~]$ ./mcb -c set -a 172.20.31.205 -p 11211 -t 200 -n >>> 100 -l 1024 -s -m 10000 >>> condition => >>> memcached = 172.20.31.205:11211 >>> command = set >>> 200 thread run >>> send 100 command a thread, total 20000 command >>> data length = 1024 >>> result => >>> interval = 38.860149 [sec] >>> performance = 514.666064 [command/sec] >>> thread info: >>> ave. = 35.751326[sec], min = 19.174975[sec], max = 38.857620[sec] >>> [t-hashi@gtp301 ~]$ >>> >>> ＃今度のErlang勉強会にお邪魔するのでご挨拶させてください >>> >>> --- >>> Tomoya Hashimoto >>> >>> 2008/11/17 17:34 shinohara <shi...@gm...>: >>>> しのはら(shino)です。 >>>> # kai-users-ja にもクロスポストしてみます。 >>>> >>>> On 11/17/08 1:28 PM Tomoya Hashimoto wrote: >>>>> 使い方がまずいのかもしれませんが、私の手元ではエラーが出ているので報告させていただきます。 >>>>> >>>>> こちらのツールを使ってベンチマークを取っています。 >>>>> http://www.interdb.jp/techinfo/mcb/ >>>> エラー報告 & 便利なツールありがとうございます :-) >>>> >>>>> 初めの一回ぐらいはうまくいくのですが、リクエストするホストを変えたりして2,3回ほど試すとKaiがエラーを出力しています。 >>>>> >>>>> 7> >>>>> =ERROR REPORT==== 17-Nov-2008::13:08:21 === >>>>> Error in process <0.2140.0> with exit value: {{badmatch,{error,"stale >>>>> state"}},[{kai_coordinator,coordinate_put,1},{kai_coordinator,start_route,3}]} >>>> バグでした。branch で修正しましたので、確認してもらえるとありがたいです。 >>>> - vector clocks の更新で、過去データを元にノードのカウンターをインクレメントするようにした >>>> - 古い状態(stale state)かどうかの判断は、cas unique が渡ってくる cas でしか出来無い(と思う) >>>> ので、判断ロジックを削除 >>>> >>>> URL: https://kai.svn.sourceforge.net/svnroot/kai/branches/shino_vector_clocks >>>> Revision: 99 >>>> Last Changed Author: shino_shun >>>> Last Changed Rev: 99 >>>> Last Changed Date: 2008-11-17 16:52:10 +0900 (Mon, 17 Nov 2008) >>>> >>>> よろしくおねがいします m(_ _)m >>>> >>>> shino >>>> >>>> >>> ------------------------------------------------------------------------- >>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >>> Build the coolest Linux based applications with Moblin SDK & win great prizes >>> Grand prize is a trip for two to an Open Source event anywhere in the world >>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>> _______________________________________________ >>> Kai-users-ja mailing list >>> Kai...@li... >>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja >>> >> >> >> -- >> Takeru INOUE <tak...@gm...> >> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Kai-users-ja mailing list > Kai...@li... > https://lists.sourceforge.net/lists/listinfo/kai-users-ja > > -- 井上 武 - Takeru INOUE, Ph.D. NTT 未来ねっと研究所 NTT Network Innovation Laboratories Tel: +81-46-859-3030, Fax: +81-46-855-1284 e-mail: ino...@la..., tak...@ie... |
|
From: Tomoya H. <tom...@gm...> - 2008-11-18 05:39:03
|
橋本です。
マシンスペックは以下の通りです。
* CPU
Processor Brand : Intel(R) Xeon(R) CPU 5148 @ 2.33GHz
Processor Version : Model 15 Stepping 6
Current Speed : 2333 MHz
これが二つ。
* memory
4GB
ネットワークは1000BASE-TXです。負荷をかけたときのネットワークの使用状況はモニターできて
いないのですが、このホストが900Mbpsまで行けることは確認してます。
この状態で負荷をかけたときのvmstatです。
[t-hashi@gtp301 ~]$ ./mcb -c get -a 172.20.31.205 -p 11211 -t 50 -n
2000 -l 1024 -s -m 10000
condition =>
memcached = 172.20.31.205:11211
command = get
50 thread run
send 2000 command a thread, total 100000 command
data length = 1024
result =>
interval = 43.806301 [sec]
performance = 2282.776620 [command/sec]
thread info:
ave. = 42.160808[sec], min = 40.160611[sec], max = 43.804653[sec]
[t-hashi@gtp205 ~]$ vmstat -S m -n 2
procs -----------memory---------- ---swap-- -----io---- --system--
-----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
5 0 0 3526 18 270 0 0 13 7 122 234 0
0 100 0 0
3 0 0 3526 18 270 0 0 0 0 31016 38199 49
15 35 0 1
5 0 0 3525 18 270 0 0 0 16 31519 38553 48
15 36 0 1
4 0 0 3525 18 270 0 0 0 2 26418 32052 48
14 37 0 1
5 0 0 3525 18 270 0 0 0 0 30790 37966 47
18 35 0 1
7 0 0 3525 18 270 0 0 0 0 32458 40062 50
20 29 0 1
7 0 0 3525 18 270 0 0 0 22 33013 40854 51
19 29 0 1
5 0 0 3525 18 270 0 0 0 0 32784 40440 51
18 31 0 1
4 0 0 3525 18 270 0 0 0 6 31287 38188 50
16 33 0 1
4 0 0 3525 18 270 0 0 0 0 32566 40348 49
18 32 0 1
5 0 0 3525 18 270 0 0 0 0 32992 40846 51
16 33 0 1
5 0 0 3525 18 270 0 0 0 0 32861 40580 50
18 32 0 1
5 0 0 3525 18 270 0 0 0 0 32189 39737 46
19 34 0 1
5 0 0 3525 18 270 0 0 0 4 32994 40807 49
19 32 0 1
3 0 0 3525 18 270 0 0 0 0 33136 40862 50
17 33 0 1
3 0 0 3525 18 270 0 0 0 0 33312 41332 50
18 31 0 1
2 0 0 3525 18 270 0 0 0 12 31582 38786 48
18 34 0 1
4 0 0 3525 18 270 0 0 0 0 33237 40898 49
19 31 0 1
2 0 0 3525 18 270 0 0 0 0 33156 40825 48
18 33 0 1
6 0 0 3525 18 270 0 0 0 0 33395 40956 50
17 32 0 1
5 0 0 3525 18 270 0 0 0 6 31706 38739 53
16 30 0 1
1 0 0 3525 18 270 0 0 0 0 19777 24406 29
10 61 0 0
1 0 0 3525 18 270 0 0 0 0 735 1088 0
0 100 0 0
1 0 0 3525 18 270 0 0 0 8 721 1084 0
0 100 0 0
1 0 0 3525 18 270 0 0 0 0 730 1089 0
0 100 0 0
[t-hashi@gtp206 ~]$ vmstat -S m 2
procs -----------memory---------- ---swap-- -----io---- --system--
-----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 3533 17 263 0 0 18 9 228 373 1 0 99 0 0
0 0 0 3533 17 263 0 0 0 0 2912 4254 1 1 98 0 0
3 0 0 3533 17 263 0 0 0 0 6042 8320 1 2 97 0 0
3 0 0 3533 17 263 0 0 0 12 5241 7352 1 2 97 0 0
5 0 0 3533 17 263 0 0 0 0 5564 7788 2 2 96 0 0
3 0 0 3533 17 263 0 0 0 0 5565 7708 1 2 97 0 0
3 0 0 3533 17 263 0 0 0 0 5427 7618 1 2 97 0 0
3 0 0 3533 17 263 0 0 0 0 5286 7386 1 2 97 0 0
3 0 0 3533 17 263 0 0 0 40 5532 7714 1 2 97 0 0
3 0 0 3533 17 263 0 0 0 0 5391 7587 1 2 96 0 0
3 0 0 3533 17 263 0 0 0 72 4742 6587 0 2 98 0 0
3 0 0 3533 17 263 0 0 0 0 5353 7485 2 2 96 0 0
3 0 0 3533 17 263 0 0 0 0 5450 7573 1 2 97 0 0
5 0 0 3533 17 263 0 0 0 4 5502 7693 1 2 96 0 0
3 0 0 3533 17 263 0 0 0 0 5385 7528 1 2 97 0 0
3 0 0 3533 17 263 0 0 0 6 5459 7575 1 2 97 0 0
3 0 0 3533 17 263 0 0 0 0 5385 7612 1 2 96 0 0
5 0 0 3533 17 263 0 0 0 0 5657 7738 1 2 97 0 0
5 0 0 3533 17 263 0 0 0 0 5559 7671 1 2 96 0 0
5 0 0 3533 17 263 0 0 0 0 5584 7745 1 2 97 0 0
5 0 0 3533 17 263 0 0 0 0 5560 7723 2 2 97 0 0
7 0 0 3533 17 263 0 0 0 0 5363 7408 1 1 98 0 0
3 0 0 3533 17 263 0 0 0 0 4960 6685 1 2 97 0 0
3 0 0 3533 17 263 0 0 0 8 490 847 0
0 100 0 0
3 0 0 3533 17 263 0 0 0 0 502 907 0
0 100 0 0
3 0 0 3533 17 263 0 0 0 0 500 846 0
0 100 0 0
[t-hashi@gtp301 ~]$ ./mcb -c get -a 172.20.31.205 -p 11211 -t 50 -n
2000 -l 1024 -s -m 10000
condition =>
memcached = 172.20.31.205:11211
command = get
50 thread run
send 2000 command a thread, total 100000 command
data length = 1024
result =>
interval = 43.806301 [sec]
performance = 2282.776620 [command/sec]
thread info:
ave. = 42.160808[sec], min = 40.160611[sec], max = 43.804653[sec]
[t-hashi@gtp205 ~]$ vmstat -S m -n 2
procs -----------memory---------- ---swap-- -----io---- --system--
-----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
5 0 0 3526 18 270 0 0 13 7 122 234 0
0 100 0 0
3 0 0 3526 18 270 0 0 0 0 31016 38199 49
15 35 0 1
5 0 0 3525 18 270 0 0 0 16 31519 38553 48
15 36 0 1
4 0 0 3525 18 270 0 0 0 2 26418 32052 48
14 37 0 1
5 0 0 3525 18 270 0 0 0 0 30790 37966 47
18 35 0 1
7 0 0 3525 18 270 0 0 0 0 32458 40062 50
20 29 0 1
7 0 0 3525 18 270 0 0 0 22 33013 40854 51
19 29 0 1
5 0 0 3525 18 270 0 0 0 0 32784 40440 51
18 31 0 1
4 0 0 3525 18 270 0 0 0 6 31287 38188 50
16 33 0 1
4 0 0 3525 18 270 0 0 0 0 32566 40348 49
18 32 0 1
5 0 0 3525 18 270 0 0 0 0 32992 40846 51
16 33 0 1
5 0 0 3525 18 270 0 0 0 0 32861 40580 50
18 32 0 1
5 0 0 3525 18 270 0 0 0 0 32189 39737 46
19 34 0 1
5 0 0 3525 18 270 0 0 0 4 32994 40807 49
19 32 0 1
3 0 0 3525 18 270 0 0 0 0 33136 40862 50
17 33 0 1
3 0 0 3525 18 270 0 0 0 0 33312 41332 50
18 31 0 1
2 0 0 3525 18 270 0 0 0 12 31582 38786 48
18 34 0 1
4 0 0 3525 18 270 0 0 0 0 33237 40898 49
19 31 0 1
2 0 0 3525 18 270 0 0 0 0 33156 40825 48
18 33 0 1
6 0 0 3525 18 270 0 0 0 0 33395 40956 50
17 32 0 1
5 0 0 3525 18 270 0 0 0 6 31706 38739 53
16 30 0 1
1 0 0 3525 18 270 0 0 0 0 19777 24406 29
10 61 0 0
1 0 0 3525 18 270 0 0 0 0 735 1088 0
0 100 0 0
1 0 0 3525 18 270 0 0 0 8 721 1084 0
0 100 0 0
1 0 0 3525 18 270 0 0 0 0 730 1089 0
0 100 0 0
[t-hashi@gtp206 ~]$ vmstat -S m 2
procs -----------memory---------- ---swap-- -----io---- --system--
-----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 3533 17 263 0 0 18 9 228 373 1 0 99 0 0
0 0 0 3533 17 263 0 0 0 0 2912 4254 1 1 98 0 0
3 0 0 3533 17 263 0 0 0 0 6042 8320 1 2 97 0 0
3 0 0 3533 17 263 0 0 0 12 5241 7352 1 2 97 0 0
5 0 0 3533 17 263 0 0 0 0 5564 7788 2 2 96 0 0
3 0 0 3533 17 263 0 0 0 0 5565 7708 1 2 97 0 0
3 0 0 3533 17 263 0 0 0 0 5427 7618 1 2 97 0 0
3 0 0 3533 17 263 0 0 0 0 5286 7386 1 2 97 0 0
3 0 0 3533 17 263 0 0 0 40 5532 7714 1 2 97 0 0
3 0 0 3533 17 263 0 0 0 0 5391 7587 1 2 96 0 0
3 0 0 3533 17 263 0 0 0 72 4742 6587 0 2 98 0 0
3 0 0 3533 17 263 0 0 0 0 5353 7485 2 2 96 0 0
3 0 0 3533 17 263 0 0 0 0 5450 7573 1 2 97 0 0
5 0 0 3533 17 263 0 0 0 4 5502 7693 1 2 96 0 0
3 0 0 3533 17 263 0 0 0 0 5385 7528 1 2 97 0 0
3 0 0 3533 17 263 0 0 0 6 5459 7575 1 2 97 0 0
3 0 0 3533 17 263 0 0 0 0 5385 7612 1 2 96 0 0
5 0 0 3533 17 263 0 0 0 0 5657 7738 1 2 97 0 0
5 0 0 3533 17 263 0 0 0 0 5559 7671 1 2 96 0 0
5 0 0 3533 17 263 0 0 0 0 5584 7745 1 2 97 0 0
5 0 0 3533 17 263 0 0 0 0 5560 7723 2 2 97 0 0
7 0 0 3533 17 263 0 0 0 0 5363 7408 1 1 98 0 0
3 0 0 3533 17 263 0 0 0 0 4960 6685 1 2 97 0 0
3 0 0 3533 17 263 0 0 0 8 490 847 0
0 100 0 0
3 0 0 3533 17 263 0 0 0 0 502 907 0
0 100 0 0
3 0 0 3533 17 263 0 0 0 0 500 846 0
0 100 0 0
---
Tomoya Hashimoto
2008/11/18 9:04 Takeru INOUE <tak...@gm...>:
> ets のスループットはもう少し上がりそうな気もします．
>
> 差し支えなければ，PC のスペックはどのくらいか教えていただけますでしょうか．
> あと，CPU 使用率と，ネットワークの状況 (Gbit?) はどうでしたでしょうか．
>
>
> 2008/11/17 Tomoya Hashimoto <tom...@gm...>:
>> 橋本です。
>>
>> 早速Rev 99で同様に試してみました。こちらではエラーが発生しなくなりました。大体以下のような
>> 数字が得られました。detsはetsの1/3ぐらい、という結果でした。
>>
>> ■ ets
>>
>> [t-hashi@gtp301 ~]$ ./mcb -c set -a 172.20.31.207 -p 11211 -t 200 -n
>> 100 -l 1024 -s -m 10000
>> condition =>
>> memcached = 172.20.31.207:11211
>> command = set
>> 200 thread run
>> send 100 command a thread, total 20000 command
>> data length = 1024
>> result =>
>> interval = 12.847524 [sec]
>> performance = 1556.720199 [command/sec]
>> thread info:
>> ave. = 10.303019[sec], min = 2.445050[sec], max = 12.843495[sec]
>>
>> ■ dets
>>
>> [t-hashi@gtp301 ~]$ ./mcb -c set -a 172.20.31.205 -p 11211 -t 200 -n
>> 100 -l 1024 -s -m 10000
>> condition =>
>> memcached = 172.20.31.205:11211
>> command = set
>> 200 thread run
>> send 100 command a thread, total 20000 command
>> data length = 1024
>> result =>
>> interval = 38.860149 [sec]
>> performance = 514.666064 [command/sec]
>> thread info:
>> ave. = 35.751326[sec], min = 19.174975[sec], max = 38.857620[sec]
>> [t-hashi@gtp301 ~]$
>>
>> ＃今度のErlang勉強会にお邪魔するのでご挨拶させてください
>>
>> ---
>> Tomoya Hashimoto
>>
>> 2008/11/17 17:34 shinohara <shi...@gm...>:
>>> しのはら(shino)です。
>>> # kai-users-ja にもクロスポストしてみます。
>>>
>>> On 11/17/08 1:28 PM Tomoya Hashimoto wrote:
>>>> 使い方がまずいのかもしれませんが、私の手元ではエラーが出ているので報告させていただきます。
>>>>
>>>> こちらのツールを使ってベンチマークを取っています。
>>>> http://www.interdb.jp/techinfo/mcb/
>>>
>>> エラー報告 & 便利なツールありがとうございます :-)
>>>
>>>> 初めの一回ぐらいはうまくいくのですが、リクエストするホストを変えたりして2,3回ほど試すとKaiがエラーを出力しています。
>>>>
>>>> 7>
>>>> =ERROR REPORT==== 17-Nov-2008::13:08:21 ===
>>>> Error in process <0.2140.0> with exit value: {{badmatch,{error,"stale
>>>> state"}},[{kai_coordinator,coordinate_put,1},{kai_coordinator,start_route,3}]}
>>>
>>> バグでした。branch で修正しましたので、確認してもらえるとありがたいです。
>>> - vector clocks の更新で、過去データを元にノードのカウンターをインクレメントするようにした
>>> - 古い状態(stale state)かどうかの判断は、cas unique が渡ってくる cas でしか出来無い(と思う)
>>> ので、判断ロジックを削除
>>>
>>> URL: https://kai.svn.sourceforge.net/svnroot/kai/branches/shino_vector_clocks
>>> Revision: 99
>>> Last Changed Author: shino_shun
>>> Last Changed Rev: 99
>>> Last Changed Date: 2008-11-17 16:52:10 +0900 (Mon, 17 Nov 2008)
>>>
>>> よろしくおねがいします m(_ _)m
>>>
>>> shino
>>>
>>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Kai-users-ja mailing list
>> Kai...@li...
>> https://lists.sourceforge.net/lists/listinfo/kai-users-ja
>>
>
>
>
> --
> Takeru INOUE <tak...@gm...>
>
|
|
From: Takeru I. <tak...@gm...> - 2008-11-18 00:04:19
|
ets のスループットはもう少し上がりそうな気もします． 差し支えなければ，PC のスペックはどのくらいか教えていただけますでしょうか． あと，CPU 使用率と，ネットワークの状況 (Gbit?) はどうでしたでしょうか． 2008/11/17 Tomoya Hashimoto <tom...@gm...>: > 橋本です。 > > 早速Rev 99で同様に試してみました。こちらではエラーが発生しなくなりました。大体以下のような > 数字が得られました。detsはetsの1/3ぐらい、という結果でした。 > > ■ ets > > [t-hashi@gtp301 ~]$ ./mcb -c set -a 172.20.31.207 -p 11211 -t 200 -n > 100 -l 1024 -s -m 10000 > condition => > memcached = 172.20.31.207:11211 > command = set > 200 thread run > send 100 command a thread, total 20000 command > data length = 1024 > result => > interval = 12.847524 [sec] > performance = 1556.720199 [command/sec] > thread info: > ave. = 10.303019[sec], min = 2.445050[sec], max = 12.843495[sec] > > ■ dets > > [t-hashi@gtp301 ~]$ ./mcb -c set -a 172.20.31.205 -p 11211 -t 200 -n > 100 -l 1024 -s -m 10000 > condition => > memcached = 172.20.31.205:11211 > command = set > 200 thread run > send 100 command a thread, total 20000 command > data length = 1024 > result => > interval = 38.860149 [sec] > performance = 514.666064 [command/sec] > thread info: > ave. = 35.751326[sec], min = 19.174975[sec], max = 38.857620[sec] > [t-hashi@gtp301 ~]$ > > ＃今度のErlang勉強会にお邪魔するのでご挨拶させてください > > --- > Tomoya Hashimoto > > 2008/11/17 17:34 shinohara <shi...@gm...>: >> しのはら(shino)です。 >> # kai-users-ja にもクロスポストしてみます。 >> >> On 11/17/08 1:28 PM Tomoya Hashimoto wrote: >>> 使い方がまずいのかもしれませんが、私の手元ではエラーが出ているので報告させていただきます。 >>> >>> こちらのツールを使ってベンチマークを取っています。 >>> http://www.interdb.jp/techinfo/mcb/ >> >> エラー報告 & 便利なツールありがとうございます :-) >> >>> 初めの一回ぐらいはうまくいくのですが、リクエストするホストを変えたりして2,3回ほど試すとKaiがエラーを出力しています。 >>> >>> 7> >>> =ERROR REPORT==== 17-Nov-2008::13:08:21 === >>> Error in process <0.2140.0> with exit value: {{badmatch,{error,"stale >>> state"}},[{kai_coordinator,coordinate_put,1},{kai_coordinator,start_route,3}]} >> >> バグでした。branch で修正しましたので、確認してもらえるとありがたいです。 >> - vector clocks の更新で、過去データを元にノードのカウンターをインクレメントするようにした >> - 古い状態(stale state)かどうかの判断は、cas unique が渡ってくる cas でしか出来無い(と思う) >> ので、判断ロジックを削除 >> >> URL: https://kai.svn.sourceforge.net/svnroot/kai/branches/shino_vector_clocks >> Revision: 99 >> Last Changed Author: shino_shun >> Last Changed Rev: 99 >> Last Changed Date: 2008-11-17 16:52:10 +0900 (Mon, 17 Nov 2008) >> >> よろしくおねがいします m(_ _)m >> >> shino >> >> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > 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...> - 2008-11-17 09:38:15
|
橋本です。
早速Rev 99で同様に試してみました。こちらではエラーが発生しなくなりました。大体以下のような
数字が得られました。detsはetsの1/3ぐらい、という結果でした。
■ ets
[t-hashi@gtp301 ~]$ ./mcb -c set -a 172.20.31.207 -p 11211 -t 200 -n
100 -l 1024 -s -m 10000
condition =>
memcached = 172.20.31.207:11211
command = set
200 thread run
send 100 command a thread, total 20000 command
data length = 1024
result =>
interval = 12.847524 [sec]
performance = 1556.720199 [command/sec]
thread info:
ave. = 10.303019[sec], min = 2.445050[sec], max = 12.843495[sec]
■ dets
[t-hashi@gtp301 ~]$ ./mcb -c set -a 172.20.31.205 -p 11211 -t 200 -n
100 -l 1024 -s -m 10000
condition =>
memcached = 172.20.31.205:11211
command = set
200 thread run
send 100 command a thread, total 20000 command
data length = 1024
result =>
interval = 38.860149 [sec]
performance = 514.666064 [command/sec]
thread info:
ave. = 35.751326[sec], min = 19.174975[sec], max = 38.857620[sec]
[t-hashi@gtp301 ~]$
＃今度のErlang勉強会にお邪魔するのでご挨拶させてください
---
Tomoya Hashimoto
2008/11/17 17:34 shinohara <shi...@gm...>:
> しのはら(shino)です。
> # kai-users-ja にもクロスポストしてみます。
>
> On 11/17/08 1:28 PM Tomoya Hashimoto wrote:
>> 使い方がまずいのかもしれませんが、私の手元ではエラーが出ているので報告させていただきます。
>>
>> こちらのツールを使ってベンチマークを取っています。
>> http://www.interdb.jp/techinfo/mcb/
>
> エラー報告 & 便利なツールありがとうございます :-)
>
>> 初めの一回ぐらいはうまくいくのですが、リクエストするホストを変えたりして2,3回ほど試すとKaiがエラーを出力しています。
>>
>> 7>
>> =ERROR REPORT==== 17-Nov-2008::13:08:21 ===
>> Error in process <0.2140.0> with exit value: {{badmatch,{error,"stale
>> state"}},[{kai_coordinator,coordinate_put,1},{kai_coordinator,start_route,3}]}
>
> バグでした。branch で修正しましたので、確認してもらえるとありがたいです。
> - vector clocks の更新で、過去データを元にノードのカウンターをインクレメントするようにした
> - 古い状態(stale state)かどうかの判断は、cas unique が渡ってくる cas でしか出来無い(と思う)
> ので、判断ロジックを削除
>
> URL: https://kai.svn.sourceforge.net/svnroot/kai/branches/shino_vector_clocks
> Revision: 99
> Last Changed Author: shino_shun
> Last Changed Rev: 99
> Last Changed Date: 2008-11-17 16:52:10 +0900 (Mon, 17 Nov 2008)
>
> よろしくおねがいします m(_ _)m
>
> shino
>
>
|
|
From: shinohara <shi...@gm...> - 2008-11-17 08:56:08
|
しのはら(shino)です。 # kai-users-ja にもクロスポストしてみます。 On 11/17/08 1:28 PM Tomoya Hashimoto wrote: > 使い方がまずいのかもしれませんが、私の手元ではエラーが出ているので報告させていただきます。 > > こちらのツールを使ってベンチマークを取っています。 > http://www.interdb.jp/techinfo/mcb/ エラー報告 & 便利なツールありがとうございます :-) > 初めの一回ぐらいはうまくいくのですが、リクエストするホストを変えたりして2,3回ほど試すとKaiがエラーを出力しています。 > > 7> > =ERROR REPORT==== 17-Nov-2008::13:08:21 === > Error in process <0.2140.0> with exit value: {{badmatch,{error,"stale > state"}},[{kai_coordinator,coordinate_put,1},{kai_coordinator,start_route,3}]} バグでした。branch で修正しましたので、確認してもらえるとありがたいです。 - vector clocks の更新で、過去データを元にノードのカウンターをインクレメントするようにした - 古い状態(stale state)かどうかの判断は、cas unique が渡ってくる cas でしか出来無い(と思う) ので、判断ロジックを削除 URL: https://kai.svn.sourceforge.net/svnroot/kai/branches/shino_vector_clocks Revision: 99 Last Changed Author: shino_shun Last Changed Rev: 99 Last Changed Date: 2008-11-17 16:52:10 +0900 (Mon, 17 Nov 2008) よろしくおねがいします m(_ _)m shino |
|
From: Kunihiko T. <kun...@gm...> - 2008-06-17 16:17:45
|
-- TAKAHASHI Kunihiko |
3 messages has been excluded from this view by a project administrator.
