问题描述 应用收到频繁Full GC告警 问题排查 登录到对应机器上去,查看GC日志,发现YGC一分钟已经达到了15次,比Full GC还要频繁一些,其中Full GC平均10分钟超过了4次,如下图 使用jstat -gcutil 5280 1000查看实时GC情况 ...
这个是之前处理过的一个线上问题,处理过程断断续续,经历了两周多的时间,中间各种尝试,总结如下。这篇文章分三部分: 问题的场景和处理过程 GC的一些理论东西 看懂GC的日志 先说一下问题吧 问题场景:线上机器在半夜会推送一个 M左右的数据,这个时候有个数据置换的过程,也就是说有 M 的数据在heap区域中,线上系统超时比较多,导致了很严重 严重程度就不说了 的问题。 问题原因:看日志,系统接口超时的 ...
2018-05-07 09:35 0 1362 推荐指数:
问题描述 应用收到频繁Full GC告警 问题排查 登录到对应机器上去,查看GC日志,发现YGC一分钟已经达到了15次,比Full GC还要频繁一些,其中Full GC平均10分钟超过了4次,如下图 使用jstat -gcutil 5280 1000查看实时GC情况 ...
本文翻译自: https://blogs.oracle.com/poonam/entry/understanding_cms_gc_logs 准备工作 JVM的GC日志的主要参数包括如下几个: -XX:+PrintGC 输出GC日志 -XX:+PrintGCDetails 输出GC的详细日志 ...
问题发现场景 某天突然收到线上应用的gc时间过长的告警,刚开始只有一台机器偶尔报一下,后续其他机器也纷纷告警,具体告警的阈值是应用10分钟内ygc的总时长达到了6.6s。 初步排除过程 按照gc问题常规排查流程,还是先保留现场,jmap -dump:format=b,file ...
背景说明 组织架构被拆分为多个微服务 需求: 一个输入框 查询 前后模糊查询 人员信息(工号、姓名),前后模糊查询 单位名称。 跨库平级查询!! ...
上周运维反馈线上程序出现了OOM,程序日志中的输出为 看线程名称应该是tomcat的nio工作线程,线程在处理程序的时候因为无法在堆中分配更多内存出现了OOM,幸好JVM启动参数配置了-XX:+HeapDumpOnOutOfMemoryError,使用MAT打开拿到的hprof文件进行分析 ...
近期需要对公司的接口做线上的巡查监控,需要写一个脚本放到服务器上,定时运行脚本监测线上接口是否正常。测试的接口不是HTTP协议,而是公司基于TCP协议开发的私有协议,因此不能直接用现成的一些接口测试工 ...
大家好,我是雨乐! 前几天,突然收到报警,线上服务崩溃,然后自动重启。 由于正值双十一期间,业务以稳定为主,线上服务崩溃,这可不是一件小事,赶紧登陆线上服务器,分析原因,迅速解决。 借助这篇文章,记录下整个崩溃的分析和解决过程。 收到报警 上午上班后,正在划水,突然收到邮件报警 ...
上周晚上,某环境 ES 出现阻塞, 运行缓慢。于是开始排查问题的过程。 开始 思路:现象是阻塞,通常是 CPU 彪高,导致业务线程分配不到 CPU 时间片,或者内存吃紧,频繁 GC 导致的 STW。 登录到目标服务器,由于 ES 的用户不是 LZ,因此找运维要了 root 权限,登录到服务器 ...