一次 gc 日志分析

纯干货:线上出现fullGC次数很多的排查思路以及实践总结 最近线上发布了一个版本,导致full gc次数忽然就上去了,虽然对线上业务造成的影响还不是很大,但是为了以防万一还是对这个问题做了相关排查。 GC命令排查 一开始还是从堆的变化开始: # 查看每秒的堆发生的变化以及gc的次数 jstat -gcutil pid 1000 相关参数: s0 : Heap上的 Survivor space 0 区已使用空间的百分比 s1 : Heap上的 S... 阅读详情

/**
* -XX:NewSize=5242880
* -XX:MaxNewSize=5242880
* -XX:InitialHeapSize=10485760
* -XX:MaxInitialHeapSize=10485760
* -XX:SurvivorRatio=8
* -XX:PretenureSizeThreshold=10485760
* -XX:+UseParNewGC
* -XX:+UseConcMarkSweepGC
* -XX:+PrintGCDetails
* -XX:+PrintGCTimeStamps
* -Xloggc:gc.log
* @param args
*/
public static void main(String[] args) {
/**CommandLine flags: -XX:InitialHeapSize=10485760 -XX:MaxHeapSize=10485760 -XX:MaxNewSize=5242880 -XX:NewSize=5242880 -XX:OldPLABSize=16 -XX:PretenureSizeThreshold=10485760 -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:SurvivorRatio=8 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
0.133: [GC (Allocation Failure) 0.133: [ParNew: 3826K->471K(4608K), 0.0010332 secs] 3826K->1497K(9728K), 0.0011436 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
par new generation total 4608K, used 3705K [0x00000007bf600000, 0x00000007bfb00000, 0x00000007bfb00000)
eden space 4096K, 78% used [0x00000007bf600000, 0x00000007bf928670, 0x00000007bfa00000)
from space 512K, 92% used [0x00000007bfa80000, 0x00000007bfaf5f98, 0x00000007bfb00000)
to space 512K, 0% used [0x00000007bfa00000, 0x00000007bfa00000, 0x00000007bfa80000)
concurrent mark-sweep generation total 5120K, used 1026K [0x00000007bfb00000, 0x00000007c0000000, 0x00000007c0000000)
Metaspace used 3197K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 352K, capacity 388K, committed 512K, reserved 1048576K
**/

    // 先说下我们设置的 gc 参数.
    // 1.新生代大小为 5M(Eden 区 4M,s0 为 0.5M)
    // 2.堆内存为 10M
    // 3.大对象进入老年代阈值为 10M
    // 4.新生代使用 ParNew
    // 5.老年代使用 CMS
    // 6.打印详细 gc 日志
    // 7.打印每次 gc 发生的时间
    // 8.将 gc 日志写入文件.

    // 第一个 0.133 是分配失败的时间.
    // 第二个 0.133 是新生代发生 gc 的时间,使用 ParNew 新生代收集器,总量为 4608->4.5M
    // 使用量为 3826 -> 3.7M 左右. 一开始在新生代创建了 3 个 1M 的对象,然后失去引用,变成垃圾.
    // 有人会问,不应该是 3M 吗?那个 1M 只是数据部分,JVM 还会创建其他的东西,比如对象头等数据结构.
    // 471K 是 gc 剩下的大小.
    // 0.0010332 本次 gc 耗时.
    // 后面那个 3826 是堆内存的变化
    int ONE_M = 1024 * 1024;
    byte[] array1 = new byte[ONE_M];
    array1 = new byte[ONE_M];
    array1 = new byte[ONE_M];

    array1 = null;

    byte[] array2 = new byte[2 * ONE_M];
}
Java垃圾收集器:ParNew收集器的编程指南 通过配置相关的Java虚拟机参数,我们可以启用ParNew收集器,并使用多线程并行地进行新生代的垃圾回收。ParNew收集器是Java虚拟机中的一种垃圾收集器,用于新生代的垃圾回收。它是基于标记-复制算法的收集器,具有多线程的能力,可以并行地进行垃圾回收操作。本文将介绍ParNew收集器的使用方法,并提供相关的示例代码。在垃圾回收过程中,首先进行标记阶段,遍历所有的根对象,并标记所有与根对象可达的对象。要使用ParNew收集器,首先需要在Java虚拟机的启动参数中进行相应的配置。ParNew收集器的配置。 阅读详情

相关推荐

NVIDIA驱动装好了,Gazebo为啥还是卡?手把手教你用optirun搞定GPU加速

本文详细解析了NVIDIA驱动安装后Gazebo仍卡顿的原因,并提供三步精准诊断与GPU加速实战方案。通过optirun快速启用GPU加速,解决OpenGL与显示服务器的配置问题,显著提升仿真性能。适用于ROS、PX4等开发环境,帮助用户充分利用显卡性能。

weixin_30379531的博客 465

JVM 垃圾回收器

垃圾回收器

qianqia_n的博客 2983

多目标跟踪(MOT)中的卡尔曼滤波(Kalman filter)和匈牙利(Hungarian)算法详解

多目标跟踪(MOT)中的卡尔曼滤波(Kalman filter)和匈牙利(Hungarian)算法详解 1. 概览 在开始具体讨论卡尔曼滤波和匈牙利算法之前,首先我们来看一下基于检测的目标跟踪算法的大致流程。 2. 卡尔曼滤波(Kalman filter) 目标跟踪中使用的就是最基础的 Kalman filter 算法。这里也仅仅讨论最基础的 Kalman filter 算法。 卡尔曼滤波算法的过程很简单,如下图所示。最核心的两个步骤就是预测和更新(下图的 correct)。 在目标跟踪任务中,目标的

生命在于折腾! 2万+

GC参数解析 UseSerialGC、UseParNewGC、UseParallelGC、UseConcMarkSweepGC

因为为java语言提供支持的虚拟机有很多,不同虚拟机提供的垃圾收集器差别很大。这里讨论的收集器基于JDK1.7 Update14之后的HotSpot虚拟机。这个虚拟机包含的所有垃圾收集器如下图 -XX:+UseSerialGC 使用串行回收器进行回收,这个参数会使新生代和老年代都使用串行回收器,新生代使用复制算法,老年代使用标记-整理算法。Serial收集器是最基本、历史最悠久的收集器,它是一个...

leo187的博客 3万+

软件测试方法——等价类划分法详解

!如果下面这些资料用得到的话可以直接拿走:1、自学开发或者测试必备的完整项目源码与环境2、测试工作中所有模板(测试计划、测试用例、测试报告等)3、软件测试经典面试题4、Python/Java自动化测试实战.pdf5、Jmeter/postman接口测试全套视频获取6、Python学习路线图。

MXB1220的博客 1万+

关于VS2019调试问题:进程已退出,代码为-1073741819(已解决)

关于VS2019调试问题:进程已退出,代码为-1073741819(已解决) 详情:上一篇发了这个进程问题,在我翻阅了《c语言程序设计第四版》和《算法与数据结构》两本书对照代码加上调试终于找到了解决方法 解决方法: 首先找到项目的源文件右击找到属性 然后选择从生成中排除选择是! 重新生成解决方案,发现代码问题: 之前的代码: #include <stdio.h> #include <stdlib.h> #include <malloc.h> #include &lt

qq_51553982的博客 1万+

【JVM垃圾回收】GC 调优

调优领域: 内存 锁竞争 CPU占用 IO GC 确定目标: 低延迟/高吞吐量?选择合适的GC 并发收集器: CMS G1 ZGC 并行收集器: Parallel GC Zing 七大垃圾收集器: 1、串行GC:Serial收集器(1:1) 串行收集器是最古老的,最稳定,效率高的收集器,只使用一个线程去回收但其进行垃圾回收过程中可能会产生较长的停顿。虽然在收集垃圾的过程中需要暂停其他的工作线程,但是简单高效,对于单CPU环境来说,没有线程交互的开销可以获得最高的单线程垃圾收集效率。 2、并行GC:

太阳的博客 622

实用工具抓取youtube热门数据

YouTube作为全球第二大搜索引擎,2024年日均视频播放量突破50亿次,头部创作者单月广告分成可达百万美元量级。但对数据分析者而言,其反爬机制堪称业界最严: ‌反爬技术升级‌:Google部署的Botguard系统可检测异常流量,触发机制包括: 单IP每小时请求超过50次即封禁 检测Headless浏览器指纹(如Chrome的navigator.webdriver属性) 动态加载内容(如评论数据需滚动页面3次后加载) ‌数据价值维度‌:某MCN机构研究显示,前100热门视频的标题关键词复用率高达67%

26万+

【JVM】垃圾回收 GC

垃圾回收(Garbage Collection,GC)是由 Java 虚拟机(JVM)垃圾回收器提供的一种对内存回收的一种机制,它一般会在内存空闲或者内存占用过高的时候对那些没有任何引用的对象不定时地进行回收。以避免内存溢出和崩溃的问题。JVM的垃圾回收算法包括引用类型、引用计数器法、可达性分析算法和标记-清除算法等。

weixin_40381772的博客 2629

YOLOv12改进策略【模型轻量化】| 替换骨干网络为EfficientNet v1 高效的移动倒置瓶颈结构

本文记录的是基于。采用了创新性的方法,通过精心平衡网络和来提升性能。本文将的设计优势融入YOLOv12中,提升YOLOv12的性能与效率,使其在目标检测任务中表现更为出色。本文配置了原模型中的共种不同大小的模型结构,以满足不同的需求。

Limiiiing的博客 963

【Claude Code】Not logged in 未登录错误解决方案 + /login 认证路径

Claude Code 启动时提示 Not logged in 表示当前会话缺少有效凭证。本文从环境变量、API Key 配置、CI 自动化凭证脚本和系统时钟四个维度,提供完整的认证排查流程与修复方案。

多媒体编程、网络编程、系统编程、网络安全编程、驱动编程 892

一次Full GC 过程的日志分析

基础概念: Full GC,新生代,旧生代和持久代都发生GC,说明这次GC是发生了Stop-The-World的 ParNew GC发生区域,和收集器有关,这里是ParNew收集器,如果为Serial收集器,则显示DefNew。如果Parallel Scavenge收集器,那它配套的新生代称为“PSYoungGen” GC 332674.627 后面的数字为JVM启动后到现在的时间 419

天烬的专栏 9236

基于STM32L4XX、HAL库的RTL8201F 以太网收发器(PHY)驱动程序设计

define PHY_RESET_DELAY 1000 // PHY复位延迟(ms)#define PHY_AUTONEGO_DELAY 3000 // 自动协商延迟(ms)/* 检查PHY ID (RTL8201F的ID为0x001CC816) *//* 系统时钟配置,确保ETH有50MHz时钟 *//* 初始化CPU, AHB和APB总线时钟 */

zhusl6688的博客 803

记一次JVM GC日志分析

这几天在准备升级JDK版本到1.6,对目前线上JVM(版本是1.5.0_08-b03) GC日志进行了分析,发现一些参数设置不太合理的地方,有待后续通过数据来进行验证。 1.原始GC日志(通过JVM配置GC Print参数获取GC日志) ... 695.775: [GC 695.776: [ParNew: 130944K->0K(131008K), 0.0174100 secs] 43296

海阔天空 2万+

SAP B1中文培訓教材_SDK

公司内部培训资料,对开发工具 ,DIAPI, UIAPI,Add-ON有详细解说

IMSL CNL 7.0.0 (x86-64)Crack

IMSL CNL 7.0.0 (x86-64)Crack intel的算法库破解文件,这是C++版本的破解文件

记一次JVM GC日志分析(中间给出了部分的JVM配置参数)

这几天在准备升级JDK版本到1.6,对目前线上JVM(版本是1.5.0_08-b03) GC日志进行了分析,发现一些参数设置不太合理的地方,有待后续通过数据来进行验证。 1.原始GC日志(通过JVM配置GC Print参数获取GC日志) ... 695.775: [GC 695.776: [ParNew: 130944K->0K(131008K), 0.0174100 secs]

可口可乐的博客 1067

汉书HE8,好用的汇编代码编写工具

汉书HE8,好用的汇编代码编写工具早期编写汇编代码所用功能强大

为什么JVM每隔一小时执行一次Full GC_

随着接口自动化监控的完善,线上大多数的接口都被自动化监控系统接入,因此开发、测试人员可以及时的了解API的健康情况,监控内容包括检查API的状态码是否正常、返回的内容断言是否成功等,异常的接口会对外发出报警信息,从某个时间周期开始我们发现了报警内容的一些异常情况,每天都会收到一些接口状态码为502的报警。 报警信息由自动化监控系统发给钉钉报警群 根据报警的时间我们查了对应服务的日志,并没有发现有任何的异常信息,跟运维同学沟通后,在这个时间上运维那边也并没有对Tomcat、Nginx做相关操作,由于也.

guixiang155cm的专栏 2270

SIMATIC S7-1200, S7-1500 PID 控制[手册]

SIMATIC S7-1200, S7-1500 PID 控制[手册]

Metaspace GC 问题排查

背景描述 查看应用JVM监控发现发生了连续两次 Full GC,导致 GC 的原因是什么? Full GC 监控: metaspace利用率监控: 问题排查 环境信息 生产环境,JDK1.8 关键JVM参数: -Xms4g -Xmx4g -Xmn2g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -XX:MaxDirectMemorySize=1g -XX:SurvivorRatio=10 -XX:+UseConcMarkSweepGC -XX:CM

森伯416的博客 4397

JVM调优实战:一次GC风暴的排查与优化全记录

一次高并发金融交易系统的JVM调优过程。系统在大促期间出现Full GC频繁(2-3次/分钟)、响应时间飙升至2秒以上等问题。通过监控分析、GC日志排查和堆转储解析,发现OrderCache未设置过期策略导致内存泄漏。优化方案包括:引入Caffeine缓存(限制大小和过期时间)和调整G1GC参数(MaxGCPauseMillis=100、IHOP=35等)。最终Full GC降至每小时不足1次,停顿时间从500ms降至8ms,吞吐量提升300%。总结指出80%性能问题源于代码设计,强调监控先行、代码优先的调

刘一说的IT专栏 1191

一次 Young GC 的优化实践

这个 GC 案例比较有意思,排查问题有点像侦探断案,先分析各种可能性,再按照获得的一个个证据,去排除各种可能性、然后定位原因,最终解决问题。 问题 某同学在微信上问我,有没有办法排查 YoungGC 效率低的问题?听到这话,我也是不知从何说起,就让他说下具体情况。 具体情况是: 有个服务在没有 RPC 调用时,YoungGC 时间大约在 4-5ms,但是有 RPC 调用时,YoungGC 的耗时在 40ms 以上,几乎没有什么对象晋升,频率 4-5 秒一次。GC 日志截图如下。 后来他为了排查问题.

varyall的专栏 895

年轻代频繁ParNew GC,导致http服务rt飙高

背景介绍 某日下午大约四点多,接到合作方消息,线上环境,我这边维护的某http服务突然大量超时(对方超时时间设置为300ms),我迅速到鹰眼平台开启采样,发现该服务平均QPS到了120左右,平均RT在2秒多到3秒,部分毛刺高达5到6秒(正常时候在60ms左右)。 qps情况: rt情况 问题解决 该服务是一个对内的运营平台服务(只部署了两台docker)预期qps个位数,近期没做过任何的线上发布,核心操作是整合查询数据库,一次请求最多涉及40次左右的DB查询,最终查询结果为一个多层树形结构

码农架构 4729

g-rmi_RMI强制Full GC每小时运行一次

g-rmi 在我职业生涯中进行的所有故障排除练习中,我都感觉到,随着时间的推移,我所追寻的错误在不断发展,并且变得越来越卑鄙和丑陋。 也许只是我的年龄开始了。这个特别的Heisenbug –看起来像这篇帖子一样,再次让我清醒了很多,而不是我想要的。 与其他特别令人讨厌的错误一样,我现在遇到的那个错误的症状是“有时系统运行缓慢”。 太好了,我已经感到脊椎发麻。 当我发现系统在生产中设置了一个简单...

cunfen8879的博客 269

通过btrace排查线上频繁Full GC的case

概述 又是一次因为线上报警机制开启的排查问题之旅。某日,钉钉机器人疯狂报警: 接着就是申请机器权限去排查问题,既然是频繁Full GC,那我们排查问题的思路就应该是找到引起Full GC的原因。引起频繁Full GC的常见原因有这么几点: 堆外内存达到阈值,将会调用System.gc()来做一次Full GC。这里说的堆外内存主要说的是nio下的DirectByteBuffer,它会通过Un...

hellozhxy的博客 504

一次非典型的CPU告警的排查

最近线上频繁收到CPU超过阈值的告警, 很明显是哪里出了问题. 于是排查了一番, 到最后找到罪魁祸首的时候, 突然意识到这次是一次很有意思的"非典型"的CPU的问题, 所以这里特意记录一下. 为啥说它是非典型呢, 因为在我的经验里, 典型的CPU飙升通常都是业务代码里面有死循环, 或是某个RPC性能过低阻塞了大量线程等等, 而这次的CPU问题却是由GC引起的, 因吹斯汀 来看看排查过程 找出占用C...

lonely_bin的博客 1662
上一篇: Mybatis PagerHelper 实现原理
下一篇: JVM参数优化及OOM故障分析步骤
^一剪梅^
博客等级 码龄12年 4粉丝 74原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值