L2ARCがやってきた

先日ご迷惑をおかけしたばかりですが、openSUSE 11.2のリリースの前にOSのバージョンをSolaris 10 10/09 (s10u8)に上げてしまいたかったので、日曜日の18時ごろから40分ほどftp.jaist.ac.jpを止めてしまいました。

Live Upgradeを使ったので、停止時間は再起動1回の間で済むはずだったのですが、ちょっとしたミスがあって停止時間が長くなってしまいました。敗因はluupgradeと再起動の間にZFSの構成が変わっていたことでした。luupgradeしたら、すぐに再起動しましょうね。

ともあれOSのバージョンはs10u8になり、晴れてL2ARCが使えるようになりました。L2ARCはSSDをリードキャッシュに使って、ZFSのランダムリードの性能を上げることができる仕組みです。ログをSSDに書き込んで同期書き込みの遅延を減らすZILはs10u6から使えたのですが、s10u8でようやくL2ARCが使えるようになりました。

L2ARCについては今のところarc.cのコメントが一番の情報源です。ZFSのメモリキャッシュARCは、MFUとMRUの2つのLRUリストで管理されています。この2つのLRUリストの末端の破棄されそうなキャッシュを一定期間ごとにSSDにコピーしておいて、ARCにヒットしなかった場合にSSDを見にいくというのがL2ARCの仕掛けです。

ftp.jaist.ac.jpでコンテンツを保持しているZFSのプールは2つあります。1つはiSCSIで作ったもの(zp-ftp-iscsi)、もう1つはFCのディスクアレイを2つつなげたもの(zp-ftp)です。SSDはIntel X25-M 160GBが4つあるので、zp-ftp-iscsiとzp-ftpにそれぞれ2つずつL2ARCとしてつなげました。以前紹介したいんちきキャッシュはお払い箱です。

運用を始めて気になったのが、なかなかL2ARCが埋まらないことです。43GiB以上あるARCもなかなか埋まらないのですが、今までは再起動後にARCが埋まらなくても、いんちきキャッシュのおかげで性能を稼げましたた。これからはそういうわけにはいきません。

ある程度埋まってくれば性能は出ます。今はほとんどのコンテンツがzp-ftpに載っているのでバランスが悪く、zp-ftpの2つのSSDが酷使されています。それでも4つのSSDのリードの合計は、いんちきキャッシュのころより20%ほど増えています。でもディスクアレイの負荷は、いんちきキャッシュのころの倍くらいに増えてしまいました。

いんちきキャッシュの場合は、SSDに載っているファイルもARCに載っていました。人気のあるファイルばかりですから、ARCによくヒットしていたでしょう。ARCと相補的に機能するL2ARCのほうがSSDを効率よく使えます。そのことはSSDのリードが増えたことでわかります。しかし、残念ながらヒット率が高くありません。kstat zfsで見ると60%前後といったところです。

L2ARCがなかなか埋まらないのは、200ミリ秒ごとに1つのキャッシュデバイス(SSD)に最大で8MiBしか書かないからです。4MiBより少ないデータしかキャッシュデバイスに書かなかった場合には、次は1秒後になるので書き込み頻度はもっと下がります。書き込み頻度と量を調べるdtraceのスクリプトを書いて様子を見たところ、書き込みの頻度は200ミリ秒ごとで頻繁に上限に当たっていました。

1つのキャッシュデバイスに1度に書き込む量は、zfs:l2arc_write_maxというカーネルパラメータで指定できます。ただし、この値が反映されるのはプールがインポートされるときか、キャッシュデバイスを加えたときだけです。すでに動いているキャッシュデバイスの値を変更するのは少し面倒ですが、できないこともありません。とりあえず2倍の16MiBにしたところ、いい感じで書き込まれるようになりました。ftp.jaist.ac.jpでは、これ以上大きな値は意味がなさそうです。

L2ARCのヒット率が低いのは、キャッシュデバイスをリングバッファとして使うためでしょう。デバイスの空きがなくなると、どれくらいヒットしたかは関係なく、デバイスに投入された順にキャッシュが捨てられます。キャッシュデバイスの扱いを極めてシンプルたことで、L2ARCの実行に掛かる負荷が低く抑えられている一方、ヒット率があまり上がらなくなっています。

もう一つ悩ましいのは、再起動するとL2ARCの内容を全部忘れちゃうことです。これはだいぶ頭が痛いです。

以上、L2ARCのファーストインプレッションでした。L2ARCでググってこのブログに来る人が多くて心が痛かったんですけど、これで少しは期待に応えられますかね。