共有メモリクラスタとかファイルシステムとか?

コンパイルを速くしたいと複数台の共有メモリをつなげて見せるクラスタ ファイルシステムってどうなんだろうなどというお話
3
イーロン・マスクツイッターやめろ @naota344

メモリにのることが(極力)保証されるのを狙ったネットワークファイルシステムってありますっけ?

2010-11-12 06:39:33
イーロン・マスクツイッターやめろ @naota344

なにがしたいかというと複数のマシンのshmを集めて一つのネットワークファイルシステムに見せたい感じ key/value db で実現できるか?

2010-11-12 06:43:59
E_Rubik @E_Rubik

@naota344 よくわからんが、分散共有メモリ的なもの?

2010-11-12 06:44:52
イーロン・マスクツイッターやめろ @naota344

あと shm ってか tmpfs はフラグメンテーションしないってほんとなんかしら。まぁ無視できる感じはあるけど

2010-11-12 06:49:20
かおりん@ @kaorin_linux

@naota344 発生してもアクセス速度には問題ないってことじゃね?

2010-11-12 06:49:56
イーロン・マスクツイッターやめろ @naota344

@kaorin_linux まぁ多分そうですよね。この前読んだのに、tmofsは本来的な意味でのファイルシステムでなく、フラグメンテーションはありえないとかあってんん?となりまして

2010-11-12 06:53:33
SODA Noriyuki @n_soda

@naota344 tmpfsって意味じゃないんですよね?(ぉ メモリに残るかどうかはファイルシステムじゃなくて、VMの判断におまかせってのが普通じゃないかな?AFSとかは積極的にローカルキャッシュ(ファイル)に残すので、一貫性のセマンティクスまで緩めていた覚えが。

2010-11-12 09:04:23
イーロン・マスクツイッターやめろ @naota344

@n_soda tmpfs だと一台だけですよね。それをさらにホスト間で共有するような感じです。

2010-11-12 12:06:59
SODA Noriyuki @n_soda

@naota344 tmpfsをNFS exportしておくとか(揮発性だし、できないOSもありそうですが)。tmpfsを使わない普通のNFSサーバでも、サーバ側に空きメモリが十分にあれば、カーネルが勝手にキャッシュしてくれますが、それではまずいのはどのあたりでしょう?

2010-11-12 13:36:53
イーロン・マスクツイッターやめろ @naota344

@n_soda あ、いやネットワークというかクラスタ?ですかね。参加してる全てのマシンのtmpfsを一個につないで見せたいんです

2010-11-12 14:15:58
SODA Noriyuki @n_soda

@naota344 クラスターファイルシステムですか。メモリに載ってるってのをもし仮に要件から外して良ければ、Lustreとか @syuu1228 先生が今戦っているCephですかねえ。FUSEベースで良ければ選択肢はもっと増えますが…

2010-11-12 14:21:59
イスラエルエリカちゃん @syuu1228

@n_soda @naota344 Cephのストレージ部分をRAMに乗るようにしてやればよいかも。取り敢えずtmpfs+loopback+btrfsで付け焼刃的に実現出来るけど、もっとちゃんと作りこんでもいいかもね?

2010-11-12 14:28:06
イーロン・マスクツイッターやめろ @naota344

@n_soda もともとの狙いがコンパイル速くしたい、なんですよ。一台のtmpfsだとメモリ足りなくなったらswapですけど、その前に他ホストのメモリ使えたらいいな、と。それでもだめならswap ⇒他ホストにswapとして可能な限り持ってるマシンのメモリを活用したくって…

2010-11-12 14:30:19
SODA Noriyuki @n_soda

@naota344 それって、ファイルシステムがボトルネックなんでしょうか? NetBSDのフルビルドくらいだと、vmstatで見てても「b」欄がほぼ常に0で、完全にCPUネックって感じでした。OpenOfficeとかKDEとかChromeのビルドだと話は別かな?

2010-11-12 14:34:10
イスラエルエリカちゃん @syuu1228

@naota344 @n_soda コンパイルみたいに細切れで量の多いIOってネットワークFSだとすんげぇ遅そうな予感がするのですが気のせいだろうか

2010-11-12 14:35:15
SODA Noriyuki @n_soda

@syuu1228 ハードディスクよりはネットワークの方が2桁くらいレイテンシが短いので、本当にディスクネックで、かつローカルにもアグレッシブにキャッシュするファイルシステムなら大丈夫でしょう。でもディスクネックかどうかが非常に怪しいような。

2010-11-12 14:38:52
イーロン・マスクツイッターやめろ @naota344

@syuu1228 @n_soda DB の本読んでて、 keyvalue DB は HDDよりかはLAN内のメモリのほうがはやくなるからメリットがあるーみたいな記述を見てこれをFSにできたらと思ったのですが、遅くなりますかね。

2010-11-12 14:40:33
イーロン・マスクツイッターやめろ @naota344

@n_soda make -j だったりパッケージ単位のコンパイル自体を並列で走らせてたりするので…。 最初の unpack の時間もなかなか…

2010-11-12 14:38:32
SODA Noriyuki @n_soda

@naota344 unpack みたいなのは、LFS や NiLFSみたいな、log structured filesystem 使うと馬鹿っぱやになります。

2010-11-12 14:45:50
イーロン・マスクツイッターやめろ @naota344

@n_soda あー、速くというかより厳密には IO かかるとデスクトップの反応悪くなるので…。あと netbook SSD上の ZFS で emacs ビルドするとファイルシステムが遅いと思わしき*ものすごい*遅さになっていたりして...

2010-11-12 14:37:06
SODA Noriyuki @n_soda

@naota344 スケジューラや、ディスクのキューイングポリシーを変えてみる、SSDについては、SSD向けファイルシステムに変えてみるって方が… OSは Linux?

2010-11-12 14:44:36
SODA Noriyuki @n_soda

@naota344 並列makeすると、ディスク待ちの時間は、別のコンパイル処理にCPUを回せるので、CPUはほぼ100%埋まります。このため、CPUネックになります。ディスクネックにはなりません。

2010-11-12 14:48:52
イーロン・マスクツイッターやめろ @naota344

さらに言えばそれぞれのマシンで見えるものが違っていいし違ってほしい。そして自分のファイルがなるべく「近く」に配置されるような感じ

2010-11-12 14:49:09