调整GC用于Java音频应用程序

Question

我注意到在java中播放音频时,gc中的MarkSweepCompact阶段太长并导致短暂的静音,这是不可接受的.所以我需要使用低暂停gc.我尝试过Parallel和CMS,它们似乎工作得更好,因为我认为暂停时间更短,并且它们不会像默认那样经常完全收集.

到目前为止,我已经使用ParallelGC的以下选项测试了我的程序:

-XX:+UseParallelGC 
-XX:MaxGCPauseMillis=70

对于ConcurrentMarkSweep:

-XX:+UseConcMarkSweepGC
-XX:+CMSIncrementalMode
-XX:+CMSIncrementalPacing

我也尝试过G1GC,但它仍然在java 6中实验性.两种模式的选项:

-Xms15m
-Xmx40m
-XX:+UnlockExperimentalVMOptions
-XX:+CMSClassUnloadingEnabled
-XX:+TieredCompilation
-XX:+AggressiveOpts
-XX:+UseAdaptiveSizePolicy
-Dsun.java2d.noddraw=false
-Dswing.aatext=true
-XX:MaxPermSize=25m
-XX:MaxHeapFreeRatio=10
-XX:MinHeapFreeRatio=10

哪种GC在这种情况下更好？是否可以针对最佳CPU性能和最小内存使用量对这些设置进行优化？

编辑为了识别暂停,我记录了将音频数据写入输出线的时间,通常在92到120毫秒之间(我写的是16384字节= ~92毫秒),广告在运行全GC时,它是200+毫秒:

65.424: [Full GC (System) [PSYoungGen: 872K->0K(2432K)] [PSOldGen: 12475K->12905K(16960K)] 13348K->12905K(19392K) [PSPermGen: 15051K->15051K(22272K)], 0.2145081 secs] [Times: user=0.20 sys=0.00, real=0.21 secs] 
Was writing 16384 bytes, time to write 263 ms

EDIT2我的应用程序的分配模式如下:它在启动时加载一堆对象,然后它开始播放,我猜之后的大多数对象都由gui分配,因为凝视/暂停音频不会改变GC图形许多.这是visualgc与并行gc一起显示的内容:

图表在启动时开始,我开始播放.标记是

1)声音延迟和完整的gc,我认为它增加了旧尺寸:

101.646: [Full GC [PSYoungGen: 64K->0K(6848K)] [PSOldGen: 15792K->12773K(19328K)] 15856K->12773K(26176K) [PSPermGen: 15042K->14898K(23808K)], 0.2411479 secs] [Times: user=0.19 sys=0.00, real=0.24 secs]

2)我打开应用程序窗口并暂停播放.什么都没有改变,稍后它增加了伊甸园的大小.

3)我打开窗口再次开始播放.

所以我需要增加分配的旧Gen大小？我怎么做？我正在使用-XX:NewRatio = 10和-XX:NewSize = 10m

谢谢.

Answer 1

你提供的日志太小,无法提供真实的分析,但它表示,由于旧的基本上已经满了,它花了200毫秒做v.这意味着您的堆太小或您有内存泄漏.在这种情况下,您无法调整GC算法.因此,本回复的其余部分是关于如何从应用程序中获取更多信息和/或如何在消除内存泄漏或具有更大堆时调整GC.

在很大程度上,低暂停意味着尽一切可能将集合保留为年轻集合.

您确实需要在开始和完成写入时准确记录,然后将其与在此期间发生在JVM中的STW暂停相关联,否则您实际上不知道可能导致问题的原因或问题的严重程度.

我马上做的事情;

1. 更改日志记录,以便输出可由脚本轻松解析的单行(可能是starttime,endtime,duration)
2. 添加PrintGCApplicationStoppedTime和PrintGCApplicationConcurrentTime开关,以便获得每个 STW暂停的记录,而不仅仅是GC事件
3. 使用最新的JVM(即6u23),因为在过去的一两年里,热点已经有了很多改进,所以使用较旧的一个
4. 你没有说你是否受内存限制,但如果可以,我肯定会增加堆大小,40M非常小,所以你没有足够的空间可以玩
5. 在连接visualgc的情况下运行应用程序,它可以更全面地了解IMO的内容,因为您可以同时拥有所有不同的视图

关键是确定你的空间不足以及原因.答案可能在于你的应用程序的分配模式是什么样的,它是否会产生一堆短暂的物体,这样你就可以很快地烧掉你的小伊甸园？暂停阈值太高,以至于你无论如何都要通过幸存者空间ping对象,从而迫使频繁的终身gcs(慢)？

还有一些要记住的事情......

• iCMS(增量版)适用于1或2台核心机器,是否描述了您的机器？你有多少核心？你可能只是想放弃那个选项
• CMS确实有一个单线程阶段(初始标记),这可能会伤害到你
• CMS通常比其他收集器更喜欢堆,你的收集器非常小

在visualgc图形添加到问题后进行编辑 由于您受内存限制,因此您需要充分利用您拥有的空间,唯一的方法是通过重复基准测试...理想情况下使用可重复的测试.

• 你可以-Xmn用来指定设定年轻一代的大小,其余的将给予终身.
• 你可能想要调整你对幸存者空间的使用,这样你就可以让它们在被交换之前变得更饱满,并让对象在它们终身之前存在更长时间
  • -XX:TargetSurvivorRatio=90 设置它以便幸存者空间在被复制之前需要90%满,显然这里需要在复制和使用空间的成本之间进行权衡.
  • 用于-XX:+PrintTenuringDistribution显示每个空间的大小以及事物的方式,您还可以在visualgc中看到这一点
  • 用于-XX:+MaxTenuringThreshold指定一个对象在年终集合中可以存活多少次(从1个幸存者空间复制到另一个幸存者空间),例如,如果你知道你只得到短暂的垃圾或永远存在的东西然后将其设置为1是明智的
• 您需要了解触发终身收藏的内容,并考虑采取措施以便稍后触发
  • 对于CMS,这可能涉及调整-XX:CMSInitiatingOccupancyFraction=<value>,例如设置为80,它将触发CMS 80%的终身入住率(注意:这是一个坏的错误,所以你可能更喜欢让热点管理这个;设置它太小,它收集太频繁的杀戮性能,设置太大,可能触发太晚导致计划外的完整收集,相应的长暂停时间
• 如果它真的是旧的收藏品会伤害你,你需要低停顿,那么使用CMS和ParNew

最后得到一个分析器并找出垃圾来自哪里,您可能会发现更容易控制垃圾产生的速度,然后将力量投入到可以进行GC调节的黑洞中!