OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000083e80000, 1366294528, 0) failed;

本文介绍了解决在手动搭建云HBase过程中遇到的启动命令报错问题,主要原因是内存分配失败。提供了两种解决方案:一是调整Hadoop和HBase配置文件中内存设置;二是增加系统交换空间,并详细说明了如何创建和启用交换空间。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

我是在手动搭建云hbase时遇到的

安装zookeeper和hdfs时 启动命令的时候会报OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000083e80000, 3221225472, 0) failed; error='Cannot allocate memory' (errno=12)这种错误

原因就是内存无法分配的问题 解决办法有两个种(这要看遇到的具体是什么了)

1.分配给Hadoop和hbase的内存过大了 可以修改hadoop-env.sh和hbase-env.sh中的Hadoop和hbase内存 给小一点就ok了

2.现执行命令 free -m 查看内存是不是还有 最主要的是 看有没有交换空间 swap (这很重要)如果没有交换空间 或者交换空间比较小  要先安装交换空间 或者增大空间 

 

(1)、创建swapfile:

root权限下,创建swapfile  # dd  if=/dev/zero  of=swapfile  bs=1024  count=500000  (有时会遇到dd命令不识别 可能是你安装过一次了 没事 先把swapfile删除就ok了)

(2)、将swapfile设置为swap空间

# mkswap swapfile

(3)、启用交换空间,这个操作有点类似于mount操作(个人理解):

# swapon  swapfile (删除交换空间 swapoff swapfile)

至此增加交换空间的操作结束了,可以使用free命令查看swap空间大小是否发生变化;


我的问题是增加交换空间解决的


 

http://www.cnblogs.com/zengkefu/p/5633342.html OpenJDK和Sun/OracleJDK 区别 与联系 首先要先明确之间,以及OpenJDK 6、OpenJDK 7、OpenJDK 7u和OpenJDK 8等项目之间是什么关系,这有助于确定接下来编译要使用的JDK版本和源码分支。 从前面介绍的Java发展史中我们了解到OpenJDK是Sun在2006年末把Java开源而形成的项目,这里的“开源”是通常意义上的源码开放形式,即源码是可被复用的,例如IcedTea、UltraViolet都是从OpenJDK源码衍生出的发行版。但如果仅从“开源”字面意义(开放可阅读的源码)上看,其实Sun自JDK 1.5之后就开始以Java Research License(JRL)的形式公布过Java源码,主要用于研究人员阅读(JRL许可证的开放源码至JDK 1.6 Update 23为止)。把这些JRL许可证形式的Sun/OracleJDK源码和对应版本的OpenJDK源码进行比较,发现除了文件头的版权注释之外,其余代码基本上都是相同的,只有字体渲染部分存在一点差异,Oracle JDK采用了商业实现,而OpenJDK使用的是开源的FreeType。当然,“相同”是建立在两者共有的组件基础上的,Oracle JDK中还会存在一些Open JDK没有的、商用闭源的功能,例如从JRockit移植改造而来的Java Flight Recorder。预计以后JRockit的MissionControl移植到HotSpot之后,也会以Oracle JDK专有、闭源的形式提供。 Oracle的项目发布经理Joe Darcy在OSCON 2011上对两者关系的介绍也证实了OpenJDK 7和Oracle JDK 7在程序上是非常接近的,两者共用了大量相同的代码(如下图,注意图中提示了两者共同代码的占比要远高于图形上看到的比例),所以我们编译的OpenJDK,基本上可以认为性能、功能和执行逻辑上都和官方的Oracle JDK是一致的。
### 解决方案 当在 Amazon Aurora MySQL 环境下运行应用程序并遇到 `OpenJDK 64-Bit Server VM` 报告的 `commit_memory failed error 1455` 错误时,这通常意味着操作系统无法为 JVM 提供足够的连续物理内存来满足其请求。此错误的根本原因可能是由于系统内存不足或者虚拟内存设置不当。 为了有效解决问题,可以采取以下几个措施: #### 调整Java堆大小配置 调整应用服务器上的 Java 应用程序的最大堆尺寸参数 `-Xmx` 和初始堆尺寸参数 `-Xms` 可以减少对大块连续内存的需求。通过降低这些值,可以使 JVM 更容易找到可用的内存区域[^3]。 ```bash # 编辑 jvm.options 文件路径可能不同,请根据实际情况修改 vi /path/to/application/jvm.options ``` 将原有的最大堆尺寸和最小堆尺寸适当减小,例如从原来的 8G 改成更合理的数值如 2G 或者基于实际需求评估后的其他合理值: ```properties -Xms2g -Xmx2g ``` #### 配置交换空间(Swap Space) 如果硬件资源有限,则增加系统的交换分区可以帮助缓解短期内的高负载情况下的内存压力。创建额外的 swap 文件或磁盘作为临时存储介质,在物理 RAM 不足的情况下提供补充支持[^4]。 ```bash fallocate -l 4G /swapfile # 创建一个名为 'swapfile' 的新文件,并分配给它 4GB 大小的空间 chmod 600 /swapfile # 设置权限以便只有 root 用户可读写该文件 mkswap /swapfile # 将这个文件初始化为 Swap 设备 swapon /swapfile # 启动新的 Swap 分区 echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab # 添加到 fstab 中使重启后仍然生效 ``` #### 检查数据库实例规格 对于托管于 AWS 上的服务而言,确认所使用的 EC2 实例类型是否适合当前工作负荷非常重要。如果发现即使经过上述优化之后仍频繁遭遇 OOM (Out Of Memory),那么考虑升级至更高性能级别的实例可能会有所帮助[^1]。 #### 审视应用程序日志与监控数据 最后但同样重要的是要定期审视应用程序的日志记录以及云平台提供的各种性能指标图表。这样做不仅有助于提前识别潜在的风险因素,而且还能为进一步调优提供依据。 ---
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值