请注意，与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启动在所有托pipe一些networking代码的服务器上发生一天 – 开发人员说他们没有改变任何与文件系统访问模式相关的问题，然后问题就开始了。
系统是2.6.18内核的centos5，所以我没有任何新的内核可用的仪器function。 任何我想法如何我可以debugging的问题？ 也许与systemtap？ 这是一个ec2实例 – 所以不能确定systemtap将在那里工作。
感谢Alex
晚了，但也许有用的其他谁来这个。
如果您在该EC2实例上使用AWS开发工具包，那么curl极有可能导致dentry膨胀。 虽然我没有看到这个触发器OOM，但由于操作系统需要回收SLAB所需的额外工作，所以已知会影响服务器的性能。
如果您可以确认您的开发人员使用curl命中https（许多AWS SDK执行此操作），那么解决scheme是将nss-softokn库升级到至lessv3.16.0并设置环境variablesNSS_SDB_USE_CACHE（ YES和NO是有效值，您可能需要进行基准testing，以查看哪个执行curl请求更有效）是使用libcurl的进程。
我最近自己碰到了这个，写了一些博客条目 （ 旧博客条目链接和上游错误报告 ），附带一些诊断和更详细的信息，以防万一。
你有几个select。 如果我在这种情况下，我会开始跟踪统计：
# cat /proc/sys/fs/dentry-state 87338 82056 45 0 0 0
随着时间的推移，看看它有多快。 如果这个比率是有规律的，我认为你可以用两种方法来识别可能的罪魁祸首。 首先查看lsof的输出可能表明某个进程正在离开被删除的文件句柄。 其次，您可以使用应用程序对主要资源进行调整，并查找过多的与fs相关的调用（如open（），stat（）等）。
我也很好奇@大卫·施瓦茨的评论。 我还没有看到dentrycaching导致oom杀死东西的问题，但是如果它们仍然被引用并激活，可能会发生这种情况。 如果是这种情况，我很自信，LSF会揭露这个问题。