slab肥大化とdentry_cacheに辿り着くまでの話

  • 108
    いいね
  • 2
    コメント

内容(3行)

  • memoryの使用量を監視している所からアラートが来て調査した
  • アプリケーションのheap使用率は高くなく、top等を見ても他に怪しいプロセスが存在しない
  • /proc/meminfoからslab領域の肥大を確認、slabtopでdentry_cacheが肥大化している事がわかったので、echo 2 > /proc/sys/vm/drop_caches を実施した

何があったのか

運用中のとあるサーバーのmemoryが残り20%を切ったとアラートが来たため、調査を行った。
当初は何かしらのプロセスがメモリリークしているか何かだろうとあたりをつけていた。


freeで現状確認

キャプチャとるの忘れた…
が、一旦確かにfree(buffers, cahceを足したもの)がtotalの20%を切っていることを確認。


topで確認する

スクリーンショット 2014-11-04 13.19.07.png
アプリケーションプロセスにメモリを大量消費しているプロセスは無い。


/proc/meminfoを確認

スクリーンショット 2014-11-04 13.24.50.png

同スペック、同系統のアプリケーションが稼働しているサーバーと比較したところ、Slabの項目が消費しているメモリが大きいことが判明。


slabtopで内容を確認

スクリーンショット 2014-11-04 16.09.55.png

確認すると「dentry_cache」「size-64」の項目が使用量の上位を占めていることがわかる。また先程比較した同スペックの他のアプリケーションサーバーと比較しても、この項目の差異が大きいため、dentry_cacheについて調べた。


dentry(cache)とは

dentry、これを機に知ったのですが、何かというとファイル名やディレクトリの階層構造、またディレクトリ名とinode情報を関連付けるもの(構造体)らしい。dentry_cacheは、それらの情報のキャッシュだと思って良さそう。
またdentry_cacheは存在しないディレクトリ情報(inodeを持たないdentry)なんかもキャッシュする(これをnegative dentryというらしい)。negative dentryは、sarコマンド(-vオプション)で確認する事ができる。

スクリーンショット 2014-11-05 13.39.15.png

dentunusdがnegative dentryの数になる。
dentry_cacheについてはいくつかの記事を参考にさせていただいたが、このマシンでnegative dentryが有効に利用される用途が想定できないことから、このcacheを解放しても良いだろうと判断した。(実際には同じ名前で一時ファイルを定期的に作る処理が、実は監視の中であるのだが、同様の処理他のマシンでも実施しているため、今回の問題の最大の原因ではないと考えた)


cacheの削除

これについては、詳しい記事が沢山あるのでここでは割愛。

echo 2 > /proc/sys/vm/drop_caches

上記コマンドでdentry, inodeのキャッシュを削除する。


結果

slabtop
スクリーンショット 2014-11-05 14.18.29.png

free
スクリーンショット 2014-11-05 14.20.14.png

意図したとおり、dentry_cacheが解放され、freeの容量が増えた。


参考資料