ARCミスを分析してみた

先日の障害で、ARCミスしたI/OがHDDで処理できるIOPSを超えていることがわかりました。そこでZFSへのアクセスのうち、どんなARCミスがどれくらい発生しているかを調べてみました。使ったのはこのDTraceスクリプトです。プロセスとファイルシステムのオペレーション(vnode operation)ごとに、ARCミスとL2ARCミスの発生回数を100秒間計測します。12月12日の16:30にHDDの負荷の平均が81.7%のときにデータを取りました。

ARCのヒット率は平均で93%ですが、ARCミスは1秒当たり1,709回発生していました。そしてL2ARCミスは1秒当たり491回でした。L2ARCには71%ヒットしています。L2ARCミスしたI/OはZIO (ZFS I/O Pipeline)を経て仮想デバイス(VDEV)に向かいます。VDEVはRAIDを抽象化する層です。論理ボリュームマネージャ(LVM)のボリュームグループに相当します。この流れを示したのが以下の図です。

zpool iostatでVDEVのIOPSがわかります。このデータを取る直前のIOPSは475でした。L2ARCミスに見合う数字です。L2ARCがなければARCミスがVDEVに向かいます。冒頭で述べたように、このときHDDの平均負荷は81.7%です。ARCミスの1,709回/秒は、このときのVDEVのIOPSの3.6倍になります。これを処理するのは明らかに無理です。今のftp.jaist.ac.jpではL2ARCは外せないということです。

ARCミスの詳細を見てみます。以下に示したグラフはファイルシステムのオペレーションごとの1秒当たりのARCミスです。ARCミスの原因で最も多いのはfop_lookupです。名前からvnodeを探す操作です。これとほぼ同じ回数なのがfop_getpageです。sendfileで使われています。あとはfop_read、fop_readdirと続きます。ファイル名からファイルを見付ける操作によるARCミスが半分を占めていることがわかります。

以前紹介したHTTPのリクエストに基づいてSSDにキャッシュするシステムは、この類のARCミスをほとんど助けられません。以前分析したとおり、現在のftp.jaist.ac.jpのワークロードでは役に立ちません。昔はHDDの負荷が上がるのは、Linuxディストリビューションの新しいバージョンがリリースされて、ISOファイルへのアクセスが集中したときでした。ですから、それらのファイルをSSDにキャッシュしていれば負荷が下がりました。今は同じ手は通用しないことになります

以下に示したグラフはプロセスごとの1秒当たりのARCミスです。上のグラフで想像は付きますが、2番目はrsyncで31%を占めています。

次のグラフはプロセスとオペレーションの組み合わせによる1秒当たりのARCミスです。fop_lookupのミスはhttpdとrsyncで分け合っています。fop_readdirはほぼ全部rsyncでした。rsyncのディレクトリ階層を再帰的に巡回する操作が、ARCミスをたくさん引き起こしていることがわかります。意外だったのは、sendfileを使うように設定したはずのvsftpdがreadを使っていたことです。これは見直しが必要です。

この時間のHTTPの接続は2842でrsyncはわずか11です。rsyncはチェックサムを計算するので、シングルスレッド性能の低いUltraSPARC T1には、ただでさえ厳しいです。その上にHDDにまで大きな負荷を掛けているとは思いませんでした。とはいえ、rsyncを止めてもhttpdのARCミスは1秒に1077回あるので、L2ARCなしで処理できる数をはるかに超えています。当分はL2ARC頼みの日々が続きます。