05 分析篇 | 如何判断问题是否由Page Cache产生的?
该思维导图由 AI 生成,仅供参考
Linux 问题的典型分析手段
- 深入了解
- 翻译
- 解释
- 总结
本文介绍了如何通过分析Linux系统的Page Cache来判断系统load是否由Page Cache引起,并提供了详细的分析方法和工具。作者首先介绍了典型的Linux问题分析手段,包括使用/proc和/sys导出系统信息,以及专业的分析工具如ftrace,ebpf,perf等。然后,作者详细讲解了如何使用sar工具采集Page Cache的概况和PSI信息来查看内存压力情况,并进一步查看Page Cache的行为指标来分析问题根源。文章还提到了利用tracepoint观察内存规整,并借助自动化分析工具高效分析采集的信息。总的来说,本文提供了丰富的分析方法和工具,帮助读者快速了解如何判断问题是否由Page Cache引起,并进行深入分析。文章还强调了分析方法论的普适性,适用于系统其他层面引起的问题。读者可以从中学习到如何观察Page Cache的行为、使用专业工具进行细致分析以及如何处理内存紧张的情况。
《Linux 内核技术实战课》,新⼈⾸单¥59
全部留言(13)
- 最新
- 精选
- 邵亚方置顶课后作业答案: - 假设现在内存紧张, 有很多进程都在进行直接内存回收,如何统计出来都是哪些进程在进行直接内存回收呢? 评论区里有人已经很好的回答了这个问题,使用tracepoint是最简单的方法。 “已经得知是直接内存回收引起的问题,一次执行 echo 1 >/sys/kernel/debug/tracing/events/vmscan/mm_vmscan_direct_reclaim_begin echo 1 >/sys/kernel/debug/tracing/events/vmscan/mm_vmscan_direct_reclaim_end 打开直接内存回收相关的tracepoint,然后 cat /sys/kernel/debug/tracing/trace_pipe 查看跟踪输出,得到进程号“2020-10-1117
- 我来也邵老师,看了文中的一句话,正好有个困扰很久的疑问请教一下: 我们什么时候会真的遇到需要申请连续物理内存的情况? > “单位时间内 compact_fail 变化很大时,那往往意味着系统内存碎片很严重,已经很难申请到连续物理内存了” 这里提到了“连续物理内存”。 平常也经常会看到这个描述。 我们知道,每个用户进程都有自己独立的虚拟内存地址空间。 自己申请到的内存地址其实只是进程虚拟内存中的一个地址,并不是实际的物理内存地址。 只有自己在用到了对应的虚拟地址时才会,系统才会通过缺页异常来分配具体的物理地址。 而系统的内存一般都是4k一个页表。 很有可能在进程中连续的虚拟内存地址,在实际的物理内存中并不是连续的。 现在几乎都只有内核有权限直接操作物理内存了。 所以我就有了开头的那个疑问。
作者回复: 进程既有用户态也有内核态,在进程处于内核态时,就可能会申请连续内存。比如说进程要打开一个文件,那就会先查找该文件是否存在,查找的过程就是在内核态来完成的,然后这个过程中会分配文件所需要的一些内核结构体,比如dentry,inode等,这就需要申请内存,这些内存就是连续物理内存。
2020-08-3011 - J.Smilesar 里面记录的 PSI(Pressure-Stall Information)具体怎么用啊?
作者回复: 这个是proc里面的文件,使用前提是,你的内核需要支持它,需要4.18以及更新的内核。如果内核支持了该特性,你就可以去/proc/pressure/里面去读取它了,这里面会有memory,io,cpu的信息。 你可以做一些工具来解析这些信息,具体做法可以参考sar的做法。 采集完这些数据后,你就可以使用它来作为系统压力指标的参考了。比如在业务有抖动时,你可以观察是否某个指标有异常。
2020-08-2928 - KennyQ很多生产问题都是要对秒级甚至毫秒级的行为进行分析,而业务一旦向运维部门反馈了问题以后,一般都是要做事后分析, 那么一般如何应对这样的问题分析场景? 是针对一些重要指标在事前就进行秒级监控?分钟级监控?还是等待事后部署秒级的监控脚本进行信息抓取?
作者回复: 如果采集的数据很多,那么秒级监控的开销还是很大的,所以一般都不会每秒去采集很多系统指标。通常情况下都是采用事件机制,比如在内核里一些关键路径上挂上钩子,当异常行为发生时就把该事件记录下来,但是这样做毕竟只是针对有限的事件,不会涉及到太多的事件,不然系统开销还是会大。所以在发生问题后的事后采集机制还是有必要的,因为发生问题后,运维或者业务会更加关注原因会是什么,对采集带来的开销会有心里预期,所以可以接受一定程度的损耗。很多时候借助这些粗力度的指标,是可以大致判断出问题可能出在哪里,然后再针对性的去做更细粒度的监控。 想要精确,就需要结合业务来深度定制监控;想要覆盖面广一些,就要尽量保障监控开销。鱼与熊掌是很难兼得的。
2020-09-056 - Eria请教老师一个问题:我们两个机器上一样的系统和硬件配置和服务,运行相同的测试: 1. 系统 A 的磁盘 util 很小(3%-10%),但是可以看到 80G 左右的 buffer/cache,系统 A 的服务延迟非常小 2. 系统 B 的磁盘 util 很高(大于 30%),buffer/cache 10G 左右,系统 B 的服务延迟是 A 的好几倍 系统 B 是否可能由于太小的 buffer/cache 导致 disk util 飙高进而导致延迟上升?两个系统的 cahce 参数配置是一样的,所以为什么系统 B 的 buffer/cache 会比系统 A 小那么多?
作者回复: buffer/cache小的话,workingset refault会多,这会导致ioutil太高。为什么B中的buff/cache会比A中小那么多,我猜测是因为B中有很多不可以被回收的内存导致的,你可以观察下两个机器的/proc/meminfo,对比看看哪些项存在差异?
2020-09-025 - Geek_circle老师好,想确认下页面的换出是否依赖系统开启的swap分区(一般linux系统为了避免影响性能,都是关闭不启用swap的),如果不依赖,这个换出的页面是放置在物理硬盘的哪里呢? .这个sar统计的pgpgin和pgpgout 如何解读呢
作者回复: 页的交换是要依赖swap分区的,在开启了swap后匿名页(比如堆内存)就可以被交换到swap分区,这个行为会体现在pswpin和pswpout这两个指标中。 而pgpgin和pgpgout则是指文件页的读入读出,将磁盘文件读入内存和脏页写回磁盘,它们跟swap是没有关系的,即使没有swap也会有pgpgin和pgpgout。
2020-09-134 - ray老师您好,请问 ==> /proc/pressure/cpu <== some avg10=0.00 avg60=0.00 avg300=0.00 total=10078249 ==> /proc/pressure/io <== some avg10=18.04 avg60=17.66 avg300=19.08 total=1334977849 full avg10=17.54 avg60=16.98 avg300=18.49 total=1294527367 ==> /proc/pressure/memory <== some avg10=0.00 avg60=0.00 avg300=0.00 total=0 full avg10=0.00 avg60=0.00 avg300=0.00 total=0 1. 上述cpu, io, memory指标的avg的计算方式是,单位 / 秒数,我的疑问是这3个指标是用什么单位除以秒数计算出平均值?(以memory为例,可能是page / s,但我不是很清楚单位是否是page) 2. total代表的意思是什么? 谢谢老师的解答^^
作者回复: 1. 这个单位是应用程序阻塞时间,以memory为例,那就是进程在内存申请上消耗的时间。加入10s内,进程在内存申请上消耗了5s,那avg10就是50。 2.total代表进程总的消耗时间,包括历史累积值。以memory为例,那就是在内存申请上消耗的总时间。 这些在Documentation里都有说明 。
2020-08-3024 - Linuxer请问一下邵老师,如何确定负载高是锁冲突导致的呢?还有就是象 resource temporarily unavailable这种报错我想知道具体是哪一种资源,是不是可以通过系统快照找到呢?
作者回复: - 负载高是否是由锁冲突导致的 锁冲突有两类,一类是D,一类是spin,简单查看当前系统处于D和R的任务以及调用栈就可以判断,比如使用sysrq。 — resource temp unavailable 这个无法通过快照来查看 因为这是一次性的行为 结束后就没有现场了 除非可以复现出来
2020-10-223 - Geek_b85295关于课后作业,我来依葫芦画瓢,还望老师指教。 已经得知是直接内存回收引起的问题,一次执行 echo 1 >/sys/kernel/debug/tracing/events/vmscan/mm_vmscan_direct_reclaim_begin echo 1 >/sys/kernel/debug/tracing/events/vmscan/mm_vmscan_direct_reclaim_end 打开直接内存回收相关的tracepoint,然后 cat /sys/kernel/debug/tracing/trace_pipe 查看跟踪输出,得到进程号
作者回复: 赞!回答的很好!
2020-09-292 - jssfy请问老师你们生产环境是否用4.18+内核多? 还是定制迁移相关特性到自维护版本内核?
作者回复: 互联网企业普遍都是基于centos或者Ubuntu的内核,然后在这些内核的基础上来做自己定制化的特性,这些特性既有backport的 也有根据自己场景来实现的特定需求。生产环境上centos7是主流,内核为3.10,其次是centos8,内核为4.18。
2020-08-302