#内容（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で確認する
アプリケーションプロセスにメモリを大量消費しているプロセスは無い。
/proc/meminfoを確認
同スペック、同系統のアプリケーションが稼働しているサーバーと比較したところ、Slabの項目が消費しているメモリが大きいことが判明。
slabtopで内容を確認
確認すると「dentry_cache」「size-64」の項目が使用量の上位を占めていることがわかる。また先程比較した同スペックの他のアプリケーションサーバーと比較しても、この項目の差異が大きいため、dentry_cacheについて調べた。
dentry（cache）とは
dentry、これを機に知ったのですが、何かというとファイル名やディレクトリの階層構造、またディレクトリ名とinode情報を関連付けるもの（構造体）らしい。dentry_cacheは、それらの情報のキャッシュだと思って良さそう。
またdentry_cacheは存在しないディレクトリ情報（inodeを持たないdentry）なんかもキャッシュする（これをnegative dentryというらしい）。negative dentryは、sarコマンド（-vオプション）で確認する事ができる。
dentunusdがnegative dentryの数になる。
dentry_cacheについてはいくつかの記事を参考にさせていただいたが、このマシンでnegative dentryが有効に利用される用途が想定できないことから、このcacheを解放しても良いだろうと判断した。（実際には同じ名前で一時ファイルを定期的に作る処理が、実は監視の中であるのだが、同様の処理他のマシンでも実施しているため、今回の問題の最大の原因ではないと考えた）
cacheの削除
これについては、詳しい記事が沢山あるのでここでは割愛。
echo 2 > /proc/sys/vm/drop_caches
上記コマンドでdentry, inodeのキャッシュを削除する。
結果
slabtop
free
意図したとおり、dentry_cacheが解放され、freeの容量が増えた。