牺牲cpu减少fullgc暂停时间vm参数配置

最新推荐文章于 2024-07-19 11:19:42 发布
原创 最新推荐文章于 2024-07-19 11:19:42 发布 · 227 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#fullgc #java #opt 

-Xms4096m -Xmx4096m -XX:PermSize=256m -XX:NewSize=384m -XX:NewRatio=4 -XX:+UseParNewGC -XX:ParallelGCThreads=4 -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=80 -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSFullGCsBeforeCompaction=5 -Xloggc:/logs/gc.log -XX:+ExplicitGCInvokesConcurrent -XX:+PrintGCDetails -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime
JVM高频面试基本问题与知识点整理
曾经“等你生日那天”都遥远得像未来，如今却可欢愉的挥手说“下个十年见”
01-16 86万+
JVM高频面试基本问题与知识点整理
JVM 问题排查分析下篇（案例实战）
KimmKing的技术博客
09-22 657
GC 问题排查实战案例 这一部分，我们来看一个实际的案例。 假设我们有一个提供高并发请求的服务，系统使用 Spring Boot 框架，指标采集使用 MicroMeter，监控数据上报给 Datadog 服务。 当然，Micrometer支 持将数据上报给各种监控系统，例如：AppOptics、Atlas、Datadog、Dynatrace、Elastic、Ganglia、Graphite、Hum...
JVM初探- 使用堆外内存减少Full GC
菜鸟-翡青
01-13 1万+
使用堆外内存减少Full GC - JVM 大部分主流互联网企业线上Server JVM选用了CMS收集器(如Taobao、LinkedIn、Vdian), 虽然CMS可与用户线程并发GC以降低STW时间, 但它也并非十分完美, 尤其是当出现Concurrent Mode Failure由并行GC转入串行时, 将导致非常长时间的Stop The World
JVM调优—减少FullGC
weixin_38829588的博客
05-10 2018
最近负责了一个审批流程新项目，带领了几个小伙伴，哼哧哼哧的干了3个月左右，终于在三月底完美上线了，好消息是线上客户用的很丝滑，除了几个非常规的业务提单之外，几乎没有什么大的问题，但是美中不足的是，发现每个pod的GC频率非常高，基本上30分钟就会有一次FGC，导致每次流量高峰的时候，会有一部分客户反馈，系统有些卡顿，观察监控平台发现，每天流量高峰的时候FGC竟然达到了惊人的5分钟每次，每次GC的时间差不多有400-700ms，此时，部分接口的耗时达到了5s，因此接口优化和参数调优迫在眉睫；
full gc_减少主要GC暂停的频率
cunfen8879的博客
12-17 364
full gc 这篇文章将讨论一种减少负担的应用程序延迟的垃圾收集暂停技术。 正如我几年前所写，在JVM中无法禁用垃圾收集。 但是，有一个巧妙的技巧可以用来大大减少长时间停顿的时间和频率。 如您所知，JVM中发生了两个不同的GC事件，称为次要和主要集合。 关于这些收集期间发生的事情，有很多可用的材料，因此，我将不着重于详细描述其机制。 我只想提醒一下，在Hotspot JVM中-在次要收集期...
Hadoop运行MapReduce任务时，异常及解决方案
累迹的博客
02-03 1万+
异常代码描述 刚刚开始接触Hadoop，对于MapReduce并不时特别了解，以下记录以下纠结了一天的问题及解决方案 1、执行MapReduce任务 hadoop jar wc.jar hejie.zheng.mapreduce.wordcount2.WordCountDriver /input /output 2、跳出异常 Task failed task_1643869122334_0004_m_000000 [2022-02-03 15:10:59.255]Container killed on
【JVM】JVM内存模型/内存布局
lp15929801907的博客
11-16 406
JVM的内存模型/内存布局
JVM GC停顿引发CPU波动？G1与ZGC日志分析的6大关键指标
![CPU负载分析与优化方法]...在高并发Java应用运行过程中，JVM的垃圾回收（GC）行为不仅直接影响应用的响应延迟，还会引发显著的CPU使用率波动。GC线程与
G1调优参数精讲：MaxGCPauseMillis与IHOP实战配置的4大坑点警示
# G1垃圾回收器调优：从参数迷雾到生产实战的深度穿越 在某个风和日丽的下午，你正准备收工下班。突然钉钉群炸了——“线上接口P99飙升至800ms！”、“GC停顿突破300ms红线！”、“用户投诉下单卡顿！”……一连串...
Java GC垃圾回收
qq_63353796的博客
07-19 1005
GC垃圾回收
JVM优化-如何减少FullGC
屎壳郎先生
05-23 6558
面试，实战利器。 优化的重点就是尽量不要让对象进入老年代。如果对象进不去老年代，想Full GC都难。这是JVM调优的重点。（当然了引起fullgc的还有元空间满了 or 堆外空间满了）
关于fullGC的总结
xerjava的专栏
01-09 1060
1. 描述 相对的是youngGC 源于Java堆的内存结构：分代，新生代和老年代 fullGC即在新生代和老年代都进行垃圾回收 2. fullGC的影响 GC过程中导致服务不可用，降低吞吐率 3. 如何降低fullGC带来的影响 fullGC长起来可达到5~6s 从降低fullGC频率和减少fullGC时长的角度，考虑降低其带来的影响 减少fullGC时长 降低fullGC频率...
JVM的XX参数之布尔类型 || KV设值类型
qq_39368007的博客
03-10 142
JVM性能案例
mayrose01的博客
05-04 398
案例一：回收器选择不当导致频繁FGC 【问题描述】 使用单台8C8G压力机Jmeter压测A系统，约3mins内存就占满4G，频繁出现FGC。 【性能场景】 单机模式下，使用500并发持续压测http明文接口； 默认jvm配置：-Xms1024m -Xmx2048m -XX:NewSize=512m。 【分析和调优过程】 1...
java GC调优
三省吾身，每天都是新的
12-08 5630
原帖地址：http://arbow.javaeye.com/blog/362861由于Boss看了某JVM GC调整的文章，兴致大发叫嚷要对我们的服务进行调优，于是开始了一次调优经历。由于服务是属于非后台计算类型，因此抛弃了并行回收策略，而使用并发回收，对年轻代做并行回收，年老代做并发回收，参数引用-Xms2048m -Xmx2048m -Xmn512m -XX:Paral
什么时候对象进入老年代？什么时候触发Full GC？如何减少长时间的 GC 停顿？
yanghenan19870513的专栏
04-13 3988
1. Minor GC 和 Full GC 的含义及区别？ Minor GC（新生代GC）：指发生在新生代的垃圾收集动作，新生代中的对象朝生夕死，所以 Minor GC 非常频繁，回收速度也比较快。 Full GC（老年代GC）：指发生在老年代的GC，速度一般比 Minor GC 慢十倍以上。如果有Full，说明这次GC发生了Stop-The-World。 2. 什么时候对象进入老年代？ 大对象直接进入老年代。 虚拟机提供了一个阈值参数，令大于这个设置值的对象直接在老年代中分配。如果大对象进入新生代，
一次线上JVM调优实践，FullGC40次/天到10天一次的优化过程
热门推荐
believer123的专栏
07-15 3万+
对于JVM垃圾回收，之前一直都是处于理论阶段，就知道新生代，老年代的晋升关系，这些知识仅够应付面试使用的。前一段时间，线上服务器的FullGC非常频繁，平均一天40多次，而且隔几天就有服务器自动重启了，这表明的服务器的状态已经非常不正常了，得到这么好的机会，当然要主动请求进行调优了。未调优前的服务器GC数据，FullGC非常频繁。 首先服务器的配置非常一般（2核4G），总共4台服务器集群。每...
如何配置JVM参数避免FullGC
最新发布
10-24
<think>首先，用户的问题是基于之前的上下文：用户正在询问如何配置JVM参数以避免Full GC。他们提供了几个引用，这些引用讨论了频繁Full GC的原因和解决方案，包括调优JVM参数。 我的系统指令： - 所有行内数学表达式使用$...$格式（但这里可能不需要数学表达式，因为主题是JVM参数）。 - 独立公式用$$...$$（同样，可能不适用）。 - LaTeX语法正确（需要确保）。 - 使用中文回答。 - 生成相关问题。 - 回答中引用的段落末尾自然地添加引用标识，如[^1]。 用户指令： - 回答结构清晰，帮助用户逐步解决问题。 - 尽量保证回答真实可靠。 用户的问题是：“我想查找配置JVM参数以避免FullGC的方法 请问配置JVM参数避免FullGC的方法” 参考了三个引用： - [^1]: 提到调整JVM参数、选择合适的GC策略等。 - [^2]: 具体参数示例：-Xms4g -Xmx4g -Xmn2g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -XX:+UseG1GC。 - [^3]: 提到合理配置JVM参数、优化GC算法等。 我需要基于这些构建一个结构清晰的回答，帮助用户逐步解决配置JVM参数以避免Full GC的问题。 关键点从引用中提取： - 设置堆大小：-Xms（初始堆大小）、-Xmx（最大堆大小）、-Xmn（年轻代大小）。 - 元空间设置：-XX:MetaspaceSize、-XX:MaxMetaspaceSize。 - 选择合适的垃圾收集器：如G1GC，可以减少Full GC。 - 其他：避免内存泄漏、减少对象创建等（虽然不是直接参数配置，但相关）。 步骤结构： 1. **理解问题**：解释Full GC的原因（简要）。 2. **关键JVM参数配置**： - 堆内存设置：-Xms, -Xmx, -Xmn。 - 年轻代和老年代比例。 - 垃圾收集器选择：推荐G1GC。 - 元空间设置。 - 其他参数如-XX:+UseConcMarkSweepGC（如果使用CMS）。 3. **示例配置**：提供基于引用的示例。 4. **监控和调整**：建议监控GC日志来优化。 5. **相关优化**：简要提到代码优化以避免内存泄漏。 6. **生成相关问题**：在结尾生成相关问题。 使用中文回答。 自然地添加引用标识：在引用的部分末尾加[^1], [^2], [^3]。 例如，当提到参数时，引用[^2]提供的示例。 完整回答结构： - 引言：回应问题。 - 逐步指南： - 步骤1: 设置堆大小。 - 步骤2: 配置年轻代和老年代。 - 步骤3: 选择GC收集器。 - 步骤4: 元空间设置。 - 步骤5: 其他优化。 - 示例配置。 - 监控和调整建议。 - 相关问题。 确保回答真实可靠：基于标准JVM调优实践和提供的引用。 </think>### 配置JVM参数避免Full GC的方法 Full GC（Full Garbage Collection）是Java虚拟机（JVM）垃圾回收过程中的一个重负担阶段，频繁发生会导致应用性能下降。这通常与内存设置不当、垃圾收集器配置不合适或内存泄漏有关[^1][^3]。通过合理配置JVM参数，可以有效减少Full GC的发生频率。以下是一个结构清晰的逐步指南，帮助你逐步解决问题。每一部分都基于实际调优原则，确保安全可靠。 #### 步骤1: **设置堆内存大小** 堆内存是JVM中对象存储的主要区域，不当设置会触发不必要的Full GC。需要平衡初始堆大小和最大堆大小，避免频繁扩容或内存耗尽。 - **关键参数**： - `-Xms<size>`：设置初始堆大小（例如，`-Xms4g`表示4GB）。 - `-Xmx<size>`：设置最大堆大小（例如，`-Xmx4g`表示4GB）。 建议将`-Xms`和`-Xmx`设置为相同值以减少堆大小调整时的开销[^2]。如果应用内存需求大，可以增加大小；但避免过大，以免增加GC停顿时间。 - **为什么有效**：稳定的堆大小减少内存波动，降低Full GC触发频率[^1]。 #### 步骤2: **配置年轻代和老年代比例** 年轻代（Young Generation）和老年代（Old Generation）的比例直接影响GC行为。年轻代太小会导致对象过早晋升到老年代，增加Full GC风险。 - **关键参数**： - `-Xmn<size>`：设置年轻代大小（例如，`-Xmn2g`表示年轻代占2GB）。 - 建议年轻代占堆总大小的1/3到1/2（例如，总堆4GB时，设置`-Xmn2g`）。年轻代中，可进一步调整Eden区和Survivor区比例，如`-XX:SurvivorRatio=8`（Eden:Survivor=8:1）。 - **为什么有效**：优化年轻代回收（Minor GC），减少对象过早进入老年代，从而避免Full GC[^2][^3]。 #### 步骤3: **选择合适的垃圾收集器** 垃圾收集器的选择对Full GC频率有重大影响。G1收集器（Garbage-First）适合大内存场景，能并发处理回收任务，减少Full GC停顿。 - **关键参数**： - `-XX:+UseG1GC`：启用G1收集器（默认在Java 9+）。 - 如果使用其他收集器（如CMS），推荐切换到G1：`-XX:+UseG1GC`。 - 对于CMS收集器，可添加`-XX:+UseConcMarkSweepGC`并设置`-XX:CMSInitiatingOccupancyFraction=70`（老年代使用率70%时触发CMS）。 - **为什么有效**：G1收集器能并行处理老年代回收，减少Full GC的发生[^2][^3]。 #### 步骤4: **设置元空间大小** 元空间（Metaspace）存储类元数据，如果不足会触发Full GC。合理设置元空间限制可以避免溢出。 - **关键参数**： - `-XX:MetaspaceSize=<size>`：初始元空间大小（例如，`-XX:MetaspaceSize=256m`）。 - `-XX:MaxMetaspaceSize=<size>`：最大元空间大小（例如，`-XX:MaxMetaspaceSize=512m`）。 - **为什么有效**：防止元空间频繁扩容导致的Full GC[^2]。 #### 步骤5: **其他优化参数和注意事项** 除了核心参数，还需结合应用场景优化： - **避免大对象**：添加参数`-XX:PretenureSizeThreshold=1m`，将大对象直接分配到老年代，减少年轻代压力。 - **监控和日志**：启用GC日志分析：`-Xloggc:gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps`，使用工具如GCViewer分析日志。 - **代码优化**：减少不必要的对象创建和内存泄漏，避免长期持有大对象，这能辅助参数调优[^1][^3]。 - **一般建议**：从保守参数开始测试，逐步调整。例如，使用以下基准配置测试： ```bash -Xms4g -Xmx4g -Xmn2g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m -XX:+UseG1GC ``` 然后根据应用负载（如高并发或大数据处理）微调[^2]。 #### 监控和验证 配置后，务必监控GC行为： - 使用JVisualVM或Arthas工具实时查看GC活动。 - 检查日志：如果Full GC频率未下降，检查是否有内存泄漏（例如，使用`jmap -histo`分析对象分布）。 - 参考最佳实践：如Oracle官方JVM调优指南。 通过以上步骤，大多数应用能显著减少Full GC。但记住，参数调优需结合应用特点测试；如果仍有问题，可能需要深入排查代码或升级JVM版本[^1][^2][^3]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值