服务器负载暴涨之后怎么办?

运维 系统运维
突然听到短信想起,没理会,以为是广告呢。刚放下念头,短信接连不断的响起来,不用想,准是哪个服务器报警了。打开nagios监控见面,发现3个服务器的load过高,处于warning状态。下面以老田这次实际过程为例,介绍遇到这种情况的处理方式。

正在赶写演讲的ppt,突然听到短信想起,没理会,以为是广告呢。刚放下念头,短信接连不断的响起来,不用想,准是哪个服务器报警了。

打开nagios监控见面,发现3个服务器(3个服务器处于同一个集群下,业务为论坛,同时在线人数大概4万人)的load过高,处于warning状态\

1、 先查看访问流量,通过对比,跟以前没什么差别。

2、 查看每个服务器的进程数和cpu使用情况,跟以前也没什么差别。

3、 查看系统日志,每个服务器都有“TCP: Treason uncloaked! Peer 113.247.241.146:21345/80 shrinks window 2128147967:2128149427. Repaired.”

4、 查看php日志,大量“[WARNING] fpm_request_check_timed_out(), line 158: child 25379, script '/mnt/html/bbs/forum.php' (pool default) execution timed out (120.306361 sec), terminating”。打开论坛首页,居然花了120多秒。我在php配置文件里设置的执行中断时间是120秒,超过这个值则关闭该子进程。看来应该从这里下手了。

先问问其他人,最近有没有改程序,有没有加插件?答:“没有”。我再仔细检查了系统:

(1)       查看有没有文件系统损坏而不能写入

(2)       查看分区是否满(实际上满了的话,有短信报警的)

(3)       查看tcp连接状态,还没以前多呢,看来不是系统的问题

那么,与之有关联的还有数据库、nfs文件系统以及memchached。先检查容易的,好!先检查nfs,正常;再检查memcached,正常。看来估计数据库有什么问题了。

登录数据库,先查看数据库错误日志,tail –f 一下,滚动输出,看来问题找到了。输入的内容主要有一下几行:

[ERROR] Got error 134 when reading table './uc_mumayi/cdb_uc_members'

[ERROR] Got error 134 when reading table './uc_mumayi_net/cdb_uc_members'

[ERROR] /usr/local/mysql/libexec/mysqld: The table 'pre_common_session' is full

接下来,从处理表满开始,把它的行数值设置巨大一点,我设置的是1000万,指令为:mysql>ALTER TABLE pre_common_session MAX_ROWS=10000000; 完毕后3个web服务器的负载马上就下降了。从报错信息中,可以判断有2个表可能损坏了。检查一下,如果真坏了,就修复一下吧!

(1)检查第一个表:mysql> check table cdb_uc_notelist;输出为

+---------------------------+-------+----------+-----------------------------------------------------------+
| Table                     | Op    | Msg_type | Msg_text                                                  |
+---------------------------+-------+----------+-----------------------------------------------------------+
| uc_mumayi.cdb_uc_notelist | check | warning | 11 clients are using or haven't closed the table properly |
| uc_mumayi.cdb_uc_notelist | check | warning | Size of datafile is: 260372       Should be: 259760       |
| uc_mumayi.cdb_uc_notelist | check | error    | Wrong bytesec: 101-114-110 at linkstart: 258412           |
| uc_mumayi.cdb_uc_notelist | check | error    | Corrupt                                                   |
+---------------------------+-------+----------+-----------------------------------------------------------+
4 rows in set (0.04 sec)

真损坏了,修复一把:

mysql> repair table cdb_uc_notelist; 

输出为

+---------------------------+--------+----------+-----------------------------------------------+
| Table                     | Op     | Msg_type | Msg_text                                      |
+---------------------------+--------+----------+-----------------------------------------------+
| uc_mumayi.cdb_uc_notelist | repair | info     | Wrong bytesec: 101-114-110 at 258412; Skipped |
| uc_mumayi.cdb_uc_notelist | repair | warning | Number of rows changed from 5715 to 5742      |
| uc_mumayi.cdb_uc_notelist | repair | status   | OK                                            |
+---------------------------+--------+----------+-----------------------------------------------+

(2)修复第2个表,方法同上。

(3)再次检查表状态。

(4)让管理员从后台登录,查看是否正常。

原文:http://b.formyz.org/2011/1124/53.html

【编辑推荐】

  1. 如何配置Web服务器实现负载均衡?
  2. 软件级负载均衡器(LVS/HAProxy/Nginx)的特点和对比
  3. CPU 负载过高的故障
责任编辑:yangsai 来源: b.formyz.org
相关推荐

2018-05-14 10:16:34

服务器机房识别

2018-05-10 12:15:09

串口服务器故障

2022-09-05 09:02:01

服务器CPU服务

2018-01-30 09:25:04

2011-11-15 22:13:48

服务器死机故障排除

2022-04-18 10:07:30

服务器安全设置

2009-01-19 09:19:58

局域网远程控制服务器

2018-04-16 10:29:15

Windows7DNS服务器

2021-11-11 15:21:43

云计算安全技术

2019-12-02 14:30:59

服务器SNMP网络协议

2011-07-27 11:00:32

服务器

2015-07-15 15:07:06

云计算Google试衣间

2013-01-29 13:22:24

系统服务

2022-11-18 07:40:57

2010-03-04 09:06:35

Windows 7Apache安装

2023-11-12 21:58:41

Java“假死”

2018-12-14 08:52:38

过载保护异构服务器负载均衡

2012-11-27 10:41:33

2018-09-26 08:16:25

2010-05-05 18:44:27

服务器负载均衡
点赞
收藏

51CTO技术栈公众号