记一次OOM问题排查过程】的更多相关文章

上周运维反馈线上程序出现了OOM,程序日志中的输出为 Exception in thread "http-nio-8080-exec-1027" java.lang.OutOfMemoryError: Java heap space Exception in thread "http-nio-8080-exec-1031" java.lang.OutOfMemoryError: Java heap space 看线程名称应该是tomcat的nio工作线程,线程在处理…
大家好,我是大彬~ 今天给大家分享最近出现的OOM问题. 上周五早上,测试同学反馈测试环境的子系统服务一直超时,请求没有响应. 收到这个问题之后,我有点纳闷,最近这个系统也没有改动代码逻辑,怎么会突然报服务超时的问题.为避免影响测试进度,我赶紧登陆堡垒机查看日志,看看到底啥情况. 首先先看系统负载情况,使用top命令查看.发现其中某个Java进程cpu一直持续停留在100%到200%之间.因为这个系统不涉及大量运算的逻辑,所以可以猜到要不就是死循环的问题,要不就是频繁full gc导致. 查看系…
解Bug之路-记一次中间件导致的慢SQL排查过程 前言 最近发现线上出现一个奇葩的问题,这问题让笔者定位了好长时间,期间排查问题的过程还是挺有意思的,正好博客也好久不更新了,就以此为素材写出了本篇文章. Bug现场 我们的分库分表中间件在经过一年的沉淀之后,已经到了比较稳定的阶段.而且经过线上压测的检验,单台每秒能够执行1.7W条sql.但线上情况还是有出乎我们意料的情况.有一个业务线反映,每天有几条sql有长达十几秒的超时.而且sql是主键更新或主键查询,更奇怪的是出现超时的是不同的sql,似…
解Bug之路-记一次存储故障的排查过程 高可用真是一丝细节都不得马虎.平时跑的好好的系统,在相应硬件出现故障时就会引发出潜在的Bug.偏偏这些故障在应用层的表现稀奇古怪,很难让人联想到是硬件出了问题,特别是偶发性出现的问题更难排查.今天,笔者就给大家带来一个存储偶发性故障的排查过程. Bug现场 我们的积分应用由于量非常大,所以需要进行分库分表,所以接入了我们的中间件.一直稳定运行,但应用最近确经常偶发连接建立不上的报错.报错如下: GetConnectionTimeOutException 而…
摘要:众所周知,Nginx是目前最流行的Web Server之一,也广泛应用于负载均衡.反向代理等服务,但使用过程中可能因为对Nginx工作原理.变量含义理解错误,或是参数配置不当导致Nginx工作异常.本文介绍的就是福建开机广告Nginx的参数location处理静态文件配置不当引发的nginx日志骤增到14G的问题排期过程. 一.问题现象及系统介绍 现象:12月15日 21:02分,正在外面吃宵夜,手机收到监控平台的一条"服务器磁盘空间<20%"报警短信. 系统介绍:为了看此…
1.问题描述 每次启动信息报错如下: 2.排查过程 2.1起初怀疑是堆内存不够: 将本地队内存调整由-Xms512M,-Xmx1024M,改成与测试环境相同1536M,还是失败 如上图报错中有notify问题,怀疑notify启动占用线程数过多,增加如下线程限制: 后进行重启测试,发现还是启动报错,排除notify问题 2.2后续怀疑是线程空间占用过大 调整xss 128k 一般说来,Stack Space为128K是够用的.不过既然报错按照160k进行更改,直接报错如下 栈空间溢出...放弃此…
上传文件程序会有一定的概率提示错误,错误率大概在1%以下,错误信息是:org.apache.http.NoHttpResponseException , s3-us-west-1.amazonaws.com:80 failed to respond,看着是上传到S3的过程中发送了网络错误? 通过查阅资料,发现了一篇比较好的文章:一次NoHttpResponseException问题分析解决.这个文章的观点是会发生这个错误的原因是服务端关闭了连接,而客户端还在使用该连接,导致服务端响应RST报文,…
公司在kubernetes集群上稳定运行数月的kibana服务于昨天下午突然无法正常提供服务,访问kibana地址后提示如下信息: 排查过程: 看到提示后,第一反应肯定是检查elasticsearch集群,碰巧昨天下午公司VPN奇慢,频繁连接不上亦庄机房,因此问题排查一度集中在elasticsearch服务上,另一方面也是因为kibana服务由docker镜像提供,只读服务本身是没有状态变化的,在kubernetes集群中查看pod状态,也没有崩溃重启的记录,因此只能怀疑是连接的elastics…
原贴如下 坑爹坑娘坑祖宗的87端口(记一次tomcat故障排查) 虽然我用的是PHPstudy部署的dedecms,还是一样栽倒这个坑里了. 总结经验:本地测试使用8000~9000的端口比较安全.…
记一次数据库调优过程(IIS发过来SQLSERVER 的FETCH API_CURSOR语句是神马?) 前几天帮客户优化一个数据库,那个数据库的大小是6G 这麽小的数据库按道理不会有太大的性能问题的,但是客户反应说CPU占用很高,经常达到80%~90% 我检查了任务管理器,确实是SQLSERVER占的CPU 而服务器的内存是16G内存,只占用了7G+ 客户的环境: Windows2008R2 SQLSERVER2005 SP3 64位 企业版 服务器内存:16G CPU:8核 RDS:阿里云主机…