磁盘I/O瓶颈的解决方法

如果您的Linux服务器出现故障，您的第一步通常是在终端中使用top命令来检查平均负载。

但是，有时会top命令显示非常高的平均负载，即使CPU的us和CPU的id的度数比较低也是如此。

如果CPU单核的负载超过1，但CPU显示大约70%空闲。这种情况的常见原因之一是磁盘 I/O瓶颈。

什么是I/O等待瓶颈

存储I/O是物理磁盘或其他存储，例如磁盘或SSD。输入/输出（或写入/读取）的操作。

如果CPU需要在磁盘上等待读取或写入数据，则涉及磁盘I/O的请求会显着变慢。I/O Wait是CPU必须等待存储设备的时间百分比。

在Linux服务器可以使用一些终端命令行工具，例如top、atop和iotop来确认磁盘I/O是否正在降低应用程序性能。

top 命令平均负载与等待时间wa

当您运行top命令，您将首先浏览右上角检查平均负载。在这种情况下，它非常高。

接下来，我们很可能会浏览顶部附近的CPU和内存，然后是%CPU和%MEM列，以了解哪些进程使用的资源最多。

在top，您还需要查看wa，它几乎一直是0.0%。值始终高于1%可能表示您的存储设备速度太慢，无法跟上IO的请求。

值得注意的是，top命令顶部%Cpu(s)行的wa是多个核心wa的平均值，可以按1键来展开视图，查看每个CPU核心wa值。

完成此操作后，我们看到某些CPU内核的%wa时间高达 60%。所以我们知道有一个主要的瓶颈，接下来我们来确认一下这个磁盘瓶颈。

atop 命令监控DSK(存储)I/O 统计信息

接下来，使用atop，我们看到存储设备DSK行的busy的值在90%到100%。这是一个严重的瓶颈。在Web服务导致结果就是HTTP请求被阻塞，直到磁盘I/O可以赶上。

在atop，按d键盘查看正在使用磁盘I/O的进程。这里我们看到MySQL、Nginx、PHP-FPM，这些都是web服务核心进程。

要降低web服务磁盘IO，可以考虑将Nginx或Apache、MySQL和PHP-FPM的访问日志和错误日志不要过于频繁地写入磁盘。

并且避免将缓存（例如Nginx 缓存）存储在磁盘。高并发流量环境。除了LEMP服务之外。

还要注意flush-8:0（一个PHP缓存问题）和jbd2/sda5-8（跟踪到访问/内核日志）及其进程。

此时，如果可以，你应该在Linux服务器上执行一个快速SSD基准测试，以了解磁盘IO的速度。

运行命令dd if=/dev/zero of=diskbench bs=1M count=1024 conv=fdatasync。

dd if=/dev/zero of=diskbench bs=1M count=1024 conv=fdatasync

1073741824 bytes (1.1 GB) copied, 46.0156 s, 23.3 MB/s

尽管可以减少读/写，但磁盘I/O非常慢。如果MySQL的my.cnf的max_connections设置太高。

就会导致MySQL连接和查询堆积并增长到超出可用服务器RAM的范围。它就会发展到Linux内核OOM杀死MySQL的地步。

通常MySQL最大的连接数等于最大分配内存除以每个线程缓冲区的大小。

iotop 命令实时监控磁盘读/写

iotop命令监控Linux内核输出的I/O使用信息。它显示系统进程或线程的当前I/O使用情况，运行命令iotop -oPa。

iotop -oPa

iotop命令-o选项仅显示正在执行I/O的进程或线程，而不是显示所有进程或线程。这可以通过按o键 动态切换。

-P选项仅显示进程。通常iotop命令显示所有线程。-a选项显示累积的I/O而不是带宽。

在这种模式下，iotop命令显示自iotop命令启动以来完成的I/O进程的数量。

查看DISK WRITE列，这些数字不是很大。合理平均速度的存储设备不会忙于一些内核日志记录和磁盘缓存。

但是在低于25 MB/s的写入速度时，磁盘IO就会被Nginx缓存、内核日志、访问日志等操作使用最大化。要解决这类问题，是用性能更好的存储设备替换现有的设备。