问题发现场景 某天突然收到线上应用的gc时间过长的告警,刚开始只有一台机器偶尔报一下,后续其他机器也纷纷告警,具体告警的阈值是应用10分钟内ygc的总时长达到了6.6s. 初步排除过程 按照gc问题常规排查流程,还是先保留现场,jmap -dump:format=b,file=temp.dump pid. 查看下gc日志,发现出问题的时候的单次ygc耗时几乎有200ms以上了.正常来说单次ygc在100ms以下,基本可以认为应用是比较健康的.所以这时候已经可以确定告警的原因就是ygc比较慢. j…

解Bug之路-记一次中间件导致的慢SQL排查过程 前言 最近发现线上出现一个奇葩的问题,这问题让笔者定位了好长时间,期间排查问题的过程还是挺有意思的,正好博客也好久不更新了,就以此为素材写出了本篇文章. Bug现场 我们的分库分表中间件在经过一年的沉淀之后,已经到了比较稳定的阶段.而且经过线上压测的检验,单台每秒能够执行1.7W条sql.但线上情况还是有出乎我们意料的情况.有一个业务线反映,每天有几条sql有长达十几秒的超时.而且sql是主键更新或主键查询,更奇怪的是出现超时的是不同的sql,似…

解Bug之路-记一次存储故障的排查过程 高可用真是一丝细节都不得马虎.平时跑的好好的系统,在相应硬件出现故障时就会引发出潜在的Bug.偏偏这些故障在应用层的表现稀奇古怪,很难让人联想到是硬件出了问题,特别是偶发性出现的问题更难排查.今天,笔者就给大家带来一个存储偶发性故障的排查过程. Bug现场 我们的积分应用由于量非常大,所以需要进行分库分表,所以接入了我们的中间件.一直稳定运行,但应用最近确经常偶发连接建立不上的报错.报错如下: GetConnectionTimeOutException 而…

公司在kubernetes集群上稳定运行数月的kibana服务于昨天下午突然无法正常提供服务,访问kibana地址后提示如下信息: 排查过程: 看到提示后,第一反应肯定是检查elasticsearch集群,碰巧昨天下午公司VPN奇慢,频繁连接不上亦庄机房,因此问题排查一度集中在elasticsearch服务上,另一方面也是因为kibana服务由docker镜像提供,只读服务本身是没有状态变化的,在kubernetes集群中查看pod状态,也没有崩溃重启的记录,因此只能怀疑是连接的elastics…

摘要:众所周知,Nginx是目前最流行的Web Server之一,也广泛应用于负载均衡.反向代理等服务,但使用过程中可能因为对Nginx工作原理.变量含义理解错误,或是参数配置不当导致Nginx工作异常.本文介绍的就是福建开机广告Nginx的参数location处理静态文件配置不当引发的nginx日志骤增到14G的问题排期过程. 一.问题现象及系统介绍 现象:12月15日 21:02分,正在外面吃宵夜,手机收到监控平台的一条"服务器磁盘空间<20%"报警短信. 系统介绍:为了看此…

由于一次功能上线后,导致某数据量急剧下滑,给我们紧张的呢!排查过程也是个学习过程(这其中有大部分是领导们的功劳,不过分享给大家应该也不犯法吧,ᐓ) 1. 确认问题的真实性? 被数据部门告知,某数据量下滑严重,当时即知道问题的严重性.且该问题是在我的功能上线后产生,第一反应就是,我代码哪里写错了? 但是,还得按流程来,通过各种维度数据对比请求量,实际落地量.确认问题! 其实该过程中,我们并没有确认自己的数据量下滑.但是这也脱不了数据下滑的干系.只能进行下一步! 2. 检查代码,找有经验的同学,对比…

Linux(2)---记录一次线上服务 CPU 100%的排查过程 当时产生CPU飙升接近100%的原因是因为项目中的websocket时时断开又重连导致CPU飙升接近100% .如何排查的呢 是通过日志输出错误信息: 得知websocket时时重新 连接的信息,然后找到原因 解决了. 当然这里幸好能通过日志大致分析出原因 那么我就在思考如果日志没有告诉任何信息 但线上CPU还是接近100%那么如何排查呢.所以学习了下排查过程. 通过查阅资料并实践后,这里总结了两种办法.第一种博客满天飞的方法…

现象描述 大概1个月多以前 在启动脚本中增加了tail -f 用来启动后追踪日志判断是否启动成功 后发现无法执行shutdown.sh(卡住 利用curl) 然后无奈使用kill -9 但通过ps -el 发现此时进程变为defunct 即僵尸进程 当时的解决办法无奈 只能找到僵尸进程的父进程kill 当时认为可能是tail的问题 后来启动脚本中去掉tail 发现问题解决 But 当时一直没有来得及排查是如何引起僵尸进程的问题 这两天抽时间排查了一下 发现和tail没有一毛钱关系 艰难的排查过程…

Connection refused 排查过程 connection refused  排查  起因 今天在连接 rabbitmq 时,报 Connection refused (如下图),借此机会记录一下问题的排查过程 异常 环境 服务端 Centos 7 ( 阿里云 ECS ) rabbitmq 3.7.7 客户端 macOs 排查 检测服务是否正常启动 ps -ef | grep rabbit 如果服务未启动,则启动服务 然后,查看服务是否正确监听了端口 netstat -anp | gr…

当前使用的Spring JDBC版本是5.0.0.RC1,HikariCP版本是3.1.0. 今天测试同学反馈在前端页面点击次数多了,就报500错误,数据显示不出来.于是我在后台服务日志中观察发现HikariCP连接池报如下的错误: getDataByWorkSheetId method Exception:HikariPool-2 - Connection is not available, request timed out after 30000ms. 接着开始翻墙搜谷歌,大致要从两方面进…