如果您的Linux服务器出现故障,您的第一步通常是在终端中使用top命令来检查平均负载。
但是,有时会top
命令显示非常高的平均负载,即使CPU的us
和CPU的id
的度数比较低也是如此。
如果CPU单核的负载超过1,但CPU显示大约70%空闲。这种情况的常见原因之一是磁盘 I/O瓶颈。
如果在多核心的CPU,单核平均负载的等于top命令顶部的平均负载除以CPU核心数。在下面案例中,就是34.18/24=1.42
。
什么是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缓存、内核日志、访问日志等操作使用最大化。要解决这类问题,是用性能更好的存储设备替换现有的设备。