请注意inode_cache&与dentry_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代码的所有服务器上 – 开发人员说他们在问题开始的时候没有改变与文件系统访问模式相关的任何内容.
发生的事情是,在一周内,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会在那里工作.
谢谢
亚历克斯
解决方法
迟到了,但也许对其他人来说很有用.
如果您在该EC2实例上使用AWS开发工具包,则卷曲很可能导致dentry膨胀.虽然我没有看到这个触发器OOM,但由于操作系统需要额外的工作来回收SLAB,因此已知它会影响服务器的性能.
如果您可以确认开发人员正在使用curl来访问https(许多AWS SDK都这样做),那么解决方案是将nss-softokn库升级到至少v3.16.0并设置环境变量NSS_SDB_USE_CACHE(对于使用libcurl的进程,YES和NO是有效值,您可能必须进行基准测试以查看哪些更有效地执行curl请求.
我最近遇到了这个问题并写了a blog entry(old blog entry link和upstream bug report),并附带了一些诊断信息.更详细的信息,以防万一.
