如果您的 Linux 服务器变慢，您的第一步通常可能是在终端中使用 top 命令来检查平均负载。 然而，有时即使 CPU“us”（用户）百分比较低且 CPU“id”（空闲）百分比较高，top 也会显示非常高的平均负载。

下面示例中就是这种情况； 在具有 24 个核心的服务器上，平均负载高于 30，但 CPU 显示大约 70% 空闲。 造成这种情况的常见原因之一是磁盘 I/O 瓶颈。

1. 什么是 I/O 等待瓶颈？

存储 I/O 是物理磁盘（或其他存储，例如磁盘或 SSD）上的输入/输出（或写/读）操作。 如果 CPU 需要等待磁盘读取或写入数据，则涉及磁盘 I/O 的请求可能会显着减慢。 I/O 等待是 CPU 必须等待存储的时间百分比。

让我们看看如何通过在安装了lemp的Web服务器上使用一些终端命令行工具（top、atop和iotop）来确认磁盘I/O是否正在降低应用程序性能。

2. 使用 TOP 命令 – 负载平均值和 wa（等待时间）

根据示例所示，当您输入 top 时，您将首先浏览右上角以检查平均负载。 在这种情况下，它非常高，因此表明请求堆积。 接下来，我们很可能会浏览顶部附近的 CPU 和 mem 水平线，然后是 %CPU 和 %MEM 列，以了解哪些进程使用最多的资源。

在顶部时，您还需要查看“wa”（参见上面的示例）； 它几乎始终应该是 0.0%。 值始终高于 1% 可能表明您的存储设备速度太慢，无法跟上传入请求。 请注意，示例中初始值的平均等待时间约为 6%。

然而，这是 24 个核心的平均值，其中一些核心未激活，因为 CPU 核心未接近容量。 因此，我们应该通过按键盘上的“1”来扩展视图，以查看每个 CPU 核心在使用时的“wa”时间。 根据上面的屏幕截图，有 24 个核心，从 0 到 23。

完成此操作后，我们发现某些 CPU 核心的“%wa”时间高达 60%！ 所以我们知道存在一个瓶颈，而且是一个主要瓶颈。 接下来我们来确认一下这个磁盘瓶颈。

3. 使用 ATOP 命令监控 DSK（存储）I/O 统计信息

使用 atop, next，我们看到存储设备处于 90% 到 100% 的繁忙状态。 这是一个严重的瓶颈。 其结果是请求被阻塞，直到磁盘 I/O 能够跟上。 在顶部时，按“d”查看正在使用磁盘 I/O 的进程和 PID。

这里我们看到MySQL、Nginx和PHP-FPM，这些都是必要的进程，我还得再写一篇关于在高流量的L*MP服务器上减少磁盘I/O的文章。 简而言之，请注意 Nginx（或 Apache）、MySQL 和 PHP-FPM 的访问和错误日志未设置为过于频繁地写入磁盘，并且您还希望避免将缓存（例如 Nginx 缓存）以非常频繁的方式存储到磁盘。 高并发流量环境。

除了 LEMP 服务之外，还要注意“flush-8:0”（PHP 缓存问题）和 jbd2/sda5-8（跟踪访问/内核日志）及其 PID。

在这台服务器上，我在停止服务后执行了快速 SSD 基准测试，发现磁盘性能非常糟糕。 结果：复制了 1073741824 字节 (1.1 GB)，46.0156 秒，23.3 MB/秒。 因此，虽然可以减少读/写次数，但这里的问题是磁盘 I/O 速度极慢。

该客户的网络主机提供商否认了这一点，并表示 MySQL 是问题所在，因为它的大小经常增长并遭受 OOM 杀死。 相反，MySQL 内存使用量的增长是磁盘 I/O 阻塞 MySQL 查询及时返回的症状，并且该服务器上 MySQL 的 my.cnf max_connections 设置太高（2000），这也意味着 MySQL 的连接和查询会堆积起来，并远远超出所有服务可用的服务器 RAM。

它已经发展到 Linux 内核 OOM 杀死 MySQL 的地步。 考虑到 MySQL 的最大分配内存等于每个线程缓冲区的大小乘以“max_connections=2000”设置，这也使得 PHP-FPM 几乎没有可用内存，因为它堆积了在 MySQL < 磁盘上等待的连接。 但由于 MySQL 是最大的进程，Linux 内核选择首先杀死 MySQL。

4. 使用 IOTOP 命令实时了解磁盘读/写情况

iotop 监视 Linux 内核输出的 I/O 使用信息。 它显示系统上进程或线程当前 I/O 使用情况。 我使用命令：iotop -oPa。 以下是这些选项的解释。 -o, –only （仅显示执行 I/O 的进程或线程，而不显示所有进程或线程。

这可以通过按 o 动态切换。） -P, –processes （仅显示进程。通常 iotop 显示所有线程。） -a, –accumulated （显示累积 I/O 而不是带宽。在此模式下，iotop 显示数量 自 iotop 启动以来已完成 的 I/O 进程。）

查看“磁盘写入”栏； 这些数字并不是很大。 按照它们增加的速率，相当平均速度的存储设备不会忙于某些内核日志记录和磁盘缓存。 但在< 25 MB/s 的写入速度（以及过度使用内存）下，磁盘 IO 因 Nginx 缓存、内核日志、访问日志等的常规磁盘使用而达到最大。解决方法是用性能更好的存储替换存储写入速度比 SD 卡更快的设备。

当然，MySQL 决不应该允许建立超出服务器服务能力的连接。 此外，通过降低 PHP-FPM 的 pm.max_children 来限制传入流量的解决方法应该避免或只是暂时的，因为这意味着拒绝 Web 流量（基本上是移动瓶颈的位置）。

值得庆幸的是，上述存储设备如此缓慢的情况对于大多数托管提供商来说并不常见。 如果您的磁盘具有平均 I/O，您还可以使用 Varnish 缓存或其他缓存方法，但这些方法只能在完全启动时充当屏蔽。 如果您有足够的服务器内存，请始终首先将所有内容存储在那里。