如何衡量Linux性能，避免最典型的错误：磁盘篇

在本系列中，我们将讨论Linux性能衡量，以及如何正确测量它。 Linux性能是一个非常广泛的主题，因此，我们将重点关注通常会提高系统性能的四个主要资源--CPU，内存，磁盘存储和网络。
就磁盘而言，实际上您需要注意两件事：

• 磁盘空间 –- 这个比较好理解，这就是我们为什么运维同学会设置诸如磁盘使用率超过90%的报警。
• 磁盘的I/O性能。

磁盘空间

我看到很多人不了解大小，文件长度和磁盘使用率之间的差异。因此，在这种情况下，我创建了一个16 GB的测试文件，但是如果您查看du，它仅占用4 KB，因为这是一个稀疏文件，这是一个16 GB的巨大漏洞。

当然，您不太可能在现实世界中看到这种差异，但您可以看到，因为许多系统将稀疏文件用于不同的事物。

例如，在MySQL中，由于使用了某些表压缩，因此所使用的磁盘空间与文件长度之间可能会有很大的差异，而两者之间的差异可能会很大。

I/O 性能

现在，当您谈到磁盘I/O性能观点时，您需要在这里考虑很多事情。

显然，有IOPS--它可以在带宽中做多少。尤其是在连接网络存储或速度较慢的总线时。例如，可以注意到，所有SATA SSD都精确地每秒交付500兆字节，这是因为SSD是如此之快，但是SATA总线在这种情况下却是如此之慢，因此这是极限。

您还需要了解磁盘读取，写入或fsyncs的不同类型的负载，因为我们确实有不同的延迟和负载含义。

此外，当涉及磁盘时，负载并发性通常称为“队列深度”，因为并发性是在达到典型的大吞吐量时系统可以并行处理的请求数量。

因此，有一个典型的错误：“我的Iostat磁盘利用率已达到100％”。当“我的天哪！”时，我已经多次看到这种对100％的恐惧。
现实情况是，您的iostat利用率是指至少有一个I/O请求未完成的时间百分比。在过去的十年或几千年中，对于单个spinning驱动器来说，这也许再一次有意义，但是对于那些我们当时使用的通用存储来说，这确实没有意义。

对于SSD而言，这没有意义，对于RAID而言，这没有意义，对于NAS而言，它也没有意义，对于云存储来说，这没有意义，因为它们非常擅长同时处理多个请求。

性能（至少延迟）不会受到影响。
这里应强调：

1. 分离读写延迟

根据您的系统，读写延迟之间的差异可能非常明显。有些系统实际上具有不同的读取延迟，有些系统具有更好的写入延迟。在这种情况下，我要做的就是将它们的当前延迟与您在过去一段时间在该系统上看到的平均延迟进行比较，这样我就可以相对容易地理解它是异常的。

2. 磁盘负载，也可以是平均磁盘使用量

这意味着同时要处理多少个请求。因为如果您真的要使磁盘饱和，则会发生排队，并且当此事情通常变得很高时，您应该知道期望您的存储能够最佳地处理的确切内容。

问题当然是，如果您考虑使用云存储，您实际上并不知道最佳并发性。他们不会告诉您，这将取决于实现，并且可以随时更改。

3. biolatency：块设备延迟

接下来是biolatency，您可以再次从eBPF获得。您无需仅查看平均延迟，可以查看可以在I/O设备上完成的分布。

eBPF还提供了一些工具，您可以在文件系统级别查看这些工具，这很有趣，因为在该工具上，您还可以查看缓存效率以及其他一些异常值。

因此，这是ext4的工具，也是XFS和其他一些常见文件系统的工具。
PS: 本文属于翻译，原文