如何分析Linux io wait 问题

本文介绍了Linux系统中高IO等待的原因及解决方法。通过top命令可以查看CPU资源占用情况,iostat命令帮助确定具体磁盘负载,而iotop则能找出导致高IO等待的进程。此外还介绍了如何使用lsof命令找到引起IO等待的文件。

Linux high IOwait is a common Linux performance issue. Today we will look at what iowait means and what contributes to this problem. Hope this can give you more ideas about high IOwait issue.

What is IOwait?

IO wait is related to the CPU resource on the server.

The iowait column on top command output shows the percentage of time that the processor was waiting for I/O to complete. It indicates that the system is waiting on disk or network IO. Because the system is waiting on those resources, it can not fully utilize the CPU.

Learn more about what IOwait here.

I/O Wait is a problem that requires the use of advanced tools to debug, and of course there are many advanced uses of the basic tools.

Determine if an I/O problem is causing the system to slow

Verify that the system is slow due to I/O we can use multiple commands, but the simplest is the UNIX command top.


[[email protected] ~]# top
top - 15:19:26 up  6:10,  4 users,  load average: 0.00, 0.01, 0.05
Tasks: 147 total,   1 running, 146 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.3 sy,  0.0 ni, 99.7 id,  96.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :   999936 total,   121588 free,   328672 used,   549676 buff/cache
KiB Swap:  2097148 total,  2095792 free,     1356 used.   450460 avail Mem 

From the CPU line we can see the percentage of CPU wasted on I/O wait; the higher the number, the more CPU resources are waiting for I/O permissions

wa -- iowait
 AmountoftimetheCPUhasbeenwaitingfor I/O to complete.

check this post to understand CPU Usage us sy wa hi in Linux Top

Find which disk is being written

The top command above explains I/O wait from a whole, but does not indicate which disk is affected, and to know which disk is causing the problem, we use another command Iostat command. Check this post Troubleshooting Disk Issues In Linux for more.

[[email protected] ~]# iostat -x 2 5
Linux 3.10.0-514.el7.x86_64 (localhost.localdomain)     2017年03月03日     _x86_64_    (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.34    0.00    0.31    0.01    0.00   99.33

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.05    1.16    0.17    39.00    17.38    84.60     0.00    2.17    0.87   11.14   0.65   111.41
scd0              0.00     0.00    0.00    0.00     0.00     0.00     8.00     0.00    0.64    0.64    0.00   0.64   0.00
dm-0              0.00     0.00    1.10    0.20    37.85    17.21    84.71     0.00    2.43    0.90   10.88   0.66   0.09
dm-1              0.00     0.00    0.01    0.02     0.07     0.08     9.70     0.00    1.42    0.27    2.05   0.09   0.00

In the example above, Iostat will be updated every 2 seconds, printing 5 times of information, and-X’s option is to print out the extended information

The first Iostat report prints the statistics after the last boot of the system, which means that in most cases the first printed information should be ignored, and the remaining reports are based on the time of the previous interval. For example, this command will be printed 5 times, the second report is a statistic from the first report, the third time is based on the second, and so on

In the above example, the%utilized of SDA is 111.41%, which is a good indication that a process is being written to the SDA disk.

In addition to%utilized, we can get richer resources from iostat, such as read/write requests per millisecond (rrqm/s & wrqm/s)), read and write per second (r/s & w/s), and of course more. In the example above, our project seems to be reading and writing very much information. This is very useful for us to find the appropriate process.

Find processes that cause high I/O wait

[[email protected] ~]# iotop

Total DISK READ :    0.00 B/s | Total DISK WRITE :       0.00 B/s
Actual DISK READ:    0.00 B/s | Actual DISK WRITE:       0.00 B/s
   TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND   
  1028 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % sshd

The simplest way to find the culprit is to use Linux Iotop to check disk IO usage Per process , by looking at iotop statistics, we can easily guide sshd as the culprit

Although Iotop is a very powerful tool and is easy to use, it is not installed by default on all Linux operating systems.

Find which file caused the i/owait

The lsof command can show all the files that a process opens, or all the processes that open a file. From this list, we can find out exactly what files are written, depending on the size of the file and the specific data of the IO file in/proc

We can use the-p method to reduce the output, PID is the specific process

[[email protected] ~]# lsof -p 1028
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF    NODE NAME
sshd    1028 root  cwd    DIR  253,0      233      64 /
sshd    1028 root  rtd    DIR  253,0      233      64 /
sshd    1028 root  txt    REG  253,0   819640 2393730 /usr/sbin/sshd
sshd    1028 root  mem    REG  253,0    61752  180464 /usr/lib64/libnss_files-2.17.so
sshd    1028 root  mem    REG  253,0    43928  180476 /usr/lib64/librt-2.17.so
sshd    1028 root  mem    REG  253,0    15688  269136 /usr/lib64/libkeyutils.so.1.5
sshd    1028 root  mem    REG  253,0    62744  482870 /usr/lib64/libkrb5support.so.0.1
sshd    1028 root  mem    REG  253,0    11384  180425 /usr/lib64/libfreebl3.so
sshd    1028 root  mem    REG  253,0   143352  180472 /usr/lib64/libpthread-2.17.so
sshd    1028 root  mem    REG  253,0   251784  202440 /usr/lib64/libnspr4.so
sshd    1028 root  mem    REG  253,0    20016  202441 /usr/lib64/libplc4.so
sshd    1028 root  mem    REG  253,0    15768  202442 /usr/lib64/libplds4.so
sshd    1028 root  mem    REG  253,0   182056  202443 /usr/lib64/libnssutil3.so
sshd    1028 root  mem    REG  253,0  1220240  650074 /usr/lib64/libnss3.so
sshd    1028 root  mem    REG  253,0   164048  650076 /usr/lib64/libsmime3.so
sshd    1028 root  mem    REG  253,0   276752  650077 /usr/lib64/libssl3.so
sshd    1028 root  mem    REG  253,0   121296  269112 /usr/lib64/libsasl2.so.3.0.0
sshd    1028 root  mem    REG  253,0   398264  202404 /usr/lib64/libpcre.so.1.2.0
sshd    1028 root  mem    REG  253,0  2116736  180446 /usr/lib64/libc-2.17.so
sshd    1028 root  mem    REG  253,0    15848  202439 /usr/lib64/libcom_err.so.2.1
sshd    1028 root  mem    REG  253,0   202568  482862 /usr/lib64/libk5crypto.so.3.1
sshd    1028 root  mem    REG  253,0   959008  482868 /usr/lib64/libkrb5.so.3.3
sshd    1028 root  mem    REG  253,0   324888  482858 /usr/lib64/libgssapi_krb5.so.2.2
sshd    1028 root  mem    REG  253,0   110632  180474 /usr/lib64/libresolv-2.17.so
sshd    1028 root  mem    REG  253,0    40640  180450 /usr/lib64/libcrypt-2.17.so
sshd    1028 root  mem    REG  253,0   113152  180456 /usr/lib64/libnsl-2.17.so
sshd    1028 root  mem    REG  253,0    90664  202424 /usr/lib64/libz.so.1.2.7
sshd    1028 root  mem    REG  253,0    14432  186432 /usr/lib64/libutil-2.17.so
sshd    1028 root  mem    REG  253,0    61872  766946 /usr/lib64/liblber-2.4.so.2.10.3
sshd    1028 root  mem    REG  253,0   344280  766948 /usr/lib64/libldap-2.4.so.2.10.3
sshd    1028 root  mem    REG  253,0    19344  180452 /usr/lib64/libdl-2.17.so
sshd    1028 root  mem    REG  253,0  2025472  482880 /usr/lib64/libcrypto.so.1.0.1e
sshd    1028 root  mem    REG  253,0    23968  202508 /usr/lib64/libcap-ng.so.0.0.0
sshd    1028 root  mem    REG  253,0   155744  202421 /usr/lib64/libselinux.so.1
sshd    1028 root  mem    REG  253,0    61672  539049 /usr/lib64/libpam.so.0.83.1
sshd    1028 root  mem    REG  253,0   122936  202512 /usr/lib64/libaudit.so.1.0.0
sshd    1028 root  mem    REG  253,0    42520  298848 /usr/lib64/libwrap.so.0.7.6
sshd    1028 root  mem    REG  253,0    11328  568388 /usr/lib64/libfipscheck.so.1.2.1
sshd    1028 root  mem    REG  253,0   155064  180439 /usr/lib64/ld-2.17.so
sshd    1028 root    0u   CHR    1,3      0t0    5930 /dev/null
sshd    1028 root    1u   CHR    1,3      0t0    5930 /dev/null
sshd    1028 root    2u   CHR    1,3      0t0    5930 /dev/null
sshd    1028 root    3u  IPv4  21185      0t0     TCP *:ssh (LISTEN)
sshd    1028 root    4u  IPv6  21194      0t0     TCP *:ssh (LISTEN)

In order to further confirm that these files are read and written frequently, we can view them with the following command

[[email protected] ~] # df / tmp
File system 1K-block used available used% mount point
/ dev / mapper / cl-root 17811456 3981928 13829528 23% /

From the results of the above command, we can determine that/tmp is the root of our environment’s logical disk

[[email protected] ~]# pvdisplay
  --- Physical volume ---
  PV Name               /dev/sda2
  VG Name               cl
  PV Size               19.00 GiB / not usable 3.00 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              4863
  Free PE               0
  Allocated PE          4863
  PV UUID               4QfaOy-DNSO-niK1-ayn2-K6AY-WZMy-9Nd2It

Over Pvdisplay we can see that/dev/sda2 is actually the specific disk we used to create the logical disk. With the above information we can safely say that the result of lsof is the file we are looking for

Reference:

Troubleshooting high iowait linux

Sort Disk Read Write in Linux Iotop Command

Debugging High CPU Utilization For a Process on Linux

How to Check Disk usage Disk utilization on Linux

What is High IOwait on Linux

Using Linux Iotop to check disk IO usage Per process

How to Check if a Disk is Busy in Linux

Troubleshooting Disk Issues In Linux

<think>首先,用户的问题是:“请问Linux系统中iowait过高如何解决”。这是一个关于Linux系统性能问题的查询,特别关注iowait过高的情况。 根据系统级指令: - 所有行内数学表达式必须使用$...$格式。 - 独立公式必须使用$$...$$格式并单独成段。 - LaTeX语法正确。 - 使用中文回答。 - 生成相关问题。 - 回答中引用的段落末尾自然地添加引用标识。 - 回答结构清晰,帮助用户逐步解决问题,保证回答真实可靠。 用户提供了几个引用,这些引用是关于iowait的: - 引用[1]: iowait 是系统上未完成的磁盘I/O请求的时间百分比。高值可能表示磁盘I/O瓶颈,但也可能受CPU、内存等因素影响。 - 引用[2]: 每天收到磁盘iowait告警,尤其是在日志服务器上进行大量读写操作,导致系统崩溃边缘。需要查找原因和优化点。 - 引用[3]: 从Cpu一行可以看到浪费在I/O Wait上的CPU百分比;数字越高,说明越多的CPU资源在等待I/O权限。 - 引用[4]: Linux系统磁盘IO过高排查总结,涉及Mysql服务器磁盘IO高。 - 引用[5]: mysql iowait高,iowait过高问题的查找及解决。 用户意图是了解或解决与系统I/O等待相关的问题。所以,我需要构建一个结构化的回答,帮助用户解决iowait过高的问题。 回答结构: 1. **理解iowait**:先解释什么是iowait,为什么它重要。 2. **排查步骤**:提供逐步的排查方法,包括工具和命令。 3. **常见原因**:列出导致iowait过高的常见原因。 4. **解决方案**:针对不同原因,给出解决方案。 5. **优化建议**:提供一般性的优化建议。 6. **生成相关问题**:在回答末尾添加相关问题。 在回答中,自然地添加引用标识。例如,当引用[1]时,在末尾添加[^1]。 确保使用中文。 现在,梳理关键点: - **iowait定义**:iowait 是CPU在等待I/O操作完成时处于空闲状态的时间百分比。高iowait表示系统在I/O上花费了大量时间,可能导致性能瓶颈。 - **工具**:使用如top, iostat, iotop, vmstat, sar等工具来监控和分析。 - **常见原因**: - 磁盘I/O瓶颈:磁盘速度慢或负载高。 - 内存不足:导致频繁的swap操作。 - 高I/O应用:如数据库、日志服务。 - 配置问题:如文件系统设置、调度算法。 - **解决方案**: - 识别高I/O进程:使用iotop或pidstat。 - 优化磁盘:使用SSD、RAID配置。 - 优化应用:如调整数据库配置。 - 增加内存:减少swap使用。 - 调整内核参数:如I/O调度器。 生成相关问题: - 基于主题,如:如何监控iowaitiowait与CPU使用率的关系?特定应用如MySQL的iowait优化? 回答大纲: 1. 介绍iowait及其重要性。 2. 逐步排查方法: - 监控整体系统状态。 - 识别高I/O进程。 - 检查磁盘性能。 - 分析内存使用。 - 检查应用配置。 3. 具体解决方案。 4. 总结。 5. 相关问题。 在回答中,引用用户提供的引用: - 当解释iowait时,引用[1]。 - 当提到告警和日志服务器时,引用[2]。 - 当讨论CPU等待时,引用[3]。 - 当涉及MySQL时,引用[4]和[5]。 确保回答真实可靠:基于Linux系统管理的标准知识。</think>### Linux系统中iowait过高的解决方案 iowait(I/O等待)是CPU在等待磁盘I/O操作完成时处于空闲状态的时间百分比,通常通过`top`或`iostat`命令查看。高iowait值(如超过20%)可能表示系统存在I/O瓶颈,导致性能下降甚至系统崩溃[^1]。常见原因包括磁盘速度不足、内存不足引发频繁swap、高I/O应用(如数据库或日志服务)配置不当等[^2][^4]。解决iowait过高需要系统性排查和优化。下面我将逐步指导您完成问题诊断和解决,确保过程清晰可靠。 #### 步骤1: 理解iowait并初步监控 iowait高并不总是磁盘问题,它可能受CPU处理能力、内存资源或应用负载的综合影响[^1]。首先,使用基础工具确认问题: - 运行 `top` 命令,查看CPU行中的 `wa` 值(即iowait百分比)。例如: ```bash top - 10:00:01 up 1 day, 1 user, load average: 5.2, 4.8, 4.5 %Cpu(s): 10.0 us, 5.0 sy, 0.0 ni, 70.0 id, 15.0 wa, 0.0 hi, 0.0 si, 0.0 st ``` 这里 `wa=15.0%` 表示iowait较高。如果此值持续偏高,说明系统在等待I/O[^3]。 - 使用 `vmstat 1 5` 命令(每秒采样一次,共5次),关注 `wa` 列和 `swap` 列。高 `wa` 伴随高 `si`(swap-in)或 `so`(swap-out)可能表示内存不足[^4]。 **关键点**:iowait高时,系统资源浪费在等待I/O权限上,需进一步定位源头[^3]。 #### 步骤2: 识别高I/O进程和磁盘 高iowait通常由特定进程或磁盘引起。使用以下工具深入分析: - **查找高I/O进程**:运行 `iotop`(需安装,`sudo apt-get install iotop` 或 `sudo yum install iotop`)。命令输出显示每个进程的磁盘读写速率,例如: ```bash sudo iotop -oP TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 1028 be/4 root 0.00 B/s 0.00 B/s 0.00 % 15.00 % mysqld ``` 这里 `IO>` 列高的进程(如MySQL)可能是罪魁祸首[^5]。如果 `iotop` 不可用,使用 `pidstat -d 1` 替代。 - **检查磁盘性能**:运行 `iostat -dxk 1 5`,关注 `%util`(磁盘利用率)和 `await`(I/O平均等待时间)。例如: ```bash Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await %util sda 0.00 5.00 80.0 20.0 3200.0 800.0 50.00 10.00 100.00 90.00 ``` 如果 `%util > 70%` 且 `await` 高,说明磁盘过载,可能是慢速磁盘或RAID配置不当[^4]。 **常见原因**:日志服务器或数据库(如MySQL)的频繁读写是典型诱因,尤其在大量日志操作时[^2][^4]。 #### 步骤3: 分析系统资源瓶颈 iowait高可能源于内存或CPU问题: - **内存检查**:运行 `free -m` 查看内存使用。如果 `Swap` 使用率高(如 >10%),说明内存不足引发swap,间接推高iowait。优化方法: - 增加物理内存。 - 调整应用配置以减少内存需求(如MySQL的 `innodb_buffer_pool_size`)。 - **CPU和负载监控**:使用 `sar -u 1 5` 查看CPU使用率分布。高iowait伴随高 `%system` 可能表示内核处理I/O的CPU开销大。 #### 步骤4: 针对原因实施解决方案 根据排查结果,选择优化措施: - **优化高I/O应用**: - 如果是数据库(如MySQL),调整配置:增加 `innodb_io_capacity`、启用 `innodb_flush_log_at_trx_commit=2` 以减少磁盘写入频率[^5]。参考慢查询日志优化SQL语句。 - 如果是日志服务(如syslog或journald),限制日志大小:编辑 `/etc/systemd/journald.conf`,设置 `SystemMaxUse=500M`,或使用 `logrotate` 定期归档日志[^2]。 - **提升磁盘性能**: - 升级硬件:使用SSD替代HDD,或配置RAID 10提升I/O吞吐。 - 调整I/O调度器:运行 `echo deadline > /sys/block/sda/queue/scheduler`(将 `sda` 替换为您的磁盘),`deadline` 调度器适合高负载场景。 - **系统级优化**: - 减少swap使用:编辑 `/etc/sysctl.conf`,添加 `vm.swappiness=10`,然后运行 `sysctl -p`。 - 内核参数优化:增加文件句柄限制,在 `/etc/security/limits.conf` 中添加 `* soft nofile 65536` 和 `* hard nofile 65536`。 - **监控和告警**:部署工具如 `sar`(sysstat包)或Prometheus+Grafana,设置iowait阈值告警(如 >15%),便于早期干预[^2]。 #### 步骤5: 验证和预防 优化后,重新监控iowait: - 运行 `iostat 1` 和 `top`,确认 `wa` 值下降。 - 压力测试:使用 `fio` 工具模拟I/O负载(`sudo fio --name=test --ioengine=libaio --rw=randrw --bs=4k --numjobs=4 --size=1G --runtime=60`)。 预防措施包括: - 定期检查磁盘健康(`smartctl -a /dev/sda`)。 - 平衡负载:将高I/O应用分散到多台服务器。 #### 总结 iowait过高通常由磁盘瓶颈、内存不足或应用配置不当引起。通过工具监控、进程识别和针对性优化(如升级硬件或调整应用),能有效降低iowait。例如,某案例中优化MySQL参数后iowait从20%降至5%[^5]。记住,高iowait并非总是磁盘问题,需结合系统资源整体分析[^1]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值