30 | 套路篇：如何迅速分析出系统I/O的瓶颈在哪里？
倪朋飞
该思维导图由 AI 生成，仅供参考
你好，我是倪朋飞。
前几节学习中，我们通过几个案例，分析了各种常见的 I/O 性能问题。通过这些实战操作，你应该已经熟悉了 I/O 性能问题的分析和定位思路，也掌握了很多 I/O 性能分析的工具。
不过，我想你可能还是会困惑，如果离开专栏，换成其他的实际工作场景，案例中提到的各种性能指标和工具，又该如何选择呢？
上一节最后，我留下了作业，让你自己整理思路。今天，我就带你一起复习，总结一下，如何“快准狠”定位系统的 I/O 瓶颈；并且梳理清楚，在不同场景下，指标工具怎么选，性能瓶颈又该如何定位。
性能指标
老规矩，我们先来回顾一下，描述 I/O 的性能指标有哪些？你可以先回想一下文件系统和磁盘 I/O 的原理，结合下面这张 Linux 系统的 I/O 栈图，凭着记忆和理解自己写一写。或者，你也可以打开前面的文章，挨个复习总结一下。
学了这么久的 I/O 性能知识，一说起 I/O 指标，你应该首先会想到分类描述。我们要区分开文件系统和磁盘，分别用不同指标来描述它们的性能。
文件系统 I/O 性能指标
我们先来看文件系统的情况。
首先，最容易想到的是存储空间的使用情况，包括容量、使用量以及剩余空间等。我们通常也称这些为磁盘空间的使用量，因为文件系统的数据最终还是存储在磁盘上。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文介绍了如何快速分析系统I/O瓶颈以及选择性能工具的方法。首先，文章回顾了文件系统和磁盘I/O的性能指标，包括存储空间使用情况、缓存使用情况、文件I/O等，并强调了在不同场景下指标的选择和分析方法。其次，文章介绍了获取这些性能指标的工具，包括df、/proc/meminfo、iostat、pidstat、strace、lsof等，并结合案例详细说明了这些工具的使用方法和分析过程。最后，文章强调了掌握系统工作原理对工具使用的重要性，指出只要理清系统工作原理，工具使用并不难。整体而言，本文通过案例分析和工具介绍，为读者提供了快速了解系统I/O瓶颈分析和性能工具选择的方法，具有很高的实用性。文章通过图表和案例分析，帮助读者快速掌握文件系统和磁盘I/O性能分析的思路，为读者提供了实用的技术指导。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《Linux 性能优化实战》，新⼈⾸单¥68
《Linux 性能优化实战》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(31)
- 最新
- 精选
黄智荣一次io性能问题 数据写es，运行一段时间后，发现写入很慢，查io时发现，读的io很高，写的io很少，很奇怪只写数据还没查询，读的io使用率基本接近100%。 用iotop定位到es一些写的线程，将线程id转成16进制，用jstack打印出es的堆栈信息，查出16进制的线程号的堆栈。发现原来是es会跟据doc id查数据，然后选择更新或新插入。es数据量大时，会占用了很多读的io. 后面写es就不传id，让es自动生成。解决了问题。作者回复: 👍 思路清晰。大家也可以参考分析 es 或者其他类似的问题
2019-01-29488
麋鹿在泛舟老师，如何判断磁盘是在 顺序读 还是 随机读？ --- 可以使用strace把系统调用都找出来，write是否连续就可以看到了.作者回复: 是的，或者使用 blktrace 观察
2019-01-3028
Geek_b04b12我是一名开发者，当初公司刚刚成立，项目上线，那一次版本上线记得使用是更改了表的结构，然后系统在请求一个api以后，系统的top各种指标都达到了峰值，导致了机器直接死掉，重启以后，再请求，仍旧会宕机，当初没有看学习这个课程，然后，就各种百度，google，整体的思路想想和现在差不多，api请求以后，建立的那个进程的占用的内存，io都会很高，根据那个id ，记得使用lsof ，看到系统就一直在频繁的调用一个c语言函数，咨询了 相关的c/c++工程师，然后结合php的语言（业务是用php写的）函数的封装，最后找到了那个php函数，再找到上层自定义函数，然后发现是由于数据库的一个表的列的默认字段设置为了null，导致一个死循环，最终，将这个mysql的表的字段的默认值修改后，发现问题就迎刃而解了。。印象特别的深刻，虽然是开发，但是喜欢linux。。。各种编程语言离不开服务器的底层（linux服务器） 现在系统的学习linux以后，遇到问题就不会那么慌乱无助，现在想想，知其然不知其所以然（以前参加过一个比较基础的linux培训，重点是操作），对以后的职业发展真的不利！ 收益斐然，多谢！作者回复: 谢谢支持，很高兴专栏可以帮到更多的人
2019-08-24224
我来也[D30打卡] 套路了解了. 其实查找其他方面的问题也都是这样啊.一步一步缩小范围. 首先,确定有没有瓶颈产生,或者有哪方面的瓶颈. 其次,看是谁导致的. 再次,是谁操作什么导致的. 最后,结合实际,给出解决方案.作者回复: 是的，都是一样的套路，关键是要知道每一步该怎么做，又为什么这么做。实际上最终的优化还要综合考虑成本和收效。
2019-01-288
vvccoe倪老师，你好。 能详细说明一下IOPS吗？ 1.100 IOPS 是指的一秒内，能处理100次IO请求，这个请求包含了寻道定位数据吗？ 2.一次请求是不是只包含了4K的数据量，如果一次操作是9K 会拆成3次IO请求。作者回复: 1. IOPS就是 I/O per second 的缩写，指的是发送给磁盘的读写请求数（注意这里是系统合并后发给磁盘的） 2. 每次请求的大小不是固定的，所以才会有 IOPS 和吞吐这些不同的指标
2019-01-287- ninuxer打卡day31 满满的套路，一心只想放假，无心上班，还得熬一周😂
作者回复: 趁着有时间正好学习😊
2019-01-285 
lyonger老师好，我想请教一个问题： 很多异常产生时是短时，那么过了以后没有现场可以分析了。比如io utils报警100%，但登陆机器上查看但时候可能已经没有现场，没法查到是哪个进程导致的。而我了解到sar命令可以查历史信息，但是好像sar -d 查磁盘的时候找不到是哪个进程。那么有更好的办法查询历史信息，或者保留现场的方式呢？作者回复: 嗯，是的，所以需要搭建监控系统，把这些历史数据记录下来（参考53、54篇）。
2019-06-253
每天晒白牙【day31打卡】 老师的课程好用心，准备这些案例都会很费时，讲了心法，接下来就是我们自己在工作中的实战了，总之这个课很值。谢谢老师作者回复: 谢谢支持
2019-01-293
hola套路篇总是价值1个亿作者回复: 😊 谢谢
2019-02-232
walker文件系统和磁盘的IOPS，响应时间，吞吐量有什么区别吗作者回复: 中间多了一层文件系统，文件系统也还有一层缓存
2019-02-182
收起评论
