如果您的Linux服务器出现故障，您的第一步通常是在终端中使用top命令来检查平均负载。
但是，有时会top命令显示非常高的平均负载，即使CPU的us和CPU的id的度数比较低也是如此。
如果CPU单核的负载超过1，但CPU显示大约70%空闲。这种情况的常见原因之一是磁盘I/O瓶颈。
存储I/O是物理磁盘或其他存储，例如磁盘或SSD。输入/输出（或写入/读取）的操作。
在Linux服务器可以使用一些终端命令行工具，例如top、atop和iotop来确认磁盘I/O是否正在降低应用程序性能。
当您运行top命令，您将首先浏览右上角检查平均负载。在这种情况下，它非常高。
接下来，我们很可能会浏览顶部附近的CPU和内存，然后是%CPU和%MEM列，以了解哪些进程使用的资源最多。
在top，您还需要查看wa，它几乎一直是0.0%。值始终高于1%可能表示您的存储设备速度太慢，无法跟上IO的请求。
值得注意的是，top命令顶部%Cpu(s)行的wa是多个核心wa的平均值，可以按1键来展开视图，查看每个CPU核心wa值。
接下来，使用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的速度。
运行命令ddif=/dev/zeroof=diskbenchbs=1Mcount=1024conv=fdatasync。
ddif=/dev/zeroof=diskbenchbs=1Mcount=1024conv=fdatasync1073741824bytes(1.1GB)copied,46.0156s,23.3MB/s尽管可以减少读/写，但磁盘I/O非常慢。如果MySQL的my.cnf的max_connections设置太高。
就会导致MySQL连接和查询堆积并增长到超出可用服务器RAM的范围。它就会发展到Linux内核OOM杀死MySQL的地步。
通常MySQL最大的连接数等于最大分配内存除以每个线程缓冲区的大小。
iotop命令监控Linux内核输出的I/O使用信息。它显示系统进程或线程的当前I/O使用情况，运行命令iotop-oPa。
iotop-oPaiotop命令-o选项仅显示正在执行I/O的进程或线程，而不是显示所有进程或线程。这可以通过按o键动态切换。
-P选项仅显示进程。通常iotop命令显示所有线程。-a选项显示累积的I/O而不是带宽。
在这种模式下，iotop命令显示自iotop命令启动以来完成的I/O进程的数量。
查看DISKWRITE列，这些数字不是很大。合理平均速度的存储设备不会忙于一些内核日志记录和磁盘缓存。
但是在低于25MB/s的写入速度时，磁盘IO就会被Nginx缓存、内核日志、访问日志等操作使用最大化。要解决这类问题，是用性能更好的存储设备替换现有的设备。