30-套路篇：如何迅速分析出系统I/O的瓶颈在哪里？
IO性能指标
文件系统I/O性能指标
- 存储空间的使用情况，包括容量、使用量以及剩余空间等
通常也称这些为磁盘空间的使用量，因为文件系统的数据最终还是存储在磁盘上
注意这只是文件系统向外展示的空间使用，并非磁盘空间的真实用量，因为文件系统的元数据会占用磁盘空间
如果配置RAID，从文件系统看到的使用量跟实际磁盘的占用空间，也会因为RAID级别的不同而不一样
例如配置RAID10后，从文件系统最多也只能看到所有磁盘容量的一半 - 索引节点的使用情况，包括容量、 使用量以及剩余量等
如果文件系统中存储过多的小文件，就可能碰到索引节点容量已满的问题 - 缓存的使用情况，包括页缓存、目录项缓存、索引节点缓存以及各个具体文件系统（ext4、XFS等）的缓存
这些缓存会使用速度更快的内存用来临时存储文件数据或者文件系统的元数据，从而减少访问慢速磁盘的次数 - 文件I/O，包括IOPS（包括r/s和w/s）、响应时间（延迟）以及吞吐量（B/s）等
在考察这类指标时，通常还要考虑实际文件的读写情况
比如结合文件大小、文件数量、I/O类型等，综合分析文件I/O的性能
这些性能指标非常重要，但Linux文件系统并没提供直接查看这些指标的方法
只能通过系统调用、动态跟踪或者基准测试等方法，间接进行观察和评估
不过这些指标在考察磁盘性能时更容易见到，因为Linux为磁盘性能提供了更详细的数据
磁盘I/O性能指标
- 使用率
是指磁盘忙处理I/O请求的百分比。过高的使用率（比如超过 60%）通常意味着磁盘I/O存在性能瓶颈 - IOPS（Input/Output Per Second）
是指每秒的I/O请求数 - 吞吐量
是指每秒的I/O请求大小 - 响应时间
是指从发出I/O请求到收到响应的间隔时间
考察这些指标时，一定要注意综合I/O的具体场景来分析
比如读写类型（顺序还是随机）、读写比例、读写大小、存储类型（有无RAID以及RAID级别、本地存储还是网络 存储）等
小结
这里有个大忌，就是把不同场景的I/O性能指标，直接进行分析对比，这是很常见的一个误区，一定要避免
文件系统和磁盘I/O总结图
性能工具
-
文件系统原理
-
磁盘I/O原理
-
狂打日志案例
-
磁盘I/O延迟的单词热度案例
-
MYSQL的案例
-
redis的案例
性能指标和工具的联系
-
第一个维度，从文件系统和磁盘I/O的性能指标出发
换句话说，当想查看某个性能指标时，要清楚知道，哪些工具可以做到
-
第二个维度，从工具出发
也就是当已经安装了某个工具后，要知道这个工具能提供哪些指标
如何迅速分析I/O的性能瓶颈
有没有什么方法可以又快又准地找出系统的I/O瓶颈呢？
找关联，多种性能指标间都有一定的关联性，不要完全孤立的看待他们
想弄清楚性能指标的关联性，就要通晓每种性能指标的工作原理
- 先用iostat发现磁盘I/O性能瓶颈
- 再借助pidstat ，定位出导致瓶颈的进程
- 随后分析进程的I/O行为
- 最后结合应用程序的原理，分析这些I/O的来源
所以，为了缩小排查范围，通常会先运行那几个支持指标较多的工具，如iostat、 vmstat、pidstat等
然后再根据观察到的现象，结合系统和应用程序的原理，寻找下一步的分析方向
推理图
图中列出了最常用的几个文件系统和磁盘I/O性能分析工具，以及相应的分析流程，箭头则表示分析方向
这其中iostat、vmstat、pidstat是最核心的几个性能工具，它们也提供了最重要的I/O性能指标
例如在前面讲过的MySQL和Redis案例中，就是通过iostat确认磁盘出现I/O性能瓶颈
然后用pidstat找出I/O最大的进程，接着借助strace找出该进程正在读写的文件
最后结合应用程序的原理，找出大量I/O的原因
再如当用iostat发现磁盘有I/O性能瓶颈后，再用pidstat和vmstat检查
可能会发现I/O来自内核线程，如Swap使用大量升高。
这种情况下，就得进行内存分析了，先找出占用大量内存的进程，再设法减少内存的使用
