ストライピングはなぜ速いのか

普通のRAIDでもRAID-Zでも複数のディスクにデータがストライピングされます。ディスクの本数を増やせばシーケンシャルリードは速くなると一般に言われていますし、実際そうです。ランダムリードとはいえ、ストライピングされているのにRAID-Zが遅いことに納得できない人が多いようです。何の説明が足りないか考えていて、ハードディスクの遅延を忘れていたことに気が付きました。僕もそれを忘れていたため誤った説明をしていました。

L2ARCを止めてみた(後編)

前編に書いたように、pcacheをARCでキャッシュしない設定でデータを取ってみたところ、ARCのヒット率は93.4%から59.8%にL2ARCは63.5%から3.6%に激減しました。pcacheはほぼ変わらず59.8%です。ARC、L2ARCともにヒットしたデータは、ほとんどpcacheからもたらされたものであったことがわかります。L2ARCにいたってはほとんどがそうでした。このときの処理の流れを示したのが以下の図です。

L2ARCを止めてみた(前編)

「RAID-Zは遅いよ」で書いたように、ZFSのSSDによるキャッシュとしてL2ARCと自作のpcacheを用いていています。SSDはIntel X25-M 160GBが4個あり、L2ARCとpcacheに2個ずつ割り当てています。pcacheはARCでキャッシュしています。pcacheの役割はARCとL2ARCが埋まるまでの時間かせぎなので、それでいいと思っていました。

Solaris 10 08/11 (u10)へのアップグレードではまった

以前からpcacheのZFSで、消したファイルの領域が解放されない現象に悩まされていました。ファイルをオープンしているプロセスがいるならわかるのですが、サービスを全部止めてオープンしているプロセスがいなくなっても空き領域が増えないのです。その結果、duで確認した使用量とdfで確認した使用量がどんどん乖離していきます。

RAID-Zは遅いよ

以前紹介しましたが、ftp.jaist.ac.jpのストレージは2TBのDeskstar 7K2000を24個積んでいます。ZFSの構成は、11個ずつでRAID-Z2を2つ作りストライピングしています。残りの2個はRAID-Z2のスペアです。この構成の問題は読み込みのIOPS (1秒間あたりに可能な読み込み回数)がとても少ない低いことです。