如何找出导致大量 dentry_cache 使用的原因？

Question

请注意，与 dentry_cache 相比，inode_cache 和 ext3_inode_cache 块非常小。发生的事情是缓慢而稳定地在一周内 dentry_cache 从 1M 增长到 ~5-6G 然后我需要运行 echo 2 > /proc/sys/vm/drop_caches && echo 0 > /proc/sys/vm/drop_caches 这一天开始在托管一些 Web 代码的所有服务器上发生 - 开发人员说他们没有改变任何相关的到文件系统访问模式，然后问题就开始了。

系统是带有 2.6.18 内核的 centos5，所以我没有任何可用的新内核检测功能。我知道如何调试问题吗？也许用systemtap？这是一个 ec2 实例 - 所以甚至不确定 systemtap 会在那里工作。

谢谢亚历克斯

Answer 1

晚了，但可能对遇到此问题的其他人有用。

如果您在该 EC2 实例上使用 AWS 开发工具包，则 curl 很可能导致 dentry 膨胀。虽然我还没有看到这个触发 OOM，但已知它会影响服务器的性能，因为操作系统需要额外的工作来回收 SLAB。

如果您可以确认您的开发人员正在使用 curl 来访问 https（许多 AWS 开发工具包都这样做），那么解决方案是将 nss-softokn 库升级到至少 v3.16.0 并设置环境变量 NSS_SDB_USE_CACHE（ YES 和 NO 是有效值，对于使用 libcurl 的进程，您可能需要进行基准测试以查看哪个更有效地执行 curl 请求）。

我最近自己遇到了这个问题，并写了一个博客条目（旧博客条目链接和上游错误报告），其中包含一些诊断信息和更详细的信息，以防万一。

Answer 2

你有几个选择。如果我处于这种情况，我会开始跟踪以下方面的统计数据：

# cat /proc/sys/fs/dentry-state 
87338   82056   45      0       0       0

随着时间的推移，看看它的增长速度有多快。如果该比率有点规律，我认为您可以通过两种方式识别可能的罪魁祸首。首先查看 lsof 的输出可能表明某些进程正在删除的文件句柄周围。其次，您可以使用应用程序跟踪主要资源并查找过多的 fs 相关调用（例如 open()、stat() 等）。

我也对@David Schwartz 的评论感到好奇。我还没有看到 dentry 缓存导致 oom 杀死东西的问题，但如果它们仍然被引用并且处于活动状态，也许会发生这种情况？如果是这样的话，我非常有信心 lsof 会揭露这个问题。