27 | 案例篇：为什么我的磁盘I/O延迟很高？
倪朋飞
该思维导图由 AI 生成，仅供参考
你好，我是倪朋飞。
上一节，我们研究了一个狂打日志引发 I/O 性能问题的案例，先来简单回顾一下。
日志，是了解应用程序内部运行情况，最常用也是最有效的工具。日志一般会分为调试、信息、警告、错误等多个不同级别。
通常，生产环境只用开启警告级别的日志，这一般不会导致 I/O 问题。但在偶尔排查问题时，可能需要我们开启调试日志。调试结束后，很可能忘了把日志级别调回去。这时，大量的调试日志就可能会引发 I/O 性能问题。
你可以用 iostat ，确认是否有 I/O 性能瓶颈。再用 strace 和 lsof ，来定位应用程序以及它正在写入的日志文件路径。最后通过应用程序的接口调整日志级别，完美解决 I/O 问题。
不过，如果应用程序没有动态调整日志级别的功能，你还需要修改应用配置并重启应用，以便让配置生效。
今天，我们再来看一个新的案例。这次案例是一个基于 Python Flask 框架的 Web 应用，它提供了一个查询单词热度的 API，但是 API 的响应速度并不让人满意。
非常感谢携程系统研发部资深后端工程师董国星，帮助提供了今天的案例。
案例准备
本次案例还是基于 Ubuntu 18.04，同样适用于其他的 Linux 系统。我使用的案例环境如下所示：
机器配置：2 CPU，8GB 内存
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
作者倪朋飞分享了解决磁盘I/O延迟高问题的实际案例和技术指导。文章首先回顾了一个由于开启调试日志导致的I/O性能问题，并介绍了通过iostat、strace和lsof等工具来定位和解决这类问题的方法。接着，作者提出了一个新的案例，讲述了一个基于Python Flask框架的Web应用响应速度不佳的情况。作者提供了案例准备的详细步骤，包括机器配置和预先安装的工具，并分享了使用Docker镜像来运行案例的方法。最后，作者强调了在操作过程中避免提前查看源码，而是将应用视为一个黑盒来分析，以更好地从系统资源使用问题出发，找出应用中的瓶颈所在。整篇文章以实际案例为基础，通过详细的操作步骤和技术指导，帮助读者了解如何定位和解决磁盘I/O延迟高的问题，展现了作者的技术专长和解决问题的方法论。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《Linux 性能优化实战》，新⼈⾸单¥68
《Linux 性能优化实战》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(36)
- 最新
- 精选
- 划时代赞同在strace -p PID后加上-f，多进程和多线程都可以跟踪。
作者回复: 👍
2019-01-213129 - jeff写文件是由子线程执行的，所以直接strace跟踪进程没有看到write系统调用，可以通过pstree查看进程的线程信息，再用strace跟踪。或者，通过strace -fp pid 跟踪所有线程。
作者回复: 👍 默认选项是不开启线程的
2019-01-2176 
郭江伟strace -p -f可以查看进程的所有线程信息，本例中python进程下可能同时存在两个线程，一个线程是socket相关，一个是跟文件读写相关，与文件读写相关的会频繁变化，只需跟踪进程树的最后一个线程就可以。 可以用pstree -p 查看Python的进程树，然后strace -p 线程号，不过本例中线程消失非常快，需要写个脚本才行 比如：Python进程号是13205 strace -p `pstree -p 13205 | tail -n 1 | awk -F '(' '{print $NF}' | awk -F ')' '{print $1}'作者回复: 赞，很好的思路
2019-01-23331
萧易客perf record -e 'fs:*' -ag perf report 使用perf命令可以从kernel层级记录文件系统的内核事件，相对strace我觉得perf还有一个优势就是对系统的消耗更低，更利于在生产环境使用。 http://www.brendangregg.com/perf.html作者回复: 嗯嗯，谢谢分享新的思路。 不过perf report 更多的是统计上的分析，而 strace 则是可以看到每一个调用的细节。
2019-01-2315
双不用那么麻烦吧，一般看用户进程cpu高的，iowait显著的话，直接lsof -p就能找到了什么文件了作者回复: 简单场景一条 lsof 就解决了，但复杂的场景则还需要更多的步骤
2019-01-2229
仲鬼老师好，案例里pidstat的iodelay为0，kB_wr/s也有300MB，是否说明应用程序写文件的性能没有收到影响，造成进程响应慢的可能是其他问题（如系统调用、打开文件等）？作者回复: 应该反过来，进程大量的 I/O 时，自己可能问题不大，但却导致了其他进程出现问题
2019-01-2227- Geek_00d753老师，请教个问题。在cpu密集型任务中一个进程的cpu利用率是各cpu的us%+sy%之和。但当iow%高的时候，这个进程的cpu利用率是怎么算的呢？就像第一个例子中，进程cpu利用率14%，比两个cpu的us%+sy%大很多。我之前理解的iow状态，进程在等io资源，这个时候应该是off-cpu的，是不是我理解错了。难道iow%有一部分也算是cpu占用的吗？那又是怎么计算的呢？谢谢
作者回复: 很好的问题。多个工具对比计算的时候一定要使用相同的时间间隔，间隔不同时，很可能就会碰到这个问题
2019-03-2126 - ninuxer打卡day28 我一般用strace -cp 来看系统调用的统计信息，然后用-e 查看对应调用的详情
作者回复: 嗯，不过注意strace默认不跟踪子线程的系统调用
2019-01-2125 - 仲鬼老师，线上环境kernal版本4.1以上的很少，能不能同时讲一些2.6、3.1等版本的替代工具？提一下名字也好，不然学半天原理，还是不能“实战”啊！
作者回复: 别急，工具是有的，但旧版本的工具难用的多，所以从简单易用的开始讲起
2019-01-214 
我来也[D27打卡] Ubuntu 18.04在安装bcc时出错,然后参考[https://www.codetd.com/article/3092913]可以成功安装. 因为ppa:hzwhuang/ss-qt5 并没有18.04版本的源，因此会出现 E: 仓库 “http://ppa.launchpad.net/hzwhuang/ss-qt5/ubuntu bionic Release” 没有 Release 文件 的错误。 这时，只要编辑/etc/apt/sources.list.d/hzwhuang-ubuntu-ss-qt5-bionic.list 文件，将bionic (18.04版本代号)改成xenial（16.04版本代号） 然后再执行第二三步骤即可。作者回复: 谢谢分享
2019-01-223
收起评论
