一、性能指标
描述I/O的性能指标有哪些呢？可以回想下文件系统和磁盘I/O的原理，结合下面这张Linux系统的I/O栈图复习下。
二、文件系统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性能的四个核心指标：
- 使用率，是指磁盘忙处理 I/O 请求的百分比。过高的使用率（比如超过 60%）通常意味着磁盘 I/O 存在性能瓶颈。
- IOPS（Input/Output Per Second），是指每秒的 I/O 请求数。
- 吞吐量，是指每秒的 I/O 请求大小。
- 响应时间，是指从发出 I/O 请求到收到响应的间隔时间。
考察这些指标时，一定要注意综合 I/O 的具体场景来分析，比如读写类型（顺序还是随机）、读写比例、读写大小、存储类型（有无 RAID 以及 RAID 级别、本地存储还是网络存储）等。
注意：切忌把不同场景的I/O性能指标，直接进行分析对比。
除了这些指标，缓冲区（Buffer）也是要重点指标，它经常出现在内存和磁盘问题的分析中。
文件系统和磁盘 I/O 的这些指标都很有用，需要熟练掌握。
三、性能工具
掌握文件系统和磁盘 I/O 的性能指标后，还要知道，怎样去获取这些指标，也就是搞明白工具的使用问题。
第一，在文件系统的原理中，查看文件系统容量的工具 df。它既可以查看文件系统数据的空间容量，也可以查看索引节点的容量。至于文件系统缓存，通过 /proc/meminfo、/proc/slabinfo 以及 slabtop 等各种来源，观察页缓存、目录项缓存、索引节点缓存以及具体文件系统的缓存情况。
第二，在磁盘 I/O 的原理中，分别用 iostat 和 pidstat 观察了磁盘和进程的 I/O 情况。它们都是最常用的 I/O 性能分析工具。通过 iostat ，可以得到磁盘的 I/O 使用率、吞吐量、响应时间以及 IOPS 等性能指标；而通过 pidstat ，则可以观察到进程的 I/O 吞吐量以及块设备 I/O 的延迟等。
第三，在狂打日志的案例中，先用 top 查看系统的 CPU 使用情况，发现 iowait 比较高；然后，又用 iostat 发现了磁盘的 I/O 使用率瓶颈，并用 pidstat 找出了大量 I/O 的进程；最后，通过 strace 和 lsof，找出了问题进程正在读写的文件，并最终锁定性能问题的来源——原来是进程在狂打日志。
第四，在磁盘 I/O 延迟的单词热度案例中，同样先用 top、iostat ，发现磁盘有 I/O 瓶颈，并用 pidstat 找出了大量 I/O 的进程。可接下来，想要照搬上次操作的我们失败了。在随后的 strace 命令中，居然没看到 write 系统调用。于是，换了一个思路，用新工具 filetop 和 opensnoop ，从内核中跟踪系统调用，最终找出瓶颈的来源。
最后，在 MySQL 和 Redis 的案例中，同样的思路，先用 top、iostat 以及 pidstat ，确定并找出 I/O 性能问题的瓶颈来源，它们正是 mysqld 和 redis-server。随后，又用 strace+lsof 找出了它们正在读写的文件。
关于 MySQL 案例，根据 mysqld 正在读写的文件路径，再结合 MySQL 数据库引擎的原理，不仅找出了数据库和数据表的名称，还进一步发现了慢查询的问题，最终通过优化索引解决了性能瓶颈。
至于 Redis 案例，根据 redis-server 读写的文件，以及正在进行网络通信的 TCP Socket，再结合 Redis 的工作原理，我们发现 Redis 持久化选项配置有问题；从 TCP Socket 通信的数据中，还发现了客户端的不合理行为。于是，修改 Redis 配置选项，并优化了客户端使用 Redis 的方式，从而减少网络通信次数，解决性能问题。
四、性能指标和工具的联系
从指标和工具两个不同维度出发，整理记忆。
- 从 I/O 指标出发，可以更容易把性能工具同系统工作原理关联起来，对性能问题有宏观的认识和把握。
- 而从性能工具出发，可以更快上手使用工具，迅速找出想观察的性能指标。特别是在工具有限的情况下，更要充分利用好手头的每一个工具，少量工具也要尽力挖掘出大量信息。
第一个维度，从文件系统和磁盘 I/O 的性能指标出发。当你想查看某个性能指标时，要清楚知道，哪些工具可以做到。
根据不同的性能指标，对提供指标的性能工具进行分类和理解。这样，在实际排查性能问题时，你就可以清楚知道，什么工具可以提供你想要的指标，而不是毫无根据地挨个尝试，撞运气。
第二个维度，从工具出发。也就是当你已经安装了某个工具后，要知道这个工具能提供哪些指标。
这在实际环境中，特别是生产环境中也是非常重要的。因为很多情况下，你并没有权限安装新的工具包，只能最大化地利用好系统已有的工具，而这就需要你对它们有足够的了解。
具体到每个工具的使用方法，一般都支持丰富的配置选项。这些配置选项并不用背下来。只要知道有哪些工具，以及这些工具的基本功能是什么就够了。真正要用到的时候， 通过 man 命令，查它们的使用手册就可以了。
五、如何迅速分析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 使用大量升高。这种情况下，你就得进行内存分析了，先找出占用大量内存的进程，再设法减少内存的使用。
