☰

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

tag-icon • tag-icon linux memory
如何找出导致 dentry_cache 使用量巨大的原因？

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

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

谢谢亚历克斯

答案1

很晚了，但也许对遇到这种情况的人有用。

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

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

我最近也遇到了这个问题并写道一篇博客文章（旧博客条目链接和上游错误报告) 提供一些诊断和更详细的信息，希望有帮助。

答案2

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

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

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

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

答案3

在我们的案例中，我们可以通过观察以下几点来识别粗糙的过程 minflt/s

pidstat -l -r
pidstat -l -r | sort -k4nr    # Sort on 4th column. Numerically, reverse (descending). RHEL6.
pidstat -l -r | sort -k5nr    # On newer pidstat, minflt/s is the 5th column. RHEL 7.

相关内容