今天阳光明媚,掐指一算,今天比较适合划水。 于是早上到公司之后先是蹲了厕所,然后就准备翻阅公众号推文。 看的正嗨,突然钉钉群里开始响了, 生产日志群报了一条警告,如下: 报错信息很明确 定位到业务代码如下 一个普普通通的map的put操作,怎么就报错了呢?继续往下 ...
一次正常的上线,发了几台docker后,却发现有的机器打了info.log里面有日志,有的没有。排查问题开始: 第一:确认这台docker是否有流量进来,确认有流量进来。 第二:确认这台docker磁盘是否慢了,磁盘没有满。 第三:确认这台docker日志级别,确认和其他docker一样配置文件。 第四:这个时候就不知道了,病急乱投医,把部署的包,docker的cpu 内存 tcp 线程数 gc都 ...
2019-07-19 09:26 0 442 推荐指数:
今天阳光明媚,掐指一算,今天比较适合划水。 于是早上到公司之后先是蹲了厕所,然后就准备翻阅公众号推文。 看的正嗨,突然钉钉群里开始响了, 生产日志群报了一条警告,如下: 报错信息很明确 定位到业务代码如下 一个普普通通的map的put操作,怎么就报错了呢?继续往下 ...
这个是我很早以前解决的一个案例,其现象是系统每次上线后,20多台机器,总有两三机器,出现假死的情况。如何判断出系统假死?借助的是一个第三方公司运维监控平台;这种情况,前同事称之为的“假死”,需要重新启动系统才能恢复。因为我是新来乍到,觉得这种情况不正常,而且对研发(在这边是研发上线)来说,是一个 ...
背景 将log4j.xml的日志级别从error调整为info后,进行压测发现CPU占用很高达到了90%多(之前也就是50%,60%的样子). 问题排查 排查思路: 看进程中的线程到底执行的是什么,导致CPU占用较高. 1. 使用top命令查看到底是哪个应用 ...
? 通过查阅资料,发现了一篇比较好的文章:一次NoHttpResponseException问题分析解决。 ...
看到的错误信息如出一辙都是这样的:Method threw 'org.apache.ibatis.binding.BindingException' exception.Invalid bound s ...
应用部署在docker容器中,日志无报错,docker却有多次重启记录,Nginx监控报警 过程: 1.执行top命令查看内存占用情况 很干净的容器,只有java进程在运行 2.查看jvm情况 2.1 查看heap堆大小,可以使用jinfo -flags PID 查看 ...
周六生产服务器出现redis服务器不可用状态,错误信息为: 状态不可用,等待后台检查程序恢复方可使用。Unexpected end of stream; expected type 'Status' 如下图所示,下图6300就是我们redis服务器运行的端口。 头一次碰到此类问题 ...
最近测试环境的redis经常性发生某些key丢失的问题,最终的找到的问题让人大吃一惊。 复盘一下步骤: 1、发现问题 不知道从某天开始,后台经常报错,原因是某些key丢失,一开始不在意,以为是小bug,后来越来越频繁。 2、检查代码 看看是不是有误删除的情况,这些key的访问范围很小,压根没有删除 ...