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

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

首先判断异常状态

排查 网络、站点逻辑、请求量、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降下来了。当然,也可以直接升级服务器配置

<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、付费专栏及课程。

余额充值