OpenSolaris 勉強会 2012.06
東京 OpenSolaris 勉強会主催の 2012.06 勉強会に参加してきた。
いつもであれば、要約した発表資料を元に "Solaris Internals" の内容について話すのだけれど、そろそろ書き溜めた分が尽きるので、読み込みをしないといけないなぁ、などと思っていたら、さくらインターネットサービスの障害調査報告が発表された旨のニュースが飛び込んで来た。
つらつらと眺めていると:
というような情報がポロポロと出てくる。
実際に『さくらのクラウド』の内部アーキテクチャがどうなっているのか、詳細はわからないけれど、公開されている情報をベースに考えると、ユーザが確保した仮想ディスク毎に、ファイルシステム作成＋exportが実施されているように読める。
物理的なクライアントは 1,000 台規模、契約ユーザ数と同数以上となる共有対象ファイルシステム数は 10,000 以上にはなると考えると、Solaris NFS のソースを読んだ身としては、明らかに適切性に欠けているとしか思えない。
オラクルの「Sun ZFS Storage Appliance」が利用されていることから、『ZFS は駄目だ！』的な言及を幾つか見たことがあったけど、それは違うんじゃねぇ？(あるいは、それ以前の問題じゃねぇ？)という思いがふつふつと。
ということで、ホットな話題でもあることなので、急遽お題目を変更して、大規模システムにおける Solaris NFS 実装の問題に関して話すことに。
急遽題目を変更しただけあって、予想通りというかなんというか、発表ギリギリになって、やっと資料が完成する始末…orz
＃ まぁ、直前に軽く風邪を引いたのも失敗だったのだけど…
発表的にはまぁまぁ好評だった模様で一安心だけど、『Solaris NFS 実装の問題』と言いつつ、結構な部分は『mountd 実装の問題』だったような気がしないでもないのは内緒(笑)。
但し、『線形走査が増えた場合に性能が劣化』というあたりは、参加者的には『本当？』という印象だった模様。っていうか、僕自身、実体験として経験していても、『二桁以上の要素の線形走査が発生すると、性能劣化の要因に成りえる』というのがイマイチ信じられない。
もっとも、単なる線形走査じゃなくて、strcmp() やら memcmp() で 32 バイトかそれ以上のメモリ比較を伴う線形走査なので、その辺も影響してくるかも？ということで、性能測定してみることに …… うーん、1,000 要素あっても 0.1 ミリ秒にもならんなぁ……
裏で大量の処理が併走しているファイルサーバと、デスクトップPC上での簡易ベンチとでは、キャッシュヒット的にもイコールコンディションでは無いけれど、それにしても 0.1 ミリ秒じゃぁねぇ。
んが、そこでハタと思い当たることが！
同じ事を２回書くのが面倒なので、興味のある方は、発表資料末尾に追記した『線形走査のコストに関する考察』をどうぞ(笑)。
あ、あと発表資料には書いてない対応策として『ハッシュテーブルサイズを大きくした独自カーネルモジュール／コマンドをビルドして使う』という手もあるので、切羽詰っている人はどうぞ(笑)。
