kernel.orgミラー管理者曰く「BitTorrentは負荷分散に役立っていない」 32
ストーリー by mhatta
思わぬ弱点 部門より
思わぬ弱点 部門より
先週開催されたOttawa Linux Symposium 2008の総括記事(OTP)で、kernel.orgのミラー管理者、John Hawley氏の講演が紹介されています(記事の4ページ目)。Hawley氏によると、ユーザーはBitTorrentで負荷が分散されていると思い込んでいるものの、トラッカーとなるミラーサーバへの負荷が大きいため、実際は負荷分散になっていないそうです。Hawley氏が例として挙げたのはFedora 8リリース後1週間のデータで、kernel.orgのミラーだけをソースとしたBitTorrent経由のダウンロード数が、あらゆるソースを利用したBitTorrent経由のダウンロード数とほぼ同じくらい存在し、Fedora 8全ダウンロードデータの約25%はkernel.orgミラーをソースとするものだったそうです。しかも、BitTorrentを使うとサーバはチャンクごとにディスクをシークするためディスクスラッシングを引き起こしやすく、HTTP経由のダウンロードに比べて400倍もの負荷をディスクにかけるとのこと。P2Pによるディストリビューション配布の必要性は認めるHawley氏ですが、「BitTorrentはその解答ではない」と結論づけています。
このほかにも、Hawley氏は「FedoraやMandrivaは大量のアーカイブをミラーに放置するのをやめろ(超意訳)」とか「リリースタイミングが重ならないようディストリビューター間で調整しろ」とか不満をぶちまけているので興味のある方は元記事をどうぞ。
日本のよいこみんなはRing Serverのミラーを使おう! (スコア:2, 参考になる)
ってことでしょうか。
http://www.t.ring.gr.jp/pub/linux/ ←近いサーバー優先
http://www.dnsbalance.ring.gr.jp/pub/linux/ ←空いているサーバー優先
とりあえずFerdoraはあるみたい。
love && peace && free_software
t-nissie
Re:日本のよいこみんなはRing Serverのミラーを使おう! (スコア:2, 興味深い)
アップデート先として使われなくなったのには理由があんだよRingServer
Re: (スコア:0)
Re:日本のよいこみんなはRing Serverのミラーを使おう! (スコア:1)
あやむらさんが亡くなられて以後アーカイブの手入れが非常に悪くなった。
ある種GNUとISCのミラーとしてしか役に立ってない。
あとTENBINが動いてない。
動かすなり記述から外すなりしてほしい>関係者
Re: (スコア:0)
Re:日本のよいこみんなはRing Serverのミラーを使おう! (スコア:1)
http://ring.riken.jp/pub/linux/fedora/linux/releases/9/Fedora/
からダウンロードしようとしたらなかった。
Ring Serverはもはやイケてないのだろうか。
ディスクスペースが足りないのだろうか。
Ring Serverの管理をやっても世間や研究所内や学内で評価されないのがいけないのだろうか。
ぼくはGNUのソースをいつもダウンロードしているので助かっている。
http://ftp.riken.jp/Linux/fedora/releases/9/Fedora/
にはあったので、ダウンロード中。
30分後にSHA1のチェックをする予定。
love && peace && free_software
t-nissie
Re:日本のよいこみんなはRing Serverのミラーを使おう! (スコア:3, 興味深い)
……と思ったら、最近はもはやそういった研究機関しかRing Serverに参加していないんですね。一時期は20くらいのミラーがあったような気がするんですが。ライブドアのデータホテルのRing Serverは速くて安定していてよく使っていたんですが。
全局録画。草野さん、小倉さんもやってるぞ: ホットコーナーの舞台裏 [asablo.jp]より
Your 金銭的 potential. Our passion - Micro$oft
Tsukitomo(月友)
Re:日本のよいこみんなはRing Serverのミラーを使おう! (スコア:2, おもしろおかしい)
love && peace && free_software
t-nissie
Re:日本のよいこみんなはRing Serverのミラーを使おう! (スコア:1)
$ sha1sum -c SHA1SUM
Fedora-9-ppc-DVD.iso: 失敗
(途中略)
Fedora-9-ppc-netinst.iso: 完了
$ ls -l Fed*
-rw-r--r-- 1 t-nissie t-nissie 4417064960 2008-08-03 11:34 Fedora-9-ppc-DVD.iso
-rw-r--r-- 1 t-nissie t-nissie 185217024 2008-08-03 11:47 Fedora-9-ppc-netinst.iso
</ecode>
小さなファイルは大丈夫だった。
どっかで32ビット−4GBに関連した不具合があるのかしら。
ネットワーク?カーネル?ファイルシステム?sha1sumコマンド?
love && peace && free_software
t-nissie
Re: (スコア:0)
大きいサイズのファイルを落とすことがあまりないせいか気がつかないんですよね
Re: (スコア:0)
半分になるんだから御の字 (スコア:2, 興味深い)
すなわち見かけの帯域が倍になるんだから御の字だろう?
オープンソースものではない全世界に向けたオンライン配信コンテンツの配信周りに
ちょっとだけ首を突っ込んでいるけれど
経験的に公開後48時間くらいは帯域を猛烈に使われるけどそれ以後はたいしたことはない。
スラッシングの問題に関しては、シードしているコンテンツがメモリに乗り切ってない時点で負けだ。
これはBitTorrentに限らずHTTPでも同じ、CDNを使う場合でも同じ。
「スワップさせたら負け」
帯域制限 (スコア:1)
isoファイル落とすときに,BitTorrentのトラフィックが帯域制限(by @nifty)に引っかかってしまい,泣く泣くHTTP経由でのダウンロードになってしまう.
インフラの負荷(配布元)を軽減する目的なのに,インフラの負荷(ISP)軽減の目的でこれが阻害されてしまうのは皮肉に感じる.
Re: (スコア:0)
以前使っていたときにそう思える挙動をしていたので退会したんですけど……
と思って読み返したら
>BitTorrentのトラフィックが帯域制限(by @nifty)に引っかかってしまい,泣く泣くHTTP経由でのダウンロードに
ということはプロトコル毎に帯域制限が違うってことだったのかな?
Re:帯域制限 (スコア:1)
ファイル共有ソフトの通信のみ制限がかけられ,HTTPの場合は制限を受けていないということです.
トラッカーも負荷分散が必要 (スコア:1)
たしかに、ノードの数が多いと大変だ。
Re: (スコア:0)
技術と心理 (スコア:1)
そこらへんのユーザ心理を解決しないと、P2P技術は浸透しないような気がします。
Your 金銭的 potential. Our passion - Micro$oft
Tsukitomo(月友)
そこで拡散と寸止めですよ (スコア:0)
いつまでたってもシーダに負荷がかかるのは当然だと思いますよ。
P2Pダウンロードの要諦はいかに即消しを防ぎ、あちこちに
断片を残すかが重要なんで、BTが「キャッシュ」という形で
断片を残しにくい仕様上、1日程度寸止めして拡散しきってから
流すとか、ある程度流さないとファイルに復元できないとか、
拡散成績なんかで何らかのスコアをつけて、
高スコアのリーチャに優先的に流してシーダになってもらい、
下位のリーチャに流すという形をとらないと駄目駄目です。
ミラーFTPから持ってくるよりも結果的に早ければ問題はないのです。
BTの実装の問題なので、改良すればいいじゃないですか。
Share(仮)のターボ拡散アップロードモードとか、既に
それを解決しているP2P共有ネットワークは実在しますよ。
Re:そこで拡散と寸止めですよ (スコア:1, 参考になる)
実際のところトラッカー負荷への問題はDHTネットなど色々と模索されている部分もあるので、今後改良されるかもしれません。
また、ご指摘の初期シーダーへの負荷の問題については、一部のBTクライアントに実装されているスーパーシードモードで対処されていますよ。
拡散アップロードについては、DL効率重視のBTの思想とはなかなか相容れない部分もあると思いますので、BTで採用されるかは微妙なところかもしれません。
流行が廃れると消えやすいBTですが、逆にホットな場合のDL速度には捨てがたい魅力もあるわけで。
Shareのような「ある目的」を持ったP2Pネットワークの場合は、そのネットワーク自体の存続という目的などもあるので拡散するのに意味はあるのでしょうが、それだけがP2Pの目指すところでもないでしょうし。
既存のP2Pモデルにはそれぞれメリット・デメリットがあるので、全てのP2Pモデルが同じ方向性を取らなくても、適材適所で使えばいいんじゃないでしょうかね。
Re: (スコア:0)
というインセンティブを捨てたら、
P2Pで配布する意味がなくなると思います。
Re: (スコア:0)
インセンティブとして十分有効だと思うんだけど。
それに、普通は落ち始めるのを確認したら放置するんだから、多少遅くても問題ない。
落ちてくる様子をじっと見ているわけでもなし。
Re: (スコア:0)
もしこれが真なら、わざわざ寸止めする意味はないように思える。
> 普通は落ち始めるのを確認したら放置するんだから、多少遅くても問題ない。
もしこれが真なら、わざわざ寸止めする意味はないように思える。
Re: (スコア:0)
即ち、このkernel.orgの主張同様
「P2Pによる負荷分散は必要、でも現状のbittorrentの仕組みではダメ」
ということです。
winnyとbittorrentの中間が必要ってことかなあ。
Re: (スコア:0)
うちは仮想環境でscrap and buildを繰り返す関係上、一度DVD ISOをダウンロードして、イメージをそのままマウントして使ってるけど、対外線の帯域がショボいのでBitTrrentを上げっぱなしにはしてない。
しかし、CentOSではISOイメージのダウンロードはBitTrrent推奨なのに、BitTrrentのRPMが無い [blogspot.com]のはどういうことなんだ?
文章が意味不明なのですが。 (スコア:0)
どなたか、この1文を分かりやすく教えてください。。。
「旬」過ぎれば... (スコア:2, 参考になる)
kernel.orgのそれのようなサーバーが、ダウンロード元がなくならないように(リスト上はクライアントに混じって)存在しています。そうしたらそのサーバーがダウンロード元になった割合が25%になっちゃったよってこと。
旬が過ぎたものをtorrentで落とすのは、かなり遅くてやってられない。
なおopenSUSEの開発版においては、リリース版より旬が短くてクライアント数もシビアです(フルのDVDisoはtorrentでしか手に入らない)。なので「前版isoに、http/ftpで落とした差分あてて、torrentクライアントの裏にチョメチョメして100%ダウンロードしたことにして、他の人のダウンロードを助ける」ことが推奨されてたりします。
Re: (スコア:0)
「BitTorrentのダウンロードのうち、分散されてダウンロードされているのは半分だけで、
半分はkernel.orgのミラーだけからダウンロードされている。」
「Fedora 8の全ダウンロードの25%はkernel.orgのミラーからのダウンロードである。」
「そのためBitTorrentの分散化という効果はあまり出ていない。」
ってな感じですか?
Re: (スコア:0)
だがkernel.orgの管理者はBitTorrentには負荷軽減効果なんてないと信じているので、kernel.orgの帯域を2倍に拡張する計画である。
ということですか?わかりません><
二律背反 (スコア:0)
一方でリリースサイクルを合わせろ [srad.jp]という主張もあったりするわけですが。いったいどうしろと…
Re: (スコア:0)
P4P (スコア:0)
http://www.geekpage.jp/blog/?id=2008/4/28/1 [geekpage.jp]
これで何とかならないの?