【问题标题】:GC issue with QuickFIX/JQuickFIX/J 的 GC 问题
【发布时间】:2016-05-23 06:44:58
【问题描述】:

我们正在使用 QuickFIX/J 创建一个低延迟的 Java 应用程序。我们订阅了大约 50 个货币对,因此我们每天获得大约 4000000 个报价。这是因为我们从不同的流动性提供者那里获得它们。

我看到很多 GC 发生,在高峰时间我们的应用程序挂起并且没有响应。我尝试过使用 64 GB 堆,也尝试过使用 G1 进行 GC,但没有成功。你能建议我如何解决这个问题吗?

你之前有没有遇到过这个问题,你做了哪些 GC 优化?

我应该离开 QuickFIX/J 并尝试使用其他 FIX 引擎吗?您能否推荐一些可以满足我要求的开源/商业 FIX 引擎?

目前我正在使用 Java 7。迁移到 Java 8 会有帮助吗?

【问题讨论】:

  • 好吧 QuickixJ 不是为您处理的吞吐量而设计的。最好自定义 QuickfixJ 或修补 JVM。

标签: java garbage-collection finance quickfixj


【解决方案1】:

如果我们假设您每天工作 8 小时,那么您的平均速度为 138 滴答/秒。我很清楚极端情况很重要,但这就是我们所得到的。 138 滴答声/秒根本不是问题。我们每天使用 2 GB 堆就可以毫无问题地获得 x100。 很有可能,您有内存泄漏。你有 gc 日志记录吗? 如果没有,请立即安装。

这些是我们使用的标志:

-Xloggc:/gc-$(date +"%0d-%0m-%y-%0k%M").gclog -XX:+PrintGC详情 -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime -XX:+PrintGCC原因

GC 日志记录对性能的影响非常小。 如果您在获得 gc 日志后发布它,我们可以更进一步。

【讨论】:

  • 感谢您的回答,我将启用 GC 日志并发布
  • 这是我的报告,但持续时间较短。我会发布完整的一天运行
  • 7 分钟有点短 :-),问题没有表现出来。我认为需要更长的运行时间。此外,在运行 CMS 时,ParNewGC 是默认设置,因此您不需要它。我注意到您正在调整实验室大小,您是否注意到从中获得任何性能优势?
  • 我今天会发布我的 GC 日志,为期一整天。我没有改变实验室大小。
猜你喜欢
  • 1970-01-01
  • 2022-10-19
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-06-24
相关资源
最近更新 更多