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
