我正在开发一个完全用Java编写的内存数据库。我们有一个输入源,它向系统提供数据,这是提取/加载阶段。在运行这个过程中,我注意到JVM挂起了,根本原因是GC被触发了。然后应用程序冻结,随后出现OutOfMemory错误(超过GC开销限制)
检查GC日志发现了大量的垃圾收集,既有年轻的,也有老的。令人惊讶的是,希望的幸存者规模是负数。我在试着理解为什么会这样?以前有人遇到过这个吗?
环境:
0.666:[GC期望幸存者大小178913280字节,新阈值7(最大15)[psyounggen:524289K->4431K(30583488K)]524289K->4503K(100488576K),0.0052536秒][times:user=0.03sys=0.00,real=0.01秒]
0.671:[Full GC(系统)[Psyounggen:4431K->0K(30583488K)][Paroldgen:72K->4096K(69905088K)]4503K->4096K(100488576K)[Pspermgen:8852K->8847K(21248K)],0.0853597秒][times:user=0.08sys=0.00,real=0.09秒]
12.306:[GC所需幸存者大小178913280字节,新阈值7(最大15)[psyounggen:26214464K->389676K(30583488K)]26218560K->393868K(100488576K),0.1907519秒][times:user=0.69sys=0.69,real=0.19秒]
19.845:[GC期望幸存者大小178913280字节,新阈值7(最大15)[Psyounggen:26604140K->4369012K(30583488K)]26608334K->4539738K(100488576K),2.0671426秒][times:user=12.67 sys=10.64,real=2.07秒]
31.930:[GC期望幸存者大小178913280字节,新阈值7(最大15)[psyounggen:30583476K->4368998K(30583488K)]30764447K->5793376K(100488576K),2.4316614秒][times:user=14.32sys=12.07,real=2.43秒]
43.950:[GC所需幸存者大小178913280字节,新阈值7(最大15)[psyounggen:30583462K->4369018K(30583488K)]32008283K->10474103K(100488576K),3.0868838秒][times:user=31.76 sys=10.64,real=3.09秒]
57.851:[GC期望幸存者大小-954466304字节,新阈值6(最大15)[Psyounggen:30583482K->4369011K(16019904K)]36688571K->19053916K(85924992K),5.0616910秒][times:user=45.58 sys=21.95,real=5.06秒]
67.849:[GC期望幸存者大小-954466304字节,新阈值5(最大15)[Psyounggen:16019891K->7854065K(23301696K)]30706222K->22540396K(93206784K),1.9574226秒][times:user=35.38sys=0.00,real=1.96秒]
74.940:[GC所需幸存者大小-954466304字节,新阈值4(最大15)[Psyounggen:19504945K->11650800K(23301696K)]34191281K->27450594K(93206784K),3.2089939秒][times:user=54.41sys=1.51,real=3.21秒]
83.683:[GC所需幸存者大小-954466304字节,新阈值3(最大15)[Psyounggen:23301680K->11650785K(23301696K)]39101518K->32434323K(93206784K),4.8105989秒][times:user=65.82 sys=10.30,real=4.81秒]
93.647:[GC期望幸存者大小-954466304字节,新阈值2(最大15)[Psyounggen:23301665K->10083445K(23301696K)]44085203K->35191108K(93206784K),3.9481522秒][times:user=54.77 sys=8.02,real=3.95秒]
102.406:[GC所需幸存者大小-954466304字节,新阈值1(最大15)[Psyounggen:21734325K->10417779K(23301696K)]46841988K->39667600K(93206784K),4.7031362秒][times:user=63.29 sys=9.50,real=4.70秒]
112.109:[GC期望幸存者大小-954466304字节,新阈值1(最大15)[Psyounggen:22068659K->5501380K(23301696K)]51318480K->45289996K(93206784K),5.6499475秒][times:user=51.39sys=23.81,real=5.65秒]
122.858:[GC所需幸存者大小-954466304字节,新阈值1(最大15)[Psyounggen:17152260K->5829244K(23301696K)]56941300K->51036174K(93206784K),3.9348524秒][times:user=47.49sys=11.48,real=3.93秒]
132.599:[GC所需幸存者大小-954466304字节,新阈值1(最大15)[psyounggen:17480124K->4411050K(23301696K)]62703442K->55124929K(93206784K),3.2682313秒][times:user=35.46sys=10.86,real=3.27秒]
141.869:[GC所需幸存者大小-954466304字节,新阈值1(最大15)[psyounggen:16061930K->5983419K(23301696K)]66775809K->61080627K(93206784K),3.1660854秒][times:user=38.39sys=9.45,real=3.17秒]
149.996:[GC所需幸存者大小-954466304字节,新阈值1(最大15)[Psyounggen:17634299K->5335607K(23301696K)]72731507K->65656597K(93206784K),4.4767380秒][times:user=55.41 sys=12.67,real=4.48秒]
154.473:[全GC[Psyounggen:5335607K->0K(23301696K)][Paroldgen:60320990K->29187977K(69905088K)]65656597K->29187977K(9320678K)[Pspermgen:53148K->53088K(106560K)],55.6080316秒][times:user=518.19 sys=3.43,real=55.61秒]
210.083:[GC期望幸存者大小-954466304字节,新阈值1(最大15)[psyounggen:1942K->96K(23301696K)]29189919K->29188073K(93206784K),0.0512343秒][times:user=0.50sys=0.00,real=0.05秒]
210.134:[全GC[Psyounggen:96K->0K(23301696K)][Paroldgen:29187977K->29187816K(69905088K)]29188073K->29187816K(93206784K)[Pspermgen:53088K->53087K(106624K)],15.5128928秒][times:user=236.31 sys=0.19,real=15.51秒]
239.525:[GC所需幸存者大小-954466304字节,新阈值1(最大15)[psyounggen:11650880K->4622965K(23301696K)]40838696K->33810782K(93206784K),1.2739696秒][times:user=23.01sys=0.00,real=1.27秒]
248.572:[GC所需幸存者大小-954466304字节,新阈值1(最大15)[Psyounggen:16273845K->4009690K(23301696K)]45461663K->37894227K(93206784K),2.3307283秒][times:user=41.84sys=0.00,real=2.33秒]
256.854:[GC所需幸存者大小-954466304字节,新阈值1(最大15)[psyounggen:15660570K->5707092K(23301696K)]49545113K->43643553K(93206784K),2.5595566秒][times:user=46.05sys=0.00,real=2.56秒]
265.471:[GC所需幸存者大小-954466304字节,新阈值1(最大15)[psyounggen:17357972K->4996932K(23301696K)]55294440K->48690372K(93206784K),2.8941178秒][times:user=52.21 sys=0.00,real=2.89秒]
275.795:[GC所需幸存者大小-954466304字节,新阈值1(最大15)[Psyounggen:16647812K->3781542K(23301696K)]60342280K->52491436K(93206784K),2.6240427秒][times:user=47.18sys=0.00,real=2.63秒]
284.083:[GC所需幸存者大小-954466304字节,新阈值1(最大15)[psyounggen:15432422K->5815192K(23301696K)]64142316K->58360954K(93206784K),2.3724770秒][times:user=42.68sys=0.00,real=2.37秒]
291.659:[GC期望幸存者大小-954466304字节,新阈值1(最大15)[Psyounggen:17466072K->5357588K(23301696K)]70011840K->63780322K(93206784K),3.0063028秒][times:user=54.20sys=0.00,real=3.01秒]
299.322:[GC所需幸存者大小-1228210176字节,新阈值2(最大15)[Psyounggen:17008468K->6341939K(23301696K)]75431206K->70078817K(93206784K),4.1999305秒][times:user=65.35 sys=5.13,real=4.20秒]
303.523:[全GC[Psyounggen:6341939K->0K(23301696K)][Paroldgen:63736877K->38098305K(69905088K)]70078817K->38098305K(93206784K)[Pspermgen:53125K->53125K(103360K)],41.2081882秒]
正如你可以注意到在57.851秒以上的日志中,我们有一个负的希望幸存者大小,我不知道为什么会这样?
这看起来像内存泄漏吗?
是的,你的问题似乎是你有太多的活动对象。“超过GC开销限制”意味着GC运行,花费了很长时间,释放的空间很少。你可以调整一些旋钮来控制tresholds,但这些不会帮助你提高性能。
我在创建内存密集型模拟(也是100-120GB最大堆)时遇到了完全相同的问题。我的解决方案是远离对象来存储数据,并将所有内容都保存在一个原始的int[]中。这项工作最终变成了一个名为Banana的新开源项目,它支持一些原始数据结构。Banana实际上是将数据结构建立在自己的内存管理基础上,您可以获得完全动态的数据结构,而没有对象的开销。继续阅读项目wiki,它记录了事情是如何工作的,并获得了示例代码和基准。
我有一个JVM进程,最大1024 MB堆大小的核心转储。(OpenJDK 7 on linux) 当我使用YourkitJavaProfiler 10.0.6分析核心转储文件时,我发现进程仅在内存不足时使用803 MB堆。 似乎两个幸存者堆使用了堆的2/9(或保留)。 我在Windows7上用JDK7进行了测试,jvisualvm(带有Visual GC插件)显示一个幸存者的大小是伊甸园大小的1/
问题内容: 对于Sun / Oracle的JVM,我读过GC算法将新一代划分为一个伊甸园区域和两个幸存者区域。我想知道的是,为什么有两个幸存者地区而不是一个?该算法可以在伊甸园和一个幸存者区域之间保持乒乓(目前它在两个幸存者区域之间的方式);或这种方法有什么缺点? 问题答案: 我相信JRockit的GC实现更像您建议的那样工作,只有一个eden和一个幸存者空间,但请不要在此引用我。 HotSpot
在kubernetes仪表板上,有一个pod,其中内存使用情况(字节)显示为。 这个pod保存了使用Xms512m-Xmx1024m运行的java应用程序,该应用程序位于kubernetes部署文件中- 我已启用gc日志,并在pod日志中看到这些日志: kubernetes是如何到达用法的?如果我理解正确,目前的用法只有: 运行ps显示除了这个java应用程序之外,pod上没有其他进程在运行<任何
问题内容: 我正在使用和选项打开gc日志记录。 但是发现只有在4 0r 5后才通过命令打印我的gc日志的实际详细信息! 按照定义,将为每个gc打印应用程序停止时间。 但是我不清楚为什么它会打印如下所示的示例。 是因为 只需在每个安全点到达后打印 (要么) 该日志文件将由其他gc线程记录。我正在使用并发扫描进行完整GC,并为年轻一代使用ParNew 我的应用程序是Web应用程序。 O / p模式-我
partition/data只有15G,kafka日志文件夹是-/data/var/kafka/kafka-logs data/var/kafka/kafka-logs下的大多数文件夹大小为4K-40K 但两个文件夹的大小非常大--5G-7G,这导致/数据是100%
我想将log4j2配置为保持一周的日志,但是每个文件都应该有一个指定的最大大小。所以它是和的组合,但是在翻转策略中,我只想设置日志应该保留多少天。我不在乎会创建多少文件,它们只是不能大于指定的大小并保持一周的日志。有可能在log4j2中实现吗?