记录服务器iowait过高排查过程

最新推荐文章于 2025-05-21 12:23:05 发布
最新推荐文章于 2025-05-21 12:23:05 发布
阅读量969 收藏 5
点赞数 4
CC 4.0 BY-SA版权
文章标签： 服务器 运维
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/shark_pang/article/details/138967033

在维护服务器和站点的时候，突然被投诉说站点访问过慢。

首先判断异常状态

排查 网络、站点逻辑、请求量、io读写

查看宝塔的 负载数据，发现 iowait 过高

持续观察宝塔 的 磁盘IO 实时数据，确确实实 是标红。下图是优化后的，虽然还是标红，但比一开始好很多了，优化前 读写延迟经常 是 3000ms以上

排查io异常的进程

Linux下载 iotop 软件

yum install iotop

直接运行 iotop

重点排查 nginx相关的内容，这里是优化后的，所以看不出nginx有异常。异常的时候 nginx的io值会持续性 在30%以上

查找进程相关的文件

lsof -p 13925

 排查nginx中io高的进程，查找 熟悉的文件路径， 经过排查 导致nginx的iowait高的 内容有： 站点日志、宝塔防火墙、宝塔网站监控 软件 这三个地方，其中 waf和网站监控 异常的高。

进行取舍后，删除网站监控软件。好了 ，iowait降下来了。当然，也可以直接升级服务器配置

嗨皮螃
关注
CPU占用过高故障排查实战
悦分享
11-18 308
Java 线程池以有界队列的线程池为例，当新任务提交时，如果运行的线程少于 corePoolSize，则创建新线程来处理请求。最后定位问题是在tomcat中的catalina.out控制台日志输出过大，造成磁盘空间占满，然后系统无法继续写日志，从而导致刚好dubbo服务打印的日志一直处于死锁状态，该线程陷入死循环，大量消耗cpu，最终的结果是内存溢出，杀死进程了。将控制台打印的日志给禁用掉，并限制打印日志的大小，因为我的日志里面有打印base64位的图片日志，该日志所需空间太大，所以对日志禁用及限制。
Ubuntu服务器宕机排查记录
qq_40907977的博客
03-10 7401
环境 :ubuntu 问题症状：服务器内存占用持续增长，性能低下，并发上不去，网络无法ping通，无法登录、无法操作，输入操作无响应。也就是说系统宕机了。 宕机原因 ： 先查看线上服务日志，再通过分析Linux系统日志后， 出现内存不足，Linux出于保护机制。 排查思路：分析出内存泄露模块，分析出性能瓶颈，调优JVM 使用工具：jconsole、jprofiler 参考链接 ： 服务器宕机排查记...
LINUX CPU iowait一般性问题分析
有莘不破的博客
04-17 2048
LINUX上遇到iowait问题的一般性排查手段
IOWait相关问题
guoguo1980的专栏
04-27 3038
定位IOWait高的一些方法和工具：在Linux性能分析时经常使用的工具包括：top, iostat, vmstat等IOWait高的一些处理方法1、检查RAID的状态，比如是否正在重建或者没有初始化2、替换操作系统的内核，最好使用发行版标准的Linux kernel，因为有比较多的补丁3、检查/proc/sys/vm下面是否可以优化4、是否使用了文件系统，文件系统是否有优化的选项，比如在RAID
CentOS 7.9 宝塔面板显示IO延迟居高不下的排查方法
半抹灯芯的博客
05-21 650
本文介绍了在CentOS 7.9宝塔面板中排查和解决IO延迟问题的多种方法。首先，通过df -h命令检查磁盘空间，清理无用文件如宝塔面板日志。其次，使用top和htop命令查看系统资源使用情况，识别高资源占用进程。接着，通过iotop监控IO使用情况，找出高IO读写速率的进程。针对MySQL数据库，检查其状态并优化配置和查询语句。对于PHP-FPM进程，调整其配置参数以优化性能。此外，检查系统日志和宝塔面板插件，识别并解决可能导致IO延迟的问题。通过这些步骤，可以有效降低IO延迟，提升服务器性能。
磁盘io使用率高问题排查
赵英超的博客
10-07 5466
例如，如果统计间隔1秒，该设备有0.8秒在处理IO，而0.2秒闲置，那么该设备 的%util = 0.8/1 = 80%，所以该参数暗示了设备的繁忙程度。rrqm/s：每秒这个设备相关的读取请求有多少被Merge了（当系统调用需要读取数据的时候，VFS将请求发到各个FS，如果FS发现不同的读 取请求读取的是相同Block的数据，FS会将这个请求合并Merge）；上面的例子中，我们可以看到磁盘sda以及它的各个分区的统计数据，当时统计的磁盘总TPS是39.29，下面是各个分区的TPS。
iowait过高问题查找及解决方案
因上努力，果上随缘。但行好事，莫问前程。
11-10 4585
如果 await 远大于 svctm，说明 I/O 队列太长，应用得到的响应时间变慢，如果响应时间超过了用户可以容许的范围，这时可以考虑更换更快的磁盘，调整内核 elevator 算法，优化应用，或者升级 CPU。另外，时机也很重要，可能 5 分钟前还人满为患的收款台，现在已是人去楼空，这时候交款可是很爽啊，当然，前提是那过去的 5 分钟里所做的事情比排队要有意义 (不过我还没发现什么事情比排队还无聊的)。确认是否是I/O导致的系统缓慢我们可以使用多个命令，最简单的是unix的命令 top。
记一次高io wait问题分析及解决-设置合理的SGA
Enmotech的博客
07-08 1558
点击上方"蓝字"关注我们，享更多干货！一、背景由于行内某交易系统需要进行版本更新，为保证新版本上线后可以达到最优效果，根据需求，对该系统的Oracle数据库进行了一次深入诊...
解决kubernetes宿主机top cpu wa io过高引起的cpu资源耗尽问题
热门推荐
Anteoy的博客
05-25 1万+
环境 cat /etc/redhat-release CentOS Linux release 7.4.1708 (Core) sudo docker version Client: Version: 17.10.0-ce API version: 1.33 Go version: go1.8.3 Git commit: f4ffd25 Built: ...
CentOS 7 下 CPU 负载较高排查记录
老实人张大傻
12-31 4065
文章目录通过 top 查看服务器负载通过 iostat 查看磁盘读写情况iostat 安装iostat 使用找到 I/O 占用高的进程通过 iotop 命令查看通过 pidstat 命令查找参考 通过 top 查看服务器负载 [root@localhost ~]$ top top - 15:54:38 up 82 days, 6:28, 4 users, load average: 4.89, 8.11, 11.28 Tasks: 121 total, 1 running, 120 sleepin
iowait过高的问题 一招定位原因
yongyong169的博客
03-29 1154
使用iotop命令 根据tid 查找真正的进程，因为我查找的时间tid变成了17781，所以用这个id定位
磁盘IO高排查过程
libaxuann的博客
05-15 1451
机器io高原因排查全命令指南
achacuo3822的博客
04-10 434
机器io高原因排查全命令指南¶ 步骤1：使用iostat查看io情况¶ $iostat -x -d 1 主要查看w_await，svctm，%util这几项，svctm表示等待时间，%util高于100时表示机器io高。 步骤2：使用ioshow查看导致io高的具体进程¶ ioshow是针对开发集群低版本内核编写的工具 步骤3：使用pstree查...
性能分析（4）- iowait 使用率过高案例
qq_33801641的博客
08-10 2217
性能分析小案例系列，可以通过下面链接查看哦 https://www.cnblogs.com/poloyy/category/1814570.html 前言 前面两个案例讲的都是上下文切换导致的 CPU 使用率升高 这一篇就来讲讲等待 I/O 导致的 CPU 使用率升高的案例 进程状态 详解进程状态 https://www.cnblogs.com/poloyy/p/134137...
oracle数据库iowait高,CPU-IOWAIT分析
weixin_34859739的博客
04-14 2191
某系统的备DB的CPU iowait[6%]高于其他机器无影响：一般iowait在20%才会影响到业务背景说明：此场地使用的是一主两备的架构。主库使用的是sas盘，两台备库使用的是sata盘此场地使用的是一主两备的架构。主库使用的是sas盘，两台备库使用的是sata盘实际使用过程中采取级联的方式，主库同步数据给一台备库，这台备库再同步给另外一台备库就导致其中一台备库数据读写频繁，IOWAIT偏高服...
iowait 过高问题的查找及解决linux
weixin_34004750的博客
11-07 597
Linux 有许多可用来查找问题的简单工具，也有许多是更高级的 I/O Wait 就是一个需要使用高级的工具来debug的问题，当然也有许多基本工具的高级用法。I/O wait的问题难以定位的原因是因为我们有很多工具可以告诉你说I/O 受限了，但是并没有告诉你具体是那个进程引起的（哪些进程们） 确认是否是I/O问题导致系统缓慢 确认是否是I/O导致的系统...
服务器排障举例
最新发布
06-06
<think>嗯，用户这次想要服务器排障的示例和方法，看来是个运维人员或者系统管理员，可能遇到了实际的服务器问题。之前对话历史里用户明确提到了“服务器排障的示例或方法”，还特别强调要“流程”，说明需要结构化指导。结合用户提供的四个引用素材，发现核心是服务器排障的操作细节。用户引用的材料很有价值，比如引用1提到Nginx日志分析和端口检查，引用3展示了TCP连接数统计命令，引用4则包含硬件层面的RAID、硬盘和CPU故障排查。这些正好能组合成完整的排障流程。考虑以“核心流程+细分模块”的形式组织回答：先给用户一个完整的流程图框架，再拆解每个环节的具体命令和案例。这样既符合用户要的“流程”，又能避免信息过载。具体流程设计上，准备分五个递进层级：用户请求——网络层——应用层——系统层——硬件层。每个层级都要配置真实可用的命令，比如用netstat/tcpdump查网络问题，用journalctl看系统日志。特别要注意命令的实用性，像引用4的MegaCli和badblocks这类专业工具必须标注注意事项，防止误操作。在风险控制点方面，考虑用引用2的理念——优先考虑操作规范性问题。会在总结部分强调“人为操作失误”优先级的排查顺序，比如先确认是否配置错误或命令敲错，再检查硬件问题。准备在排障案例中展示两个典型错误：连接数爆满和磁盘故障，这样用户能更直观理解流程应用。用户提供的引用3中的netstat统计命令很有用，准备优化这个命令，因为原始命令会漏掉TIME_WAIT等状态。考虑使用更完整的模板：netstat-ant|awk'/^tcp/{++S[$6]}END{for(iinS)printi,S[i]}'。同时加入连接数优化的解决方法，这样用户不仅能诊断还能处理问题。准备生成的相关问题都是用户后续可能需要的：比如性能监控工具选型（对应引用1的日志分析）、自动化方案（用户明显需要效率工具）、云环境差异（现在很多服务器上云了）、数据库专用检查（用户提到过Web服务器）以及文档管理经验（引用4提到过记录重要性）。</think> 以下是服务器故障排查的标准化流程及示例方法，结合常见故障场景提供操作指引： --- ### **服务器故障排查标准化流程** ```mermaid graph TD A[故障现象定位] --> B[网络层检查] A --> C[应用层检查] A --> D[系统层检查] A --> E[硬件层检查] B --> F[端口/连接状态] C --> G[服务日志分析] D --> H[资源占用监控] E --> I[硬件健康诊断] ``` --- ### **一、核心排查步骤及示例** 1. **现象定位** - ✅ 关键问题：响应慢/服务不可用/数据异常 - ✅ 示例操作： ```bash # 实时监控系统负载 $ top -c -d 2 $ uptime # 查看1/5/15分钟负载 ``` 2. **网络层排查** - 🔧 **端口监听检测**（引用[3]）： ```bash $ netstat -tunlp | grep ':80' # 检查Web端口 $ ss -tuln | grep LISTEN # 更高效替代方案 ``` - 🌐 **连接追踪**（引用[3]优化）： ```bash # 统计TCP连接状态 $ netstat -ant | awk '/^tcp/ {++S[$6]} END{for(i in S) print i, S[i]}' ``` > 重点监控：`TIME_WAIT`过高需调整内核参数，`ESTABLISHED`突增警惕攻击 3. **应用层排查** - 📍 **服务日志分析**（引用[1]实践）： ```bash # Nginx错误日志检索 $ tail -100 /var/log/nginx/error.log | grep -E 'timeout|deadlock' # 实时追踪访问日志 $ tail -f /var/log/nginx/access.log -n 50 | awk '{print $1,$7,$9}' ``` 4. **系统层深度检查** - 🖥️ **资源瓶颈定位**： ```bash $ free -h # 内存分析 $ iostat -dx 2 # 磁盘IO $ vmstat 1 5 # 进程队列监控 ``` - 🛠️ **文件系统修复**（引用[4]）： ```bash $ umount /dev/sda1 && fsck -y /dev/sda1 # 强制修复（需卸载分区） ``` 5. **硬件层健康诊断** - 💾 **磁盘健康度**（引用[4]扩展）： ```bash $ smartctl -a /dev/sda # SMART检测 $ badblocks -v /dev/sda # 坏道扫描 ``` - 🔧 **RAID状态确认**： ```bash $ cat /proc/mdstat # 软RAID $ MegaCli -LDInfo -Lall -aAll | grep State # 硬件RAID（需安装MegaCLI） ``` --- ### **二、典型故障处理案例** #### **案例1：Web服务响应缓慢** ```mermaid sequenceDiagram 用户->>Nginx： HTTP请求 Nginx->>后端应用： 转发请求 后端应用-->>Nginx： 响应超时 Nginx->>用户： 504 Gateway Timeout ``` **解决路径：** 1. `netstat -s | grep timeout` 检查TCP超时 2. `journalctl -u tomcat --since "10 min ago"` 查应用日志 3. `sar -q 1 10` 观察运行队列长度 #### **案例2：磁盘故障（引用[4]实践）** ```bash # 检测到硬盘/media损坏 $ dmesg | grep -i error [ 3.221004] sd 0:0:0:0: [sdb] FAILED # 坏道隔离恢复流程： 1. badblocks -nsv /dev/sdb > bad_sectors.txt 2. fsck -l bad_sectors.txt /dev/sdb 3. 立即更换硬盘并重建RAID ``` --- ### **三、排障黄金原则** 1. **优先级排序**（引用[2]强化）： 📌 操作规范 > 配置错误 > 软件故障 > 硬件故障 *注：70%故障由配置变更或操作失误引起[^2]* 2. **证据链保全** - 记录执行命令及输出 - 备份关键日志：`tar -zcvf logs_$(date +%F).tar.gz /var/log/{nginx,tomcat}` 3. **最小影响原则** 线上环境避免直接`fsck`或`reboot`，优先采用`strace`/`tcpdump`等诊断工具 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值