今天看到监控平台显示项目的Full GC次数过多,查看了一下监控曲线,如下图,发现发生的时间点基本上都是在上午十点之后,到下午五点. 分析:考虑到业务形态,开始初步怀疑是访问人数增多引起的虚拟机内存不足,后来继续看监控指标找线索,发现如下图的监控曲线,当Young GC时,Old区的已使用空间并没有发生明显变化,而且剩余空间也非常大,所以通过这个分析发生Full GC的原因并不是虚拟机自动回收内存导致,很可能是在代码中存在System.gc(),所导致的Full GC. 在项目中搜索,发现jxl…

处理过线上问题的同学基本上都会遇到系统突然运行缓慢,CPU 100%,以及Full GC次数过多的问题.当然,这些问题的最终导致的直观现象就是系统运行缓慢,并且有大量的报警. 本文主要针对系统运行缓慢这一问题,提供该问题的排查思路,从而定位出问题的代码点,进而提供解决该问题的思路. 对于线上系统突然产生的运行缓慢问题,如果该问题导致线上系统不可用,那么首先需要做的就是,导出jstack和内存信息,然后重启系统,尽快保证系统的可用性.这种情况可能的原因主要有两种: 代码中某个位置读取数据量较大,导…

起因是本地为开发工程打包,总是提示 source 1.3 不支持注释.enum等等,但询问开发开发表示自己本地打包正常. 于是排查版本问题.开发的jdk是1.6版本,自己的是1.7,于是想要不降级吧,自己重新安装个1.6看看.有想法就有行动,闹心的行动. 下载一个64位JDK1.6后,没有拆卸原有的1.7,直接就安装了.闷声作大死,eclipse直接打不开了,提示: 使用window本身服务拆卸1.7时,可以正常拆卸,但是卸载1.6时,总会提示ddl寻找不到, 最后在网上找了个工具 your u…

从日志开始排查. 登录服务器端 $ ssh root@[IP] 关闭 ss,再次启动并其指定日志输出文件 $ ssserver -c /etc/shadowsocks.json -d stop $ ssserver -c /etc/shadowsocks.json --log-file /var/log/shadowsocks.log -d start 启动后查看日志 $ tail -f /var/log/shadowsocks.log  由日志可见启动正常. 本地电脑开启ss客户端,打开Go…

一.业务背景+系统架构 本次场景为kafka+storm+redis+hbase,通过kafka的数据,进入storm的spout组件接收,转由storm的Bolt节点进行业务逻辑处理,最后再推送进kafka. 表数据相关的逻辑为:查询Hbase表数据,首次查询会写入redis和storm cache,再次查询,会直接从redis或cache中取值. storm应用: 二.性能测试场景 1.数据:json类型的用户偏好数据700万 2.灌入方式:java脚本 3.hbase表:生产全量数据导入…

需求 前端同事说测试环境的服务接口查起来很慢,很不稳定,不是个别接口,而是大量接口. 情况分析 由于是在测试环境联调,没有多少用户量.第一步:先去服务器看看资源的使用情况.使用top命令,查看cpu的使用情况.   看图可以发现,有一个ID为2883的Java进程,导致CPU使用率达到百分之百. 第二步:根据进程ID找对应的Java项目.可以用ps -ef|grep java命令. 第三步:找对应对应项目日志排查原因.发现上传了一个视频文件过大导致. 第四步:kill -9 进程号,把项目关掉重…

问题背景 在业务使用redis过程中,出现了read timeout 的异常. 问题排查 直接原因 运维查询redis慢查询日志,发现在异常时间节点,有redis慢查询日志,执行sadd 命令花费了1秒钟.但由于redis是单线程应用,执行单条命令的阻塞,会造成其他命令的排队等候,导致read timeout. 深入排查-为什么sadd这么慢呢 为什么sadd这么慢呢?查阅redis文档看到,sadd操作的复杂度是O(1)的,实际使用本机docker搭建redis进行测试,使用脚本进行sadd,…

项目一直使用grpc作为服务交互程序,其中我负责的java模块第一次引用该框架:当框架搭建好后,建立客户端代码,报错: Runable Error:java.lang.IllegalAccessError: tried to access field XXXXXXXXXXXXXXXXXXXXXX at com.scut.fan.infrastructure.ftree.NewRequest$getMemoriedcount(.java:142) 首先我们看下该异常的信息: package jav…

问题描述 应用收到频繁Full GC告警 问题排查 登录到对应机器上去,查看GC日志,发现YGC一分钟已经达到了15次,比Full GC还要频繁一些,其中Full GC平均10分钟超过了4次,如下图 使用jstat -gcutil 5280 1000查看实时GC情况,年老代采用的是CMS收集器,发现触发Full GC的原因是年老代占用空间达到指定阈值70%(-XX:CMSInitiatingOccupancyFraction=70). 这时候猜测是某个地方频繁创建对象导致,通过jmap -dum…

一次生产系统Full GC问题分析与排查总结 背景 最近某线上业务系统生产环境频频CPU使用率过低,频繁告警,通过重启可以缓解,但是过了一段时间又会继续预警,线上两个服务节点相继出现CPU资源紧张,导致服务器卡死不可用,通过告警信息可以看到以下问题: 从上图可以看到,目前zabbix监控展示CPU空闲时间已经低于预警线,证明目前CPU资源占用过高,考虑到最近并没有特别开发任务上线,但是最近有发布过一个新的营销活动,有可能是因为突然用户量增长进一步凸显该问题. 从Pinpoint APM监控工具看…