测量和优化 I/O 性能

原文

衡量和优化 IO 性能有点像一门魔法：工具在那里，资源和讨论很多，但也非常容易迷失在森林中。 我从最近的经历说起。 在文件系统优化、RAID 调整甚至应用程序级别的更改方面经历了多次错误的启动之后，它确实有助于最终退后一步并重新审视基础知识。 后来出现了许多手册页和讨论线程，出现了一些有用的认识：iostat 是你最好的朋友，但它也可能具有令人难以置信的欺骗性； 刷新你对磁盘延迟的记忆将大有帮助； 磁盘和文件系统很快，但没有那么快。

Monitoring IO Performance with iostat

如果怀疑 IO 性能，iostat 是你最好的朋友。 话虽如此，手册页是晦涩的，所以如果你发现自己正在阅读源代码，请不要感到惊讶。 首先，确定有问题的设备并开始监控过程：

# -k output rates in kB
# -x output extended stats
# -d monitoring single device
# sample stats every 5 seconds for device /dev/sdh
$ iostat -dxk /dev/sdi 5

接下来，给自己分配几个小时来理解输出，或者期望很快发现自己走错路（到那里打个卡）。 iostat 是数据库人群中的一种流行工具，因此你会发现很多很好的讨论记录了使用情况，这并不奇怪。 根据你的应用程序，你将需要关注不同的指标，但作为一个优雅的介绍，让我们来看看 await、svctime 和 avgque：

• await - 向设备发出的 I/O 请求的平均时间（以毫秒为单位）。 这包括队列中的请求所花费的时间以及为它们提供服务所花费的时间。
• svctime - 向设备发出的 I/O 请求的平均服务时间（以毫秒为单位）。
• avgqu-sz - 发送到设备的请求的平均队列长度。

首先，await 是一个具有欺骗性的指标！ 尽管它声称测量平均时间，但最好将其理解为聚合函数，所以不要被它误导：avgqu-sz * svctm / (%util/100)。 理想情况下，await 应该大致等于你的 svctime，这导致我们得出一个推论：你的平均队列大小理想地徘徊在个位数左右。 仅了解这些变量就可以告诉你生成负载的应用程序的数量。

Disk Latencies Refresher & EBS Performance

磁盘访问时间是通过几个变量的总和来确定的：启动、寻道、旋转延迟和传输时间。假设你的磁盘没有处于休眠状态，我们可以减少旋转时间，这给我们留下了寻道（磁盘臂找到轨道的时间：~10 毫秒）、旋转延迟（在磁头下方获得正确扇区的时间：取决于 RPM）和实际传输时间。因此，在最坏的情况下，我们将花费约 10 毫秒的时间来寻找，60 秒/7200 转/分钟的旋转延迟约 = 8 毫秒，加上读取时间。平均而言，对于 7.2k RPM 磁盘，这意味着读取第一个字节大约需要大约 5 毫秒的访问时间（最坏情况下大约为 20 毫秒）！

有了这些知识，我们现在可以将 Amazon 的 EBS 性能放在上下文中：平均而言，我们的 EBS 挂载显示 10~30 毫秒的 svctime，所有考虑的事情对于 SAN 来说都不算离谱。这个数字在晚上和周末也会下降到低个位数，这表明与任何共享资源一样，EBS 的性能在白天会下降。话虽如此，基于一天中的时间的 6 倍性能差异绝对不容小觑，所以让我们希望亚马逊能够做到这一点！

平均队列大小 (avgqu-sz) 是 DBA 圈子中的一个流行指标，但在 SAN 或任何多轴设备上运行时一定要小心。理想情况下，单个磁盘的队列大小 (avgqu-sz) 应该是个位数，这意味着底层设备与应用程序生成的 IO 负载很好地匹配。相反，如果队列大小人为地小，你的应用程序代码可能会从一些调整中受益：减少磁盘刷新，考虑缓存或缓冲，或者换句话说，再次确认“IO 是瓶颈”的假设是对的吗！

Disks, Filesystems and Facebook Case Study: Haystack

我们磁盘上的平均访问时间对 IOP 的数量设置了一些硬限制——平均为 5 毫秒，我们得到了非常乐观的 200 req/s，没有读取时间。因此，如果你试图每秒存储数百个文件，你可能需要重新访问架构或认真考虑切换到 SSD！像 MySQL 这样的数据库通过最小化文件句柄的数量、缓存数据和使用积极的缓冲技术来解决这个限制。愿意使用 InnoDB 丢失一些数据吗？将flush_log_at_trx_commit 设置为2 以避免在每个事务上刷新，以支持周期性的一秒刷新。以类似的方式，你可以调整 MyISAM 密钥缓冲区，甚至将索引和数据文件放在不同的驱动器上。

Facebook 团队最近发布了他们的 Haystack 照片存储系统的详细信息，该系统是解决 IO 瓶颈的一个很好的案例研究：截至 09 年 4 月，超过 15PB 的照片存储和每秒上传约 360 张新照片。为了满足要求，他们放弃了 POSIX 文件系统语义，并采用了一个带有单独的内存索引的仅附加结构，用于存储每张照片的直接 inode 偏移量。结果，每张照片访问都被转化为一个单一的 IO 请求——一个巨大的胜利。通读它，引人入胜的内容和优化 IO 的说明性示例。