unknown option or illegal argument:-XX:OnOutOfMemoryError=kill

最新推荐文章于 2023-12-05 23:31:33 发布
最新推荐文章于 2023-12-05 23:31:33 发布 · 1.1k 阅读 · 0
文章标签：

#java #大数据

部署运行你感兴趣的模型镜像
安装Hbase时候（hbase-0.94.8）报错：
unknown option or illegal argument:-XX:OnOutOfMemoryError=kill

搞了半天是jdk版本不支持，原来是1.6.0_20-b02换成1.6.0_13-b03即可。

您可能感兴趣的与本文相关的镜像

Stable-Diffusion-3.5

Stable-Diffusion-3.5

图片生成
Stable-Diffusion

Stable Diffusion 3.5 (SD 3.5) 是由 Stability AI 推出的新一代文本到图像生成模型，相比 3.0 版本，它提升了图像质量、运行速度和硬件效率

第32课：Spark Worker原理和源码剖析解密：Worker工作流程图、Worker启动Driver源码解密、Worker启动Executor源码解密等
大模型与Agent智能体
05-25 1029
第32课：Spark Worker原理和源码剖析解密：Worker工作流程图、Worker启动Driver源码解密、Worker启动Executor源码解密等本节基于Spark 2.1版本从四个方面解密Spark Worker的运行原理和源码:1，Spark源码剖析 2，Worker启动Driver源码，Worker接收Master的指令启动Driver。3，Worker启动Executor源码4
12C ORA-错误汇总1 ORA-00000 to ORA-00877
ugghhj的博客
11-10 1733
12C ORA-错误汇总1 ORA-00000 to ORA-00877
java %p_java – -XX：OnOutOfMemoryError =“kill -9％p”问题
weixin_39623750的博客
02-18 2574
尝试将-XX：OnOutOfMemoryError =“kill -9％p”命令传递到我的jvm参数中有一个问题。我正在使用Jetty7，并在start.ini文件中。在启动它给我以下错误。这是与jre /jre1.6.0_03l64Starting Jetty: STARTED Jetty Tue Apr 26 09:54:26 EDT 2011Unrecognized option: -9Co...
对OnOutOfMemoryError的运维处理
baochuqiong3886的博客
07-06 1368
以部署在linux系统/opt/Server目录下的Server.jar为例 1.在run.sh启动脚本中添加jvm参数： -XX:OnOutOfMemoryError=/opt/Server/restart.sh 2.restart.sh脚本 linux环境： #!/bin/bashpid=$(ps -ef|grep Server.jar|awk '{if($8=="java...
-XX:HeapDumpOnOutOfMemoryError 内存溢出
热门推荐
我是程序媛，我骄傲
05-21 1万+
说明： 通过jvm参数-XX:+HeapDumpOnOutOfMemoryError可以让JVM在出现内存溢出时候Dump出当前的内存转储快照。快照格式为java_pid2821.hprof（2821为Java进程号） 参数设置： -XX:+HeapDumpOnOutOfMemoryError ：当内存溢出时触发java.lang.OutOfMemo: Java heap space -XX:He...
OutOfMemoryError异常
kdsnace的博客
10-19 1593
OutOfMemoryError异常
Linux常用命令（二）
ldwtxwh的专栏
12-05 1090
locate命令可以在搜寻数据库时快速找到档案，locate为模糊查找，数据库由updatedb程序来更新，updatedb是由cron daemon周期性建立的，locate命令在搜寻数据库时比由整个由硬盘资料来搜寻资料来得快，但较差劲的是locate所找到的档案若是最近才建立或 刚更名的，可能会找不到，在内定值中，updatedb每天会跑一次，可以由修改crontab来更新设定值。(etc/crontab)grep 命令里的匹配模式，就是你想要找出来的数据，可以是普通的文字符号，也可以是正则表达式；
Dockercompose创建redis主从复制
weixin_43224069的博客
06-29 1233
Dockercompose创建redis主从复制
03-QNX Shell常用指令
静虚待令，有物混成
10-17 8356
查看指令用法：#use 例如：查看pidin用法。
-XX:-HeapDumpOnOutOfMemoryError
wyee000的博客
07-15 880
遇到这个以为是报错，结果不影响框架的使用，后来查阅资料发现：这个不是错误，他是当抛出OOM时进行HeapDump， 是一个调试参数
JVM参数-XX:+HeapDumpOnOutOfMemoryError
sayyy的专栏
08-26 8205
前言 jdk 1.8 eclipse 4.9.0 spring boot 2.0.0.RELEASE -XX:+HeapDumpOnOutOfMemoryError 当堆内存空间溢出时输出堆的内存快照。 复现一下内存空间溢出 创建一个spring boot程序。只要能够运行就可以。 指定内存最大值为10M（-Xmx10M）。10M，呵呵，肯定启动不了 spring boot ，肯定内存空间溢...
-XX:+HeapDumpOnOutOfMemoryError 说明
xharvard的专栏
10-13 1116
-XX:+HeapDumpOnOutOfMemoryError
java内存shell_OutOfMemoryError内存溢出相关的JVM参数
weixin_39911998的博客
11-29 1526
JVM提供了很多处理内存溢出的相关参数，本文主要来讲解下这些参数，当你遇到内存溢出的时候可能会对你非常有帮助，这些参数主要有：1.-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath2.-XX:OnOutOfMemoryError3.-XX:+ExitOnOutOfMemoryError4.-XX:+CrashOnOutOfMemoryError下面我们...
linux下JVM参数-XX:+HeapDumpOnOutOfMemoryError 设置
心有猛虎,细嗅蔷薇
02-02 5337
配置方法 在JAVA_OPTIONS变量中增加 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=${目录}。 例如：export JAVA_OPTS="-Xms2048M -Xmx2048M -Xmn682M -XX:MaxPermSize=96M"  2、参数说明 （1）-XX:+HeapDumpOnOutOfM
JVM（五）实战：OutOfMemoryError 异常
挖坑埋你
01-20 857
本篇内容整理自《深入理解JVM》第二章 第四节 本节内容的目的有两个： 第一，通过代码验证Java虚拟机规范中描述的长个运行时区域存储的内容； 第二，希望读者在工作中遇到实际的内存溢出异常时，能根据异常的信息快速判断是哪个区域的内存溢出，知道什么样的代码可能会导致这些区域内存溢出，以及出现这些异常后该如何处理。 下文的代码都是基于Sun公司的HotSpot虚拟机运行的。
实战:OutOfMemoryError异常
qq_40826814的博客
04-14 752
2.4 实战:OutOfMemoryError异常 本节实战的目的有两个:第一，通过代码验证《Java虚拟机规范》中描述的各个运行时区域储存 的内容;第二，希望读者在工作中遇到实际的内存溢出异常时，能根据异常的提示信息迅速得知是哪 个区域的内存溢出，知道怎样的代码可能会导致这些区域内存溢出，以及出现这些异常后该如何处 理。 本节所列的代码均由笔者在基于OpenJDK 7中的HotSpot虚拟机上进行过实际测试，如无特殊说 明，对其他Op enJDK版本也应当适用。不过读者需意识到内存溢出异常与虚拟机本身
实战：OutOfMemoryError异常
lusiyang463的博客
07-23 249
值得注意的是，这里虽然内存溢出了，但是没有生成堆的快照文件，这是因为此时的溢出是计算出来的，并不是虚拟机的内存溢出，所以甚至没有察觉，这种情况，往往可以考虑是不是本地方法的溢出，比如NIO，NIO的原理就是使用了本地内存空间换取时间，在本地创建list数组来处理网络请求，所以数组大了，本地内存也变大。我们看到这里发生了栈内存溢出，但是没有堆内存溢出，堆内存溢出是以进程为一个单位的，栈超出深度了但远远达不到堆内存，可以利用多线程执行栈溢出可能可以实现，但是这里控制不好可能会导致系统假死，这里不做示范了。
（五）Java实战：OutOfMemoryError异常
怪咖@的博客
04-18 3410
在Java虚拟机规范的描述中,除了程序计数器外,虚拟机内存的其他几个运行时区域都有发生OutOfMemoryError (下文称OOM)异常的可能。本篇主要结合着【深入理解Java虚拟机】一书当中整理了本篇博客，感兴趣的跟着小编一块来学习呀！
-Xms2048m -Xmx4096m -XX:ReservedCodeCacheSize=800m -XX:+UseConcMarkSweepGC -XX:SoftRefLRUPolicyMSPerMB=50 -ea -XX:CICompilerCount=2 -Dsun.io.useCanonPrefixCache=false -Djdk.http.auth.tunneling.disabledSchemes="" -XX:+HeapDumpOnOutOfMemoryError -XX:-OmitStackTraceInFastThrow -Djdk.attach.allowAttachSelf=true -Dkotlinx.coroutines.debug=off -Djdk.module.illegalAccess.silent=true -XX:TieredStopAtLevel=1 -XX:MaxInlineLevel=3 -XX:Tier4MinInvocationThreshold=100000 -XX:Tier4InvocationThreshold=110000 -XX:Tier4CompileThreshold=120000
最新发布
07-26
<think>首先，用户的问题是：“Understanding and optimizing JVM startup parameters for application performance tuning 请问JVM options -Xms2048m -Xmx4096m -XX:ReservedCodeCacheSize=800m -XX:+UseConcMarkSweepGC tuning guide”。这似乎是关于JVM启动参数的调优指南，具体针对给定的参数：-Xms2048m、-Xmx4096m、-XX:ReservedCodeCacheSize=800m、-XX:+UseConcMarkSweepGC。 用户提供了系统级指令： - 所有行内数学表达式必须使用$...$格式。 - 独立公式必须使用$$...$$格式并单独成段。 - LaTeX语法正确。 - 使用中文回答。 - 生成相关问题。 - 回答中引用的段落末尾自然地添加引用标识。 用户还提供了引用内容： - 引用[1]: 建议不要过度添加JVM参数，如-Xmn，因为它会限制G1的自动扩展。只推荐使用-Xms、-Xmx和-XX:MaxGCPauseMillis。 - 引用[2]和[3]: 是JVM参数配置的示例。 用户的问题是关于调优给定的JVM参数，所以我需要基于这些参数提供指南。参数包括： - -Xms2048m：初始堆大小2048MB - -Xmx4096m：最大堆大小4096MB - -XX:ReservedCodeCacheSize=800m：保留代码缓存大小800MB - -XX:+UseConcMarkSweepGC：使用并发标记清除垃圾收集器（CMS） CMS是Java 8及更早版本中使用的垃圾收集器，但在Java 9后已被弃用，推荐使用G1或ZGC等。用户可能在使用较旧的Java版本。 我的回答应该： - 结构清晰，逐步解决问题。 - 保证回答真实可靠。 - 使用中文。 - 在回答中引用段落时添加引用标识。 - 生成相关问题。 回答结构： 1. **介绍参数**：解释每个参数的作用。 2. **调优建议**：基于最佳实践，提供优化建议。 3. **潜在问题**：讨论可能的问题和如何避免。 4. **生成相关问题**：在最后添加相关问题。 关于引用： - 用户提供了引用[1]、[2]、[3]，但它们是示例，不是直接相关。我应该基于内容自然地引用。 - 引用[1]建议避免不必要的参数如-Xmn，所以我可以提到这一点。 关键点： - **堆大小**：-Xms和-Xmx设置为2048m和4096m，表示初始和最大堆大小。建议将-Xms设置为与-Xmx相同以减少运行时调整，但用户设置不同（2048m vs 4096m），所以我可以建议调整。 - **代码缓存**：-XX:ReservedCodeCacheSize=800m，设置代码缓存大小为800MB。默认值较小，如果应用有大量JIT编译代码，可能需要增大。但800MB可能过大，需监控。 - **垃圾收集器**：-XX:+UseConcMarkSweepGC，使用CMS。CMS在低暂停时间应用中有效，但已被弃用。建议如果可能，升级到G1或ZGC。 - 引用[1]提到避免过度参数，如-Xmn，所以我可以强调只添加必要的参数。 调优指南步骤： 1. **理解参数**： - -Xms2048m：初始堆大小。 - -Xmx4096m：最大堆大小。 - -XX:ReservedCodeCacheSize=800m：代码缓存大小。 - -XX:+UseConcMarkSweepGC：垃圾收集器选择。 2. **优化建议**： - 堆大小：建议设置-Xms等于-Xmx以避免运行时堆大小调整的开销。例如，都设置为4096m。 - 代码缓存：监控使用情况；如果不需要800MB，可以减小以节省内存。默认是240MB左右，但取决于应用。 - 垃圾收集器：CMS适用于需要低暂停的应用，但考虑迁移到G1GC（-XX:+UseG1GC）或ZGC，因为CMS已弃用。 - 其他参数：避免添加不必要的参数，如引用[1]所述。 3. **监控和调整**： - 使用工具如jstat、VisualVM、GC日志分析来监控性能。 - 调整基于应用需求，如暂停时间、吞吐量。 4. **潜在问题**： - CMS可能面临并发模式失败或晋升失败问题。 - 过大的代码缓存可能浪费内存。 - 堆大小设置不当可能导致频繁GC。 生成相关问题： - 基于主题，生成3-5个相关问题。 使用中文回答。</think>### JVM启动参数调优指南：理解与优化 在应用性能调优中，JVM启动参数是关键配置，直接影响内存管理、垃圾回收（GC）效率和整体性能。您提供的参数组合为：`-Xms2048m -Xmx4096m -XX:ReservedCodeCacheSize=800m -XX:+UseConcMarkSweepGC`。我将逐步分析每个参数的作用、潜在优化点和调优建议，确保回答基于JVM最佳实践。以下指南假设您使用Java 8或更早版本（因为CMS收集器在Java 9后已弃用）。调优的核心原则是：**基于监控数据进行调整，避免过度配置**，如引用[1]所述，不要添加不必要的参数（如`-Xmn`），以免干扰JVM的自动优化机制。 #### 1. **参数解析与作用** - **`-Xms2048m`**：设置初始堆大小为2048MB（2GB）。堆是JVM存储对象实例的内存区域，初始大小影响应用启动时的内存分配速度。如果设置过小，可能导致频繁堆扩展，增加GC开销。 - **`-Xmx4096m`**：设置最大堆大小为4096MB（4GB）。这限制了堆的上限，防止内存溢出（OOM）。但`-Xms`和`-Xmx`值不同时，JVM会在运行时动态调整堆大小，可能引入额外开销。 - **`-XX:ReservedCodeCacheSize=800m`**：保留代码缓存大小为800MB。代码缓存存储JIT（即时编译器）生成的本地代码，用于加速热点方法执行。默认值通常较小（如240MB），增大此值可避免JIT编译因缓存不足而失效，但过大会浪费内存。 - **`-XX:+UseConcMarkSweepGC`**：启用并发标记清除（CMS）垃圾收集器。CMS以低暂停时间为目标，适合响应敏感型应用（如Web服务），但它在高并发或大堆场景下可能面临并发模式失败问题，且已从Java 14开始弃用[^1]。 #### 2. **调优建议与优化步骤** 调优应基于实际监控数据（如GC日志、内存使用率）。以下是针对您的参数的优化指南： **步骤1: 优化堆大小设置** - **问题**：`-Xms2048m`和`-Xmx4096m`不一致可能导致堆大小动态调整，增加GC频率。数学上，GC暂停时间与堆大小相关（例如，暂停时间$P \propto \frac{1}{H}$，其中$H$为堆大小），但不一致设置会引入不稳定性。 - **建议**：将`-Xms`设置为与`-Xmx`相同（例如`-Xms4096m -Xmx4096m`）。这避免运行时堆扩展开销，减少GC停顿。监控工具（如`jstat`或VisualVM）可确认堆使用率：如果应用平均堆使用低于2048MB，可适当降低`-Xmx`；反之，如果频繁GC，则增大`-Xmx`[^1]。 - **潜在风险**：过大的堆可能延长Full GC时间（例如，CMS的停顿时间与存活对象数量成正比）。 **步骤2: 调整代码缓存大小** - **问题**：800MB的代码缓存可能过大。默认值（如240MB）通常足够；过大的设置浪费内存，且不会提升性能。代码缓存使用率可通过`jconsole`或`-XX:+PrintCodeCache`参数监控。 - **建议**：初始建议值设为240MB（如`-XX:ReservedCodeCacheSize=240m`）。如果应用有大量动态类加载（如Spring框架），监控后逐步增加。但避免超过实际需求，以节省内存用于堆或其他区域[^3]。 - **公式参考**：代码缓存大小$C$应满足$C \geq N \times S$，其中$N$是热点方法数量，$S$是平均方法大小。但实际中，通过监控调整更可靠。 **步骤3: 垃圾收集器优化** - **问题**：CMS收集器虽适合低暂停，但已弃用，且在高堆（如4GB）场景下容易发生并发失败（例如，当GC线程无法赶上对象分配速度时）。失败后会触发Serial Old GC，导致长时间停顿。 - **建议**： - 短期：添加辅助参数减少失败风险，例如： - `-XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=70`：当老年代使用率达70%时启动CMS，避免过早或过晚GC[^2]。 - `-XX:+ExplicitGCInvokesConcurrent`：防止System.gc()触发Full GC。 - 长期：迁移到G1收集器（`-XX:+UseG1GC`），它更适合大堆和现代硬件。G1自动管理堆分区，减少手动调优需求。迁移示例参数：`-XX:+UseG1GC -XX:MaxGCPauseMillis=200`（设置期望最大GC暂停时间）[^1]。 - **监控关键指标**：使用`-Xlog:gc*`输出GC日志，分析停顿时间和频率。目标是将平均GC暂停控制在100-200ms内。 **步骤4: 整体优化原则** - **避免过度参数化**：如引用[1]强调，只保留必要参数（如`-Xms`、`-Xmx`和GC相关）。删除冗余项（如`-Xmn`或`-XX:NewSize`），让JVM自动优化代大小。 - **通用建议**： - 添加OOM诊断参数：`-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path`，便于分析内存泄漏。 - 监控工具：使用`jcmd`、VisualVM或商业工具（如YourKit）实时跟踪内存、CPU和GC。 - 参数示例（基于您的配置优化）： ```bash -Xms4096m -Xmx4096m -XX:ReservedCodeCacheSize=240m -XX:+UseG1GC -XX:MaxGCPauseMillis=150 -XX:+HeapDumpOnOutOfMemoryError ``` 此配置优先稳定性，但需根据应用负载测试调整。 #### 3. **潜在风险与注意事项** - **CMS特定风险**：在堆大小为4GB时，CMS可能因内存碎片导致晋升失败。如果监控到`concurrent mode failure`，需减小`-XX:CMSInitiatingOccupancyFraction`或增加堆大小。 - **性能权衡**：增大堆或代码缓存可能降低GC频率，但增加内存占用。数学上，吞吐量$T$与GC开销相关（$T = 1 - \frac{G}{A}$，其中$G$为GC时间，$A$为总运行时间），因此平衡是关键。 - **版本兼容性**：如果您使用Java 11+，CMS已移除，强制迁移到G1或ZGC。建议升级JDK以获得更好性能。 - **真实案例参考**：引用[2]和[3]显示样例参数，但您的配置中`-XX:ReservedCodeCacheSize=800m`可能源于特定需求（如大型应用服务器）。如果无监控支持，建议回退到保守值[^2][^3]。 #### 4. **调优流程总结** 1. **基准测试**：在未修改参数下运行应用，收集GC日志和性能指标。 2. **增量调整**：先统一堆大小（`-Xms4096m -Xmx4096m`），再优化代码缓存（从240m开始）。 3. **迁移收集器**：过渡到G1，并设置`-XX:MaxGCPauseMillis`。 4. **监控验证**：运行负载测试，确认暂停时间、吞吐量改善。 5. **迭代优化**：基于数据微调，避免一次修改多个参数。 通过以上步骤，您可显著提升应用性能。如果提供更多细节（如应用类型、JDK版本和GC日志），我可给出更定制建议。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值