[D17打卡]
想不到Buffer 和 Cache还有专门的工具分析, 长见识了!
暂时只能在自己的机器上玩玩, 生产环境连root权限都没有,更别提升级CentOS内核版本了.
-----------------
关于思考题,我是这样想的:
出现性能问题时的症状可能并不是单一的.
比如这次同一个案例,从CPU和缓存两个不同的角度, 都是定位到了代码中的open.
cpu角度分析的流程是:
1.top 看到了%iowait升高
2.dstat 看到了wait升高时 read同步升高. 说明跟磁盘相关
3.$ perf record -g ; $ perf report 定位到了跟磁盘相关的系统调用 sys_read(). new_sync_read 和 blkdev_direct_IO 定位到了跟直接读有关系.
4.查看代码 找到了跟磁盘相关的系统调用 open.
缓存角度分析的流程是:
1.进程5秒缓存命中率100%,但是只命中了1024次,推算使用缓存4MB.实际每秒0.8MB
2.看日志知道每次读取的是32MB.[实际也可以通过dstat vmstat等工具粗略推算出该值]
3.预期的32M与实际的0.8M相差甚远. 来找原因.
4.strace 查看系统调用 定位到了openat 及 直接给出了调用参数 O_DIRECT
5.查看代码 找到了跟磁盘相关的系统调用 open.
-----------------
个人总结:
顺藤摸瓜, 根据现像找本质原因.
磁盘io导致性能问题 -> 查看系统调用 -> 定位大致原因 -> 查看源码 -> 确定问题
还居然在完全不知道程序具体实现的基础上,定位到了引起性能问题的系统调用. 有的甚至还直接给出了参数,太牛了.
展开
作者回复: 总结的很好,其实两个思路都可以,不过具体实践时可能会受限于可用的性能工具