シンプルなトラフィック負荷テストの実行

lfm 2010年7月25日 04:02 UTC 原文 ·

IRC チャンネルでスケーラビリティやスパムトランザクションによるサービス拒否攻撃について憶測が飛び交っていたので、テストを行うのが良いと思いました。

私の Linux マシン 2 台に簡単な bitcoind スクリプトを設定し、3 台目のマシンに対してできるだけ速く 1000件の少額トランザクションを送信しました。

IRC で実行すべきでない明確な理由があるか尋ねたところ、良いアイデアだという賛成意見が 1 つと、まずここで聞くべきだという慎重な意見が 1 つありました。私は思い切って実行することにしました。

スクリプトはループの残りステップ数のカウントダウンと、bitcoind の sendtoaddress コマンドの出力(通常は単に「sent」)を表示するだけのものでした。

両方とも最初は速く動いていましたが、約 600件のトランザクションが送信された頃から、両方の送信側が目に見えて遅くなり始めました。一方がもう一方より 3〜4倍速かったのですが、これは CPU が速いためだと思います。最初はネットワークの過負荷を防ぐためにクライアントがスロットリングしているのかと思いましたが、それは単なる推測でした。後で、古いディスク上のデータベースが少し遅くなっているのではないかという結論に至りました。

その後、一方のマシンが突然速くなったように見えました。しかし実際にはそうではありませんでした。エラーが発生しており、bitcoind デーモンが停止していたのです。調査したところ、.bitcoin のドライブが満杯になっていたことが判明したので、プログラムが停止したのは仕方ありません。

もう一方のマシンはその頃にはかなり遅くなっており、目視で 1 トランザクションあたり約 5秒程度でした。最終的に約 50分後にエラーなく完了しました。

クラッシュしたマシンはディスク容量を追加した後すぐに再起動し、424件のトランザクションしか送信していなかったことが判明しました。つまり、最初のベンチマークとして 50分間で 1424件のトランザクションということになります。さらに多くの処理は容易に可能でしょう。

速度低下の主な原因は.bitcoin/database ディレクトリだったと思います。ディスク容量が不足したマシンでは約 184MB、1000件のトランザクションを完了したマシンでは 1341MB のデータが書き込まれていました。

より多くの人がネットワーク上に分散して参加する別のテストを行い、潜在的な問題を洗い出す価値があるかもしれません。

ネットワークは何事もなかったかのように処理したので、これは肯定的な結果です。クライアントは概ね指示通り期待通りに動作しましたが、データベースにパフォーマンスの問題がある可能性があります。

今思いつくのは以上です。

lfm 2010年7月25日 13:09 UTC 原文 ·

テスト中ずっと IRC を動かして進捗を議論できていたので、ネットワークリソースを飽和させるところまで行っていなかったと思う。

theymos 2010年7月25日 13:13 UTC 原文 ·

テストの後半でトランザクションの速度がかなり低下した。これがネットワークの問題だとすれば、将来のサービス拒否攻撃について非常に心配だ。後でもっと大規模なテストを組織できると良い。

興味がある人向けに、このイベントのパケットキャプチャ(接続が 1 つだけの「エッジ」コンピューターから)を置いておく。 http://www.freefilehostingnow.com/filedownload.aspx?code=6bb2dbeea18e6a419daaadda5798bb05ec6b

テストネットワークで行いましたか? http://bitcointalk.org/index.php?topic=363.0

theymos 2010年7月25日 15:00 UTC 原文 ·
サトシ・ナカモトの投稿(2010年7月25日 05:46 UTC)

テストネットワークで行いましたか? http://bitcointalk.org/index.php?topic=363.0

いいえ。

テストネットワークでこれらのテストを行ってくれ。それがテストネットワークの目的だ。ありがとう。

theymos 2010年7月25日 16:05 UTC 原文 ·
サトシ・ナカモトの投稿(2010年7月25日 15:29 UTC)

テストネットワークでこれらのテストを行ってくれ。それがテストネットワークの目的だ。ありがとう。

そんなに小さなネットワークからは現実のデータは得られない。それに、信頼できるネットワークなら、どんな種類のテストにも耐えられなければならない。

なら、せめて先にテストネットワークでやってくれ!

もしテストネットワークを壊せたなら、本番ネットワークも壊せる見込みは十分ある。もしテストネットワークが壊れなかったら、そのときは本番ネットワークに対して走らせて「スケールアップ」の問題を探してくれていい。

FreeMoney 2010年7月25日 20:01 UTC 原文 ·
ギャビン・アンドレセンの投稿(2010年7月25日 16:14 UTC)

なら、せめて先にテストネットワークでやってくれ!

もしテストネットワークを壊せたなら、本番ネットワークも壊せる見込みは十分ある。もしテストネットワークが壊れなかったら、そのときは本番ネットワークに対して走らせて「スケールアップ」の問題を探してくれていい。

本当か?本物の方がずっと頑健だと思いたい/願いたいんだが。違うのか?

lfm 2010年7月25日 20:25 UTC 原文 ·
サトシ・ナカモトの投稿(2010年7月25日 15:29 UTC)

テストネットワークでこれらのテストを行ってくれ。それがテストネットワークの目的だ。ありがとう。

すまない、テストネットワークの存在自体を知らなかった。私のミスだ。

テストネットワーク向けに、もっと大規模なテストを企画できないか?同時にもっと多くの人で。

aceat64 2010年7月25日 21:31 UTC 原文 ·
lfmの投稿(2010年7月25日 20:25 UTC)
サトシ・ナカモトの投稿(2010年7月25日 15:29 UTC)

こうしたテストはテストネットワークでやってほしい。そのためにあるんだ。よろしく。

すまない、テストネットワークの存在自体を知らなかった。私のミスだ。

テストネットワーク向けに、もっと大規模なテストを企画できないか?同時にもっと多くの人で。

テストの長さを比較的短く保つなら、テストネットワークに EC2 インスタンスを数台投入して協力するのは構わない。