0

这是一个难以解释的问题，也不希望有一个简单的答案，但认为值得一试。对可能会减慢与 Java 应用程序交互的长时间 Python 作业的原因感兴趣。

我们有一个 Tomcat 实例，它运行一个相当复杂且强大的 web 应用程序，称为Fedora Commons（不要与 Fedora 操作系统混淆），这是用于存储数字对象的软件。此外，我们有一个 python 中间件，它使用Celery执行长时间的后台作业。一项特殊的工作是摄取 400 多页的书，其中书的每一页都有一个大的 TIFF 文件，然后是一些较小的 PDF、XML 和元数据文件。在 10 到 15 分钟的过程中，从这些文件中创建衍生品，并将它们添加到 Fedora 中的单个对象中。

我们的问题：在摄取一本书的过程中，将文件添加到 Java 应用程序 Fedora Commons 中的数字对象的速度非常一致且可预测地变慢，但我不知道如何或为什么。

我认为摄取速度的图表可能会有所帮助，也许它掩盖了那些更熟悉 Java 的人可能会认识到的常见内存管理模式：

在此处输入图像描述

左上图是大 TIFF 的计时，被转换为 JP2，然后被摄取到 Fedora Commons。左下角是非常小的 XML 文件，没有衍生，也没有被摄取。如您所见，它们减速的曲线的斜率几乎相同。在右侧，这两个过程是一起绘制的。

我一直在互联网上试图了解 Java (GC) 中的垃圾收集，尝试不同的配置，但对减速没有太大影响。如果有帮助，这里有一些我们要传递给 Tomcat 的内存配置（我认为尾部主要是诊断性的）：

JAVA_OPTS='-server -Xms1g -Xmx1g -XX:+UseG1GC -XX:+DisableExplicitGC -XX:SurvivorRatio=10 -XX:TargetSurvivorRatio=90 -verbose:gc -Xloggc:/var/log/tomcat7/ggc.log -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC'

我们正在12GB此 VM 上使用 RAM。

我意识到可能导致这种行为的因素有很多，请原谅双关语，超出图表。但是我们与 Fedora Commons 和我们的 Python 中间件合作已经有一段时间了，并且大部分都取得了成功。这种减速你也可以设置你的手表，只是感觉与 Java / 垃圾收集有关，尽管我也可能错了。

任何有关挖掘更多信息的帮助或建议都将不胜感激！

4

3 回答 3

0

您说您怀疑 GC 是问题所在，但您没有显示 GC 指标。让你的程序通过一个分析器，看看为什么 GC 会过载。不找出原因就很难解决问题。

一旦找到问题所在，您可能需要更改代码，而不仅仅是调整 GC 设置。

于 2016-07-19T13:18:36.747 回答
0

感谢大家对 GC 和 Tomcat 分析的建议。事实证明，这种放缓完全是由于 Fedora Commons 构建数字对象的方式。我能够通过创建一个极其简单的数字对象来隔离这一点，迭代地添加接近零大小的数据流并观察进度。您可以在下图中看到这一点：

添加数据流的图表

减速曲线几乎相同，这表明这不是我们特定的摄取方法或文件大小。此外，这促使我重新挖掘有关 Fedora Commons 的旧论坛帖子，这些帖子确认单个对象并不意味着包含大量数据流。

有趣的是，这些知识是如何在数字对象的智能组织背后被混淆的，而不是特别是您对 Fedora 的性能影响，但这可能是另一个论坛的素材。

再次感谢所有的建议 - 如果没有别的，Fedora 的正常使用比以前更好地调整和嗡嗡声。

于 2016-07-22T12:21:42.190 回答
-1

好吧，与其查看晦涩的 GC 设置，不如开始显式管理内存，因此 GC 不会对您的执行产生太大影响。

于 2016-07-19T13:12:50.837 回答