通过jstack与jmap分析一次线上故障
一、发现问题 下面是线上机器的cpu使用率，可以看到从4月8日开始，随着时间cpu使用率在逐步增高，最终使用率达到100%导致线上服务不可用，后面重启了机器后恢复。 二、排查思路 简单分析下可能出问题的地方，分为5个方向： 1.系统本身代码问题 2.内部下游系统的问题导致的雪崩 ...
原文：通过jstack与jmap分析一次线上故障
一 发现问题 下面是线上机器的cpu使用率，可以看到从 月 日开始，随着时间cpu使用率在逐步增高，最终使用率达到 导致线上服务不可用，后面重启了机器后恢复。 二 排查思路 简单分析下可能出问题的地方，分为 个方向： .系统本身代码问题 .内部下游系统的问题导致的雪崩效应 .上游系统调用量突增 .http请求第三方的问题 .机器本身的问题 三 开始排查 .查看日志，没有发现集中的错误日志，初步排除 ...
2019-03-29 16:34 0 1788 推荐指数：
相关推荐
一次线上OOM故障排查经过
转贴：http://my.oschina.net/flashsword/blog/205266 本文是一次线上OOM故障排查的经过，内容比较基础但是真实，主要是记录一下，没有OOM排查经验的同学也可以参考。 现象 我们之前有一个计算作业。最近经常出现不稳定，无法正常响应的情况。具体表现 ...
【JVM】记录一次线上SWAP偏高告警的故障分析过程
近期遇到一个堆外内存导致swap飙高的问题，这类问题比较罕见，因此将整个排查过程记录下来了 现象描述 最近1周线上服务器时不时出现swap报警（swap超过内存10%时触发报警，内存是4G，因此swap超过400M会触发报警），每次都是童鞋们通过重启tomcat解决的；但导致的根本原因 ...
由一次线上故障来理解下 TCP 三握、四挥 & Java 堆栈分析到源码的探秘
本文导读： 生产故障场景介绍 TCP 建连三次握手过程 TCP 断连四次挥手过程 结合 Java 堆栈剖析源码 再从堆栈中找到"罪魁祸首" 问题优化方案总结 1、生产故障场景介绍 业务简介： 该服务主要是提供对外的代理接口，大部分接口都会调用第三方接口 ...
从一次线上故障思考Java问题定位思路
问题出现：现网CPU飙高，Full GC告警 CGI 服务发布到现网后，现网机器出现了Full GC告警，同时CPU飙高99%。在优先恢复现网服务正常后，开始着手定位Full GC的问题。在现场只能够抓到四个GC线程占用了很高的CPU，无法抓到引发Full GC的线程。查看了服务故障期间的错误 ...
记一次线上kafka一直rebalance故障
来源 https://www.jianshu.com/p/271f88f06eb3 今天我司线上kafka消息代理出现错误日志，异常rebalance，而且平均间隔2到3分钟就会rebalance一次，分析日志发现比较严重。错误日志 ...
记录一次因subprocess PIPE 引起的线上故障
sence：python中使用subprocess.Popen(cmd, stdout=sys.STDOUT, stderr=sys.STDERR, shell=True) ，stdout, s ...
记录一次线上yarn RM频繁切换的故障
周末一大早被报警惊醒，rm频繁切换 急急忙忙排查 看到两处错误日志 错误信息1 错误信息2 查看源码处FairScheduler 跟进去看下 ...