Understanding Disk I/O

这篇文章是我翻译的第一篇文章有些地方翻译的不是很好见谅:-)，文章来自scout的官方博客(点我)，个人第一次读的时候感觉很赞。文章主要讲了什么呢？

• 磁盘IO是什么？
• 怎么样才能判断你遇到了磁盘I/O的瓶颈？
• 如何解决磁盘IO的瓶颈
• 本文还推荐了scout的一些监控插件

关于scout的介绍

Scout是一个服务器和应用扩展监控服务，它主要关注于安装和配置的易用性。
Scout默认提供了报警功能，帮助管理员更快地在不同负载的情况下理解应用程序的行为，
同样，Scout也允许程序员创建插件来扩展Scout

如果你年纪足够大，那你应该知道软盘驱动器，你应该听说过的磁盘I/O瓶颈的症状。 例如，在俄勒冈小道加载下一个场景，你会听到硬盘磨走，从磁盘读取数据。 CPU就在这段时间处于闲置状态，摆弄它的手指等待数据。如果软盘驱动器是更快，你会现在运行的哥伦比亚河的急流。(直译,我没见过软盘，对这块的理解不是那么深:-) )

如果磁盘不是在你的桌面上,很难察觉的I/O瓶颈。对于Web应用程序，我比较关注四个重要的磁盘I/O问题：

• 你有一个I/O瓶颈？
• 有什么影响I/O性能？
• 什么是解决I/O瓶颈的最佳路径？
• 你如何监视磁盘I/O？

A banana slug vs. an F-18 Hornet

磁盘I / O包含一个物理磁盘上的输入/输出操作。如果你从磁盘上的一个文件中读取数据，处理器需要等待要读取的文件(写文件也是如此)。 磁盘工作时的杀手锏？访问时间。访问时间是为了处理来自处理器的数据请求，然后检索存储装置所需要的数据所需的计算机的时间。 由于硬盘是机械的，你需要等待磁盘转动到所需的磁盘扇区(数据存储的扇区)。 磁盘延迟大约是13ms，由于它依赖于硬盘的质量和旋转速度。内存延迟大约83ns。区别有多大？如果内存是一架最大速度可达1,190mile/h的F-18大黄蜂,那么磁盘访问速度则是只有0.007mile/h的香蕉蛞蝓(感觉像蜗牛,参考上图图片)。

这就是为什么在内存中缓存数据对于性能是如此重要 ------内存和硬盘驱动器之间的延迟的差异是巨大的。

Do you have an I/O bottleneck?

你的I/O等待测量直接反应是否存在I/O瓶颈。I/O等待是处理器正在等待磁盘数据所占的百分比。

举例来说，假设需要1秒内从MySQL读取10000行，这个操作需要对这些行执行某些操作。 

mysql的某一行被检索时，磁盘处于被访问的状态。在此期间，处理器处于闲置状态。它等待在磁盘数据读取。在上面的例子中，磁盘访问了700毫秒，因此I/O等待的70％。

你可以通过top命令来检查你的 iowait ，top命令在任何版本的Linux上的都存在的： 

如果你的I/O wait 百分比大于(1/# of CPU cores,核心数分之一),那么你的CPU花费了大量的时间用于等待磁盘子系统(等待磁盘的读写)。

在上面的输出，I/O等待为12.1%。该服务器有8个内核（通过执行cat /proc/cpuinfo 可以看到)。这是非常接近（1/8 cores=0.125)。如果I/O等待一直处于这个阈值的(1/# of CPU cores,核心数分之一)前后,那么磁盘访问会使程序运行变缓慢。

What impacts I/O performance?

对于一些磁盘随机访问(数据库,邮件服务器,文件服务器等),你应着眼于IOPS(每秒钟执行I/O操作的次数)。

四个主要因素影响的IOPS：

• Multidisk Arrays(多磁盘阵列) - 磁盘阵列磁盘越多意味着IOPS越大。如果一个磁盘的IOPS是 150,那么两个磁盘的IOPS可以达到300。
• Average IOPS per-drive(每个驱动器的平均IOPS) - 每个驱动器可处理的IOPS越大，那么总IOPS的能力就越强。这在很大程度上是由驱动装置的旋转速度决定。
• RAID Factor(RAID 因素) - 你的应用程序可能会使用RAID做存储配置，这意味着你使用多个磁盘来保障可 * “靠性和冗余度。一些RAID配置对写操作有显著的影响。对于RAID6，每一个写请求需要操作6个磁盘。对于RAID1和RAID10，一个写请求，只需要操作2个磁盘。对于一个RAID集，磁盘操作的次数越低，IOPS就越大。本文对RAID和IOPS的性能有很透彻的分析。
• Read and Write Workload(读写工作负载) - 如果你有写操作的比例很高,RAID的配置导致对于每个写请求会执行执行许多次操作(如RAID 5或RAID6)，那么你的IOPS会显著更低。

Calculating your maximum IOPS

一个非常准确的让你设身处地的去了解你机器的最大IOPS到底是有大的方式 就是去计算下你机器的理论IOPS是多大，然后把它同你实际测试到的IOPS进行对比，如果两者接近，那么也会你的IO会有点问题了。  上面的每一项都可以从硬件信息中获取，你需要知道你的读/写负载，当然肯定得需要通过一些软件来实现了。你可以使用类似sar的命令行工具，也可以安装scout的检测插件，以上两种方式都可以获取读/写的负载情况。

一旦，你计算出来机器的理论IOPS，那么和sar命令中的tps 行进行比较，TPS每秒钟物理设备的 I/O 传输总量。sar命令中的tps是你的实际IOPS。如果TPS接近理论的IOPS，那么你的机器还是在承受范围之内的。下图是iostate执行的结果。

What’s the best path to fixing an I/O bottleneck?

即使香蕉蛞蝓听从来自“The 4 Hour Body”的所有建议，它决不会和F-18大黄蜂的速度一样快。同样，你可以调整你的磁盘硬件有更好的表现， 但它的复杂性决定了他永远不会不接近RAM的速度。

如果你现在面临磁盘I/O瓶颈，调整你的硬件可能并不是最快的补救措施。硬件改动可能涉及到的应用程序开发人员和系统管理员之间大量测试，数据迁移和交流。

当我们看到Blue Box Group的I/O瓶颈的时候，我们首先尝试调整该公司使用I/O最多的服务，使该服务尽可能多的数据缓存到ram中。 例如，我们通常配置我们的数据库服务器使其有尽可能多的RAM (高达64 GB,或者更多),然后让MySQL的缓存尽可能多的内存。

How do you monitor disk I/O?

在数据重服务器上的检测磁盘性能是非常重要，通过监控你可以判断随着时间的推移应用程序是如何影响磁盘性能。TOP命令的输出并没有给出太多的上下文：你看到的是正常的吗？还是这仅仅是一个短暂的高峰？怎么我们怎么获取 2个月前的I/O wait信息呢？

scout有两个关键的插件，用于测量你的磁盘性能。

• The CPU usage plugin monitors key CPU metrics, which include I/O Wait %
• The Device Input/Output plugin provides additional I/O metrics for a given device, including the I/O Wait time in milliseconds and read/write throughput

Three takeaways

• Disk access is slooowww(磁盘访问毕竟是慢的) – 磁盘的访问速度是无法接近RAM的访问速度的.
• Optimize your apps first(首先对你的app进行调优)– 调优磁盘的硬件是无价值的或者说并不是一个最快的修复方式.你应该让你的app中重I/O的服务尽可能从ram缓存中获取更多的数据。
• Measure(测量或者检测) – 对你app代码的休克可能对磁盘I/O造成很大的影响,记录一段时间内关键的I/O指标.