ubuntu中报错:无法分配内存 (errno=12)

  今天碰到一个大坑,差点要了老命!

  之前装了ubuntu双系统,后来崩溃,想在就想装VMware虚拟机,再装ubuntu,一切进展顺利,直到在虚拟机的ubuntu中安装IDEA时出现了问题。
  安装过程并没有报错,但是启动后运行一个项目,项目还没加载呢就直接退出,生成个错误日志,如下: 

  


  OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x00000000f5a9b000, 66166784, 0) failed; error='无法分配内存' (errno=12)

  日志中的部分内容是:

# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 66166784 bytes for committing reserved memory.
# Possible reasons:
#   The system is out of physical RAM or swap space
#   In 32 bit mode, the process size limit was hit
# Possible solutions:
#   Reduce memory load on the system
#   Increase physical memory or swap space
#   Check if swap backing store is full
#   Use 64 bit Java on a 64 bit OS
#   Decrease Java heap size (-Xmx/-Xms)
#   Decrease number of Java threads
#   Decrease Java thread stack sizes (-Xss)
#   Set larger code cache with -XX:ReservedCodeCacheSize=
# This output file may be truncated or incomplete.
#
#  Out of Memory Error (os_linux.cpp:2627), pid=3309, tid=0x00007f0174cfc700
#
# JRE version: OpenJDK Runtime Environment (8.0_112-b16) (build 1.8.0_112-release-736-b16)
# Java VM: OpenJDK 64-Bit Server VM (25.112-b16 mixed mode linux-amd64 compressed oops)
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

  真是走了很多弯路,尝试了无数次:重装idea,idea配置文件配置jvm的大小,把虚拟机的内存再调大一倍等等等等

  最后来根据 (errno=12)这个搜索到一篇文章,说道:
    后来看了美军一个文章(http://www.enchantedage.com/node/235),加一个配置即可:echo 1000000 > /proc/sys/vm/max_map_count

  我看了自己虚拟机ubuntu里面,/proc/sys/vm/max_map_count的初始值很小,只有65530,果断使用这个重设了一下。

  啊,终于好了,太艰难了。

 

  后来又请装双系统的同事看下他们系统里的这个值,也是65530,但是他们的却不报错,真是醉醉的。看来造成“无法分配内存”的原因,并不是这里,但是可以通过修改这个来解决。

    猜测这个原因:1、双系统和虚拟机不同  2、安装jdk方式的不同(之前的我,和现在的同事们,都是先下载好jdk再安装的;可是现在虚拟机我却使用命令安装,这样不需要配置环境变量)

    只是猜测,暂时就不去验证它了,如果再有遇到的同学,解决不了的话,可以朝这个方向尝试下。

 


 

  后来在IDEA中操作,实在是各种卡、慢,第二天还是决定重装jdk,不使用命令安装,而是使用解压缩包并且配置环境变量,并且将max_map_count的值改了回去

  echo 65530> /proc/sys/vm/max_map_count

 

  你猜怎么着,一点问题没有。Maven仓库下载jar包也很溜,果然还是jdk的问题啊。所以最终解决方案是:使用解压缩包并配置环境变量的方式,重新安装jdk!

 

  标签:虚拟机的ubuntu中安装Idea出错 无法分配内存 (errno=12)

 

  原创文章,欢迎转载,转载请注明处!

 

 


 

 附 美军文章的内容如下:

Linux mmap() ENOMEM error causing Segmentation Fault

 

I have a system that creates files on disk, then uses mmap and madvise and mflush to asynchronously do I/O to the disk. This system may potentially create many, many files, each of which will have three mmap sections, that will be rotated through the file.

After trying to run this system for a while, I started getting segmentation violations that I couldn't quite understand. Initially, I thought it was a threading problem, because I'm using boost::asio and boost::thread quite heavily. I used strace() to figure out what the system was doing, and found that right before the crashes, one or more calls to mmap() would fail.

Long story short: There is a limit to the number of mmap() segments that can be active in a Linux process at any one time. This limit is configurable in /proc/sys/vm/max_map_count. I already knew there was a file descriptor limit, and I raised that pretty high, but apparently Linux doesn't think you'll be using lots of mmap() just because you're using lots of files. Adding the following to /etc/rc.local will fix the problem:

echo 1000000 > /proc/sys/vm/max_map_count

 
<think>我们正在处理一个SRT协议相关的错误。错误信息显示在SRT播放接收线程中,读取数据时发生了超时(Timer expired),导致socket状态变为SRTS_BROKEN(连接已断开)。 错误分析: 1. 错误代码:6001 (SRT read or write failed) 2. 具体原因:在等待数据可读时发生错误,错误信息为“Timer expired”(定时器超时),这通常意味着在指定的超时时间内没有收到数据。 3. 可能的原因: - 网络问题:推流端停止发送数据或网络中断。 - 配置问题:SRT连接的超时时间设置过短。 - 推流端问题:推流端异常退出或停止推流。 解决方案: 1. 检查推流端是否正常工作,确保推流端持续发送数据。 2. 调整SRT的超时配置,增加超时时间以避免因网络波动导致的断开。 3. 检查网络状况,确保网络稳定。 配置调整建议(在srt_server配置块中): - 增加 `peerlatency` 参数(默认为200ms,可适当增加,如500ms) - 增加 `connect_timeout` 参数(默认为4000ms,可适当增加,如10000ms) 例如: srt_server { enabled on; listen 6666; maxbw 1000000000; connect_timeout 10000; # 连接超时设置为10秒 peerlatency 500; # 设置对端延迟为500ms } 另外,确保推流端和服务器之间的网络延迟在可接受范围内。 如果问题仍然存在,可以检查SRS日志以获取更多信息,或者尝试使用工具(如srt-live-transmit)测试SRT链路的稳定性。 注意:这个错误是发生在播放端(接收端)的,所以我们需要确保播放端的网络和设置也正确。但是,根据错误上下文,问题可能出在服务器等待数据时超时,因此主要调整服务器配置。 如果调整配置后问题仍然存在,可能需要检查SRS版本是否有已知问题,并考虑升级到最新版本。 由于问题是在运行过程中出现的,我们还需要考虑如何让SRS在连接断开后能够自动恢复,但SRT协议本身是面向连接的,断开后需要重新建立连接。 最后,这个错误也可能是由于服务器资源不足(如CPU、内存)导致处理不及时,可以监控服务器资源使用情况。 根据以上分析,我们提供调整配置的建议,并建议监控网络和推流端状态。 注意:在配置调整后需要重启SRS服务。 如果问题仍然存在,请提供更详细的日志信息。 现在,根据要求,我们需要在回答后提出3-5个相关问题。</think>### SRT "Timer expired" 错误解决方案 #### 错误分析 该错误 `SRT read or wait readable: Timer expired` 表示 SRT 连接在读取数据时超时,常见原因包括: 1. **网络延迟过高**:超过 SRT 配置的等待时间 2. **防火墙/路由问题**:数据包被拦截或丢失 3. **推流端异常**:推流中断或数据发送不稳定 4. **SRT 参数不匹配**:客户端与服务器参数不一致 #### 解决方案 ```conf # 修改 SRT 服务器配置 srt_server { enabled on; listen 6666; maxbw 1000000000; # 关键修复参数 connect_timeout 10000; # 增加连接超时时间(单位:毫秒) peerlatency 1000; # 增加对端延迟容忍度 recv_timeout 5000; # 增加接收超时时间 send_timeout 5000; # 增加发送超时时间 } ``` #### 调试步骤 1. **检查网络路径**: ```bash # 测试网络连通性 mtr -r -c 10 推流端IP地址 ``` 2. **验证 SRT 连接**: ```bash # 使用 srt-live-transmit 测试 srt-live-transmit -v srt://推流端IP:端口 srt://服务器IP:6666 ``` 3. **调整内核参数**: ```bash # 增加 UDP 缓冲区 sysctl -w net.core.rmem_max=67108864 sysctl -w net.core.wmem_max=67108864 ``` 4. **启用详细日志**: ```conf # 在 SRS 配置中添加 srt_log_level debug; ``` #### 根本原因预防 1. **使用前向纠错(FEC)**: ```conf srt_server { fec redundant; # 启用冗余纠错 fec_rows 10; fec_cols 5; } ``` 2. **配置自适应参数**: ```conf srt_server { latency_factor 8; # 动态调整延迟 max_reorder 1000; # 最大重排序容忍度 } ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值