服务器负载暴涨以后...-阿里云开发者社区

服务器负载暴涨以后...

2017-11-16 1186

版权

本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。

本文涉及的产品

RDS MySQL Serverless 基础系列，0.5-2RCU 50GB

RDS MySQL Serverless 高可用系列，价值2615元额度，1个月

简介：

服务器负载暴涨以后

作者：田逸（ sery@163.com） from：http://b.formyz.org/2011/1124/53.html

正在赶写演讲的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; 输出为 +---------------------------+-------+----------+-----------------------------------------------------------+

+---------------------------+-------+----------+-----------------------------------------------------------+

+---------------------------+-------+----------+-----------------------------------------------------------+

4 rows in set (0.04 sec)

真损坏了，修复一把：mysql> repair table cdb_uc_notelist; 输出为+---------------------------+--------+----------+-----------------------------------------------+

+---------------------------+--------+----------+-----------------------------------------------+

+---------------------------+--------+----------+-----------------------------------------------+

（2）修复第2个表，方法同上。

（3）再次检查表状态。

（4）让管理员从后台登录，查看是否正常。

本文转自sery51CTO博客，原文链接： http://blog.51cto.com/sery/723220 ，如需转载请自行联系原作者

服务器负载暴涨以后...

热门文章

最新文章

相关课程

相关电子书

相关实验场景