运维故障案例

系列文章目录

`

一、故障案例与解决思路

1.故障案例一、NFS故障，造成系统cpu使用率低而负载极高。

故障概述:
公司使用NFS为web节点提供共享存储服务,某一天下午发现web节点CPU使用率低,而负载极高.登录web节点服务器排查发现后段NFS服务器故障.
影响范围:
网站看不到图片了。
处理流程:
通过ssh登录NFS服务器重启NFS服务
结果:
所有节点恢复正常。
场景一：磁盘读写请求过多就会导致大量I/O等待
上面说过，cpu的工作效率要高于磁盘，而进程在cpu上面运行需要访问磁盘文件，这个时候cpu会向内核发起调用文件的请求，让内核去磁盘取文件，这个时候会切换到其他进程或者空闲，这个任务就会转换为不可中断睡眠状态。当这种读写请求过多就会导致不可中断睡眠状态的进程过多，从而导致负载高，cpu低的情况。
场景二：MySQL中存在没有索引的语句或存在死锁等情况
我们都知道MySQL的数据是存储在硬盘中，如果需要进行sql查询，需要先把数据从磁盘加载到内存中。当在数据特别大的时候，如果执行的sql语句没有索引，就会造成扫描表的行数过大导致I/O阻塞，或者是语句中存在死锁，也会造成I/O阻塞，从而导致不可中断睡眠进程过多，导致负载过大。
具体解决方法可以在MySQL中运行show full processlist命令查看线程等待情况，把其中的语句拿出来进行优化。
场景三：外接硬盘故障，常见有挂了NFS，但是NFS server故障
比如我们的系统挂载了外接硬盘如NFS共享存储，经常会有大量的读写请求去访问NFS存储的文件，如果这个时候NFS Server故障，那么就会导致进程读写请求一直获取不到资源，从而进程一直是不可中断状态，造成负载很高。

2.Nginx出现大量的closed keepalive connection，而其他节点主机没有出现。

问题：因为两台服务器配置文件不一致，有一台开启了日志使用的是info级别
故障概述:
某天发现公司其中一台Nginx服务器日志里出现了大量的closed keepalive connection信息，但是其他节点的日志里没有出现。
影响范围:
导致Nginx日志不一致。
处理流程:
检查Nginx配置发现Nginx节点配置文件不一致，有一台开启的日志使用的是info级别。
结果:
将配置文件日志级别配置改为和其他节点一致后恢复正常。

3. 服务器假死

故障概述
测试环境下某台节点服务器出现了能ping通，但是ssh登录不上，任何其他操作也都没有反应，包括上面部署的nginx也打不开。
影响范围
运维人员通过ssh远程登录方式连接不上服务器。
处理流程
通过连接显示器直接登录服务器，使用nice将sshd的进程优先级调高，这样系统内存吃紧，还是能勉强登录sshd进行调试的。
结果
再通过ssh登录可以成功登录调试。

二、

1.

2.

总结