[原创]systemtap脚本分析系统中dentry SLAB占用过高问题

  • 时间:
  • 浏览:0
  • 来源:5分6合APP下载_5分6合APP官方

备注

内存回收主要的两大机制:kswapd和“Low on Memory Reclaim”。即当系统中的可用内存很少时,守护多多tcp连接 kswapd被唤醒现在现在开始 释放页面,肯能内存压力很大,多多tcp连接 也会同步地释放内存,你你这名 情况报告被称为direct-reclaim.

kswapd释放内存页面的数量是有一定的比例的(有兴趣还里能查阅pages_min, pages_low and pages_high什么参数),但会 当内存的分配占用率高于释放率时,就引起了上述的什么的问题即看得人内存一直在增长。

查看监控中的slab曲线一直处在增长情况报告

再全部查看一下dentry的使用情况报告:

$cat /proc/sys/fs/dentry-state

209810031 2091005757 45 0 0 0

从上边肯能看出必须/etc/pki/nssdb/._dOeSnotExist_ 的使用不明确搜索一把,发现redhat 6系列的系统中处在的什么的问题, bug分析全部参考:

Can curl HTTPS requests make fewer access system calls?

https://bugzilla.redhat.com/show_bug.cgi?id=1044666

查看某一台主机上的dentry条目如下,约3.3亿。

$cat /proc/sys/fs/dentry-state

3310031179 3310022259 45 0 0 0

systemtap脚本执行完成后,生成日志文件,经分析/etc/pki/nssdb/xxxx,占用量最大1点多亿条dentry.

$sudo grep "/etc/pki/nssdb" dcache.log |wc -l

131071404

此例什么的问题对所有linux主机上dentry占用较高分析有借鉴参考意义。

dentunusd:在缓冲目录条目中越来越 使用的条目数量.

file-nr:被系统使用的文件句柄数量.

inode-nr:使用的索引节点数量.

pty-nr:使用的pty数量.

1)dentunusd

dentunusd数据的数据来源是/proc/sys/fs/dentry-state的第二项数据.

要弄明白它的意义,当当我们首越来越 弄明白dcache(目录高速缓存),肯能系统中所有的inode都是通过文件名来访问的,而为了补救文件名到inode转换的时间,就引入了dcache.

它是VFS层为当前活动和最近使用的名字维护的却说cache.

dcache中所有处在unused情况报告和negative(消极)情况报告的dentry对象都通链入到dentry_unused链表中,你你这名 dentry对象在回收内存时肯能会被释放.

肯能当当我们在系统中运行ls -ltR /etc/会看得人dentunusd的数量会多起来.

而通过mount -o remount /dev/sda1会看得人dentunusd会迅速会回收.

2)file-nr

file-nr的的数据来源是/proc/sys/fs/file-nr文件的第一项数据.

实际上file-nr都是却说准确的值,file-nr每次增加的步长是64(64位系统),类似现在file-nr为2528,实际上肯能只打开了2527个文件,而此时你打开却说文件后,它就会变成2592,而都是25100.

3)inode-nr

inode-nr的数据来源是/proc/sys/fs/inode-nr文件的第一项数据减去第二项数据的值.

inode-nr文件的第一项数据是肯能分配过的INODE节点.第二项数据是空闲的INODE节点.

类似,inode-nr文件里的值为:13720 7987

当当我们新建却说文件file1,此时inode-nr第一项数据会加1,却说13721,表示系统里建立了越来越 多的inode.

当当我们再删除掉file1,此时就会变成13720.

空闲的INODE节点表示当当我们肯能里越来越 多的INODE节点却说有过被利用,但越来越 被释放.

越多INODE节点总数减去空闲的INODE,却说正在被用的INODE.

最后通过使用mount -o remount /dev/sda1命令,空闲节点会被刷新,越多inode-nr的值会有所变化.

4)pty-nr

pty-nr的数据来源是/proc/sys/kernel/pty/nr

表示登陆过的终端总数,肯能当当我们登录过10回,退出了3回,最后的结果还是10回.

dentry的作用:当读写文件时内核会为该文件对象建立却说dentry,并将其缓存起来,方便下一次读写时直接从内存中取出提高强度。

肯能tengine主机上调用了一定量的curl https做探测(curl的版本7.19),使用如下命令做了一下分析还里能明确发现一次curl有上百次的访问/etc/pki/nssdb/.xxx文件产生一定量的dentry,

从上查看dentry使用数量,还里能发现有一定量unused dentries占用率很高,越来越 释放掉。

原创文章:来自systemtap脚本分析系统中dentry SLAB占用过高 什么的问题

关于linux dentry的介绍还里能搜出来一大把,包括dentry占用过高 ,不外乎并否是 补救辦法 ,并否是 是直接通过proc系统清理dentry,命令如下:

sudo sh -c "echo 2 > /proc/sys/vm/drop_caches"

缺点是执行命令过程容易hang住几分钟,但会 redhat官方却说建议使用你你这名 辦法 清理cache等;另外并否是 辦法 是通过调整内核参数vm.vfs_cache_pressure,含义如下,先调整为vm.vfs_cache_pressure=1000观察一天也越来越 发现能使dentry降下去。

vm.vfs_cache_pressure控制内核回收用于dentry和inode cache内存的倾向。 默认值是100,内核会根据pagecache和swapcache的回收情况报告,让dentry和inode cache的内存占用量保持在却说相对公平的百分比上。减小vfs_cache_pressure会让内核更倾向于保留dentry和inode cache。当vfs_cache_pressure等于0,在内存紧张时内核却说会回收dentry和inode cache,这容易原应OOM。肯能vfs_cache_pressure的值超过100,内核会更倾向于回收dentry和inode cache。

另外肯能agent周期性的在拉取配置文件什么配置文件以当前时刻做文件名,也造成一定量的dentry。两者加起来的数量基本符合/proc/sys/fs/dentry-state查出来的数量。

至此什么的问题的却说主要原应肯能比较清楚。

以上数据的全部含义还里能man proc查看,下边是还里能从网上查到的中文含义

全部查看slab中各部分内存的占用,还里能看出dentry占用的越多,最少在40GB内存。

cat /proc/meminfo细化查看内存各部分的使用,还里能发现slab占用过高 约40GB,共同也还里能观察到SReclaimable也很高,即SReclaimable指可撤销Slab的大小。

利用systemtap脚本分析系统中dentry SLAB占用过高 什么的问题

sudo strace -f -e trace=access curl 'https://www.taobao.com'

12:07:09 AM dentunusd file-nr inode-nr pty-nr

12:07:10 AM 183107848 1088 42210 44

12:07:11 AM 183107871 1088 42245 44

12:07:12 AM 1831165100 1152 42290 44

12:07:13 AM 183116581 1088 42343 44

12:07:14 AM 183116617 1216 42396 44

12:07:15 AM 1831110059 1216 40585 44

$grep '/etc/pki/nssdb' dcache.log | more

/etc/pki/nssdb/._dOeSnotExist_-869749107.db 223

/etc/pki/nssdb/._dOeSnotExist_-869749108.db 224

/etc/pki/nssdb/._dOeSnotExist_-869749109.db 225

/etc/pki/nssdb/._dOeSnotExist_-869749110.db 226

/etc/pki/nssdb/._dOeSnotExist_-869749111.db 227

/etc/pki/nssdb/._dOeSnotExist_-869749112.db 228

/etc/pki/nssdb/._dOeSnotExist_-869749113.db 229

/etc/pki/nssdb/._dOeSnotExist_-869749114.db 2100

/etc/pki/nssdb/._dOeSnotExist_-869749115.db 231

/etc/pki/nssdb/._dOeSnotExist_-869749116.db 232

/etc/pki/nssdb/._dOeSnotExist_-869749117.db 233

/etc/pki/nssdb/._dOeSnotExist_-869749118.db 234

/etc/pki/nssdb/._dOeSnotExist_-869749119.db 235

/etc/pki/nssdb/._dOeSnotExist_-869749120.db 236

/etc/pki/nssdb/._dOeSnotExist_-869749121.db 237

/etc/pki/nssdb/._dOeSnotExist_-869749122.db 238

/etc/pki/nssdb/._dOeSnotExist_-869749123.db 239

/etc/pki/nssdb/._dOeSnotExist_-869749124.db 240

/etc/pki/nssdb/._dOeSnotExist_-869749125.db 241

/etc/pki/nssdb/._dOeSnotExist_-869749126.db 242

/etc/pki/nssdb/._dOeSnotExist_-869749127.db 243

/etc/pki/nssdb/._dOeSnotExist_-869749128.db 244

/etc/pki/nssdb/._dOeSnotExist_-869749129.db 245

/etc/pki/nssdb/._dOeSnotExist_-8697491100.db 246

……

收集内存使用的相关信息如下:

因内存占用率报警mem:76.28%先看一下内存的总体使用情况报告,从下图中还里能看出used占用较高,buffers/cached占用较少(关于cached占用过高 的分析补救请参见另一篇文章), 这时首先想到是都是有多多tcp连接 内存泄漏,经查询tengine和别的多多tcp连接 越来越 发现有占用一定量内存即不处在内存泄漏。

长时间运行着的tengine主机有内存占用75%以上的报警.

日志分析

操作系统版本: 2.6.32.el6.x86_64

即然上述却说辦法 都是的是完美的辦法 ,就须要确认越来越 多unused dentries到底是什么文件占用的? 按正常理解情况报告下linux内核不太肯能释放不了dentry。

首先通过查看内核dentry社会形态部分的代码(fs/dcache.c),搞清楚了所有的unused dentries挂在了super_blocks 社会形态的s_dentry_lru链表上,还里能通过遍历此链表上的节点输出什么节点代表的文件名,就还里能知道dentries被什么文件占用。

思路:用systemtap工具做内核探测,将每个节点的文件名写入到log文件。guru模式关键代码如下:

也可用于sar命令查看dentunusd以秒为间隔查看dentry的变化。

$sar -v 1

猜你喜欢

为什么我家的的wifi信号满格,手机能显示信号,但就和没连一样 不能用,为什么

很高兴为你服务至于你的间题,很简单,只有三个白多多将会性愿因分析,展开完整版展开完整版使用百度知道APP,立即抢鲜体验。你的手机镜头里或许有别人想知道的答案。怪怪的推荐扫描二维

2020-02-20

家里网络能看电视,手机却经常连不上网,是路由器的原因吗

采纳数:40527获赞数:106725展开完正你对这些回答的评价是?收起更多回答(1)可选中俩个 或多个下面的关键词,搜索相关资料。也可直接点“搜索资料”搜索整个问提。展开完

2020-02-20

游客esqfqydq476om的主页

文章:0丨粉丝:7339丨话题:0文章:1丨粉丝:38663丨话题:0数据库,NoSQLKubernetes、Docker、调度、里边件文章:104丨粉丝:8129丨话题:1阿

2020-02-20

复旦博士给机器人当语言老师,教出了英语四级水平的“阿里小蜜“

“在阿里,服务体量广,业务场景多,人工智能有更多的发挥空间,我的工作也更有价值。”Peter说。谁也想没办法,2017年3月,这人 复旦博士回国做的第一件事,是加入阿里巴巴集

2020-02-20

官方 | 从机器翻译到阅读理解,一文盘点PaddlePaddle九大NLP模型

近日,百度PaddlePaddle开源了语义表示模型ERNIE,在多个中文NLP任务上表现超越了谷歌的BERT,展示了百度在NLP技术的领先能力,同时也表明PaddlePadd

2020-02-20