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

SODA Noriyuki @n_soda

@naota344 『自分のファイルがなるべく「近く」に配置されるような感じ』 Gfarmはこれやってますけどね… Cephでも、各クライアントでOSDも動かせばこうなるんでしょうか？ @syuu1228

SODA Noriyuki @n_soda

@naota344 CPUが100%埋まり、I/Oの方もコンパイルのためのトラフィックで埋まると、当然対話的レスポンスが低下します。これへの対策は、物理的なディスクを複数用意する(I/O)、ディスクI/Oのキューイングポリシー(I/O)・スケジューリングポリシー(CPU)の変更

小崎 資広 (KOSAKI Motohiro) @kosaki55tea

いまLKMLでttyごとに自動的にscheduling group分けるパッチが議論されてます。対話レスポンス全然落ちなくなる RT @n_soda: @naota344 CPUが100%埋まり、I/Oの方もコンパイルのためのトラフィックで埋まると、当然対話的レスポンスが低下しま

イーロン・マスクツイッターやめろ @naota344

ディスクネックもともかくOOoとかは6Gぐらい容量ないとコンパイルできなくて。まぁswap6G作ってから一台でtmpfsもいいけど他のマシンのメモリ使えたらなぁとか(´・ω・`)

イーロン・マスクツイッターやめろ @naota344

CPUに関しては一応ある程度分散コンパイルあるし…ってもし分散コンパイルとその共有shmをうまく組ませたらいいのかな

イーロン・マスクツイッターやめろ @naota344

うん、コンパイル速くというよりディスクIOさせたくない気持ちのほうが(ry

SODA Noriyuki @n_soda

@naota344 真の目的は、対話的レスポンスの向上じゃなくて?

イスラエルエリカちゃん @syuu1228

クライアント！＝ストレージの前提で、ハッシュ関数で公平に撒くのがデフォルトと思うんですが、分散ルールを記述可能な仕組みになってるっぽくてどこまで何ができるかちょっと把握しきれてないす。RT @n_soda: @naota344 『自分のファイルがなるべく「近く」に配置されるような

イスラエルエリカちゃん @syuu1228

いやむしろRAMにデータを載せるであるとか、積極的なローカルキャッシュであるだとか、更にノード間キャッシュ共有であるとか、って辺りを見ていこうか、と思ってたり

SODA Noriyuki @n_soda

@syuu1228 @naota344 Gfarmの場合、ファイルへの書き込みを行なっているホストがディスクも提供している場合は、その書き込みを行なっているホストに配置されるんですよ。(ただしディスクに空きがある場合)

SODA Noriyuki @n_soda

@syuu1228 もし対話的プロセスにCPUが回ってこないことが問題だった場合には、それだけだと改善にならないというか、コンパイル処理の待ちが減り、対話的利用に対するCPU利用の競合が増えるので、かえって対話的レスポンスは低下します。まず何が問題で何が起きているのか調べないと

イーロン・マスクツイッターやめろ @naota344

@n_soda この場合はたとえばコンパイルプロセス全体のCPUとディスクIOの優先度を下げてtmpfsで運用、となるんでしょうか

イーロン・マスクツイッターやめろ @naota344

@n_soda そうですね、コンパイルに邪魔されなければいいのですが。まぁそれでもできるなら速く…

SODA Noriyuki @n_soda

@naota344 優先度についてはその通りです。NiLFSが使える状況なら、tmpfsよりも良いかもしれません(tmpfs使うよりも仮想記憶システムによる自動調整の方が良い結果がえられる可能性があるので)。負荷観察はまずはvmstatですよ。

イーロン・マスクツイッターやめろ @naota344

@n_soda うーん nilfs はそのためにある程度 disk 切らなくてはいけなくてお手軽ではない感が…。LANつないでIP範囲設定してデーモン立てておけば shm 共有して best でないにしろ better な環境が手にいれられれば…

Fadis @fadis_

コンパイル中だけディスクへの書き出しがちょっとやそっとじゃ発生しないように調整するとかどう? http://bit.ly/aoRFQc QT @naota344: うん、コンパイル速くというよりディスクIOさせたくない気持ちのほうが(ry

イーロン・マスクツイッターやめろ @naota344

@fadis_ ディスク上のファイルシステムのダーティページですよね…うむむ

Fadis @fadis_

@naota344 メインメモリ上のディスクキャッシュとディスクの間の同期を行う条件を極端に厳しくすることで、メモリが十分載っていればRAMディスクっぽい状態に出来ます。無論、システムが突然停止した際にいじっていたファイルが助からない確率は高くなりますが

イーロン・マスクツイッターやめろ @naota344

@fadis_ ああ、そうか…そうですね。でもなんかやっぱりディスク全体に影響来るのが… できるだけ影響範囲は少なくお手軽にしたいところで… FS mount しておけば OK ってのは魅力かなぁとか

イーロン・マスクツイッターやめろ @naota344

確かにあまりemerge中のプロセスの様子計測したことないな。なんかグラフ出せるものをつくってみるべきか

イーロン・マスクツイッターやめろ @naota344

でも依然として自分にのってるメモリが少ないマシンでLAN内のメモリ使えるといいような…うーむ メモリに乗っててもネット越しのが遅い？ コンパイル経過だからディスクになんか乗らなくていいのだらよ…

イーロン・マスクツイッターやめろ @naota344

とかいうようなことで研究になるんだろーかとちらっと思った。これでできるならやってみたいなぁ。ファイルシステム好きだし

Norihisa Fujita, ぽん @fjnli

@naota344 GbE<HDD seq readなので、そのあたりも考えだすと面白そうですね。

イーロン・マスクツイッターやめろ @naota344

@fjnli あ、 seq read だと HDD のが速いんですね。むむむ

イーロン・マスクツイッターやめろ @naota344

ChromeOS のビルドとかで分散コンパイルしたら速くなるんじゃないのかにゃ(ちらっ