高负载故障解决一例

简介:

top - 16:09:36 up 159 days,  3:51,  4 users,  load average: 29.00, 29.07, 29.17
Tasks: 417 total,   1 running, 415 sleeping,   1 stopped,   128 zombie
Cpu(s):  0.0%us,  0.1%sy,  0.0%ni, 99.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:     16087M total,    14465M used,     1622M free,      113M buffers
Swap:      164M total,        8M used,      156M free,    13965M cached

今日登陆服务器。top一看,128个僵尸进程,用了下面的命令处理,记录如下

ps -ef |grep '<defunct>'

root       682   678  0 Jan24 ?        00:00:00 [sh] <defunct>
root       780   775  0  2011 ?        00:00:00 [sh] <defunct>
root       951   948  0 Jan24 ?        00:00:00 [sh] <defunct>
root      1420  1364  0  2011 ?        00:00:00 [sh] <defunct>
root      2109  2063  0 Jan24 ?        00:00:00 [sh] <defunct>

ps -ef |grep '<defunct>'|wc -l
128

`ps -ef | grep '<defunct>'|grep -v grep |awk '{print $2,$3}'|sed "s/^/kill -9 /g"`

同时发现系统负载是如此之高,查看mysql,发现凌晨的备份到现在还未执行完毕,杀掉备份进程,系统负载变为以下

top - 16:29:57 up 159 days,  4:12,  5 users,  load average: 1.14, 4.52, 15.14
Tasks: 305 total,   1 running, 303 sleeping,   1 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni, 99.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:     16087M total,    14444M used,     1643M free,      113M buffers
Swap:      164M total,        8M used,      156M free,    13965M cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                   
 6648 root      20   0  2472 1148  768 R    1  0.0   0:00.45 top                                                                                                       
    1 root      20   0  1940  644  596 S    0  0.0   1:29.46 init                                                                                                      
    2 root      15  -5     0    0    0 S    0  0.0   0:01.54 kthreadd

 

此故障是由于脚本程序执行故障引起的



本文转自it你好 51CTO博客,原文链接:http://blog.51cto.com/itnihao/830368,如需转载请自行联系原作者

相关文章
|
3月前
|
监控 Java Linux
疯狂飙高!怎么排查CPU导致系统反应缓慢的问题?
疯狂飙高!怎么排查CPU导致系统反应缓慢的问题?
|
4月前
|
存储 设计模式 监控
如何诊断处理生产环境服务器变慢
在当今的高科技环境下,生产环境服务器的性能问题可能是一个复杂且棘手的问题。当服务器变慢时,可能会对企业的运营产生重大影响,包括客户满意度下降,工作效率降低,甚至可能导致整个系统崩溃。为了解决这些问题,我们需要深入了解生产环境服务器变慢的原因,并掌握有效的诊断和处理方法。本文将详细介绍如何诊断和处理生产环境服务器变慢的问题。通过深入探讨服务器的硬件和软件配置,网络环境,以及可能影响服务器性能的各种因素,我们将提供一系列实用的诊断和解决方案。
47 1
|
7月前
|
Java 调度
CPU突然飙高系统反应慢,是怎么导致的?有什么办法排查?
面试过程中,场景类的问题更容易检测出一个开发人员的基本能力。这不,有一位小伙伴去阿里面试,第一面就遇到了关于“CPU 飙高系统反应慢怎么排查”的问题?当时这位小伙伴不知从何下手。 今天,我给大家分享一下我的解决思路。
110 0
|
9月前
|
算法 前端开发 应用服务中间件
高并发环境如何有效缓解带宽压力
高并发环境如何有效缓解带宽压力
|
10月前
|
缓存 运维 监控
如何通过一系列步骤来诊断和解决服务器CPU负载过高问题?
如何通过一系列步骤来诊断和解决服务器CPU负载过高问题?
547 0
|
12月前
|
监控 容灾 安全
系统总出故障怎么办?
系统总出故障怎么办?
|
SQL 监控 关系型数据库
一次数据库CPU飙高问题排查与解决
### 问题发现 最近,经常收到一些数据库的报警,提示我们的数据库的CPU有异常飙高的情况,通过该监控发现,确实间歇性的有一些CPU飙高的情况,经常把CPU打满了。 ![](https://ata2-img.oss-cn-zhangjiakou.aliyuncs.com/neweditor/a1786489-1f44-4c39-bea4-85ca25a45433.png) ### 问题排
456 0
一次数据库CPU飙高问题排查与解决
|
SQL Arthas 存储
再一次生产 CPU 高负载排查实践
前几日早上打开邮箱收到一封监控报警邮件:某某 ip 服务器 CPU 负载较高,请研发尽快排查解决,发送时间正好是凌晨。 其实早在去年我也处理过类似的问题,并记录下来:《一次生产 CPU 100% 排查优化实践》 不过本次问题产生的原因却和上次不太一样,大家可以接着往下看。
|
Arthas 监控 Cloud Native
性能测试如何定位瓶颈?偶发超时?看高手如何快速排查问题
线上系统为何经常出错?数据库为何屡遭黑手?业务调用为何频频失败?连环异常堆栈案,究竟是哪次调用所为?数百台服务器意外雪崩背后又隐藏着什么?是软件的扭曲还是硬件的沦丧?走进科学带你了解 Arthas,一款开源一年多 GitHub Star 2 万,99% 的阿里研发小哥都在用的 Java 终极诊断利器.
性能测试如何定位瓶颈?偶发超时?看高手如何快速排查问题
|
SQL 移动开发 Java
Java应用CPU打满故障处理
java应用CPU故障处理,及后续操作建议
1932 0
Java应用CPU打满故障处理