应用程序随着时间的推移变慢 - Java + Python答案

【问题标题】：Application slows down over time - Java + Python应用程序随着时间的推移变慢 - Java + Python
【发布时间】：2016-07-19 13:00:53
【问题描述】：

这是一个难以解释的问题，也不希望得到一个简单的答案，但认为值得一试。对可能会减慢与 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'

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

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

感谢任何有关挖掘更多信息的帮助或建议！

【问题讨论】：

python部分是通过jython在jvm上运行的吗？还是一个单独的过程？如果是后者，您首先应该确定整个机器的哪个部分变慢了，即它是 java 还是 python 部分。
尝试将 Psi-Probe 添加到您的 Fedora Commons Tomcat 实例。通过仅查看作业完成时间，您无法判断 Fedora Commons 安装的哪个组件导致速度下降。问题可能是 Fedora、gSearch、Solr 或 Djatoka。通过添加 Psi-Probe，您将能够在 servlet 级别检查性能并更好地查明问题。 psi-probe.github.io/psi-probe
这太好了，谢谢@RickSarvas！我认识到其中许多组件与我们没有使用的 Islandora 密切相关。但是 Psi-Probe 对 Tomcat 来说听起来很笼统，它可能非常有用。感谢您的建议。

标签： java python tomcat garbage-collection fedora-commons

【解决方案1】：

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

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

【讨论】：

欣赏这个建议 - 我会看看我能做些什么来分析。我看过 GCC 日志，看到很多“调用”，我认为这些“调用”可能意味着“次要”GC，但不是很多主要的。但同意，分析结果会有所帮助（那些 GC Tomcat 设置来自其他人分析和调整他们的 Fedora Commons 摄取过程）。
不幸的是，大量的 GC 调用对于 Java 代码来说是相当标准的，尤其是在没有针对速度进行优化但针对资源使用进行优化的应用程序中。

【解决方案2】：

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

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

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

再次感谢大家的建议 - 如果不出意外，Fedora 的正常使用比以前更好地调整和嗡嗡声。

【讨论】：

【解决方案3】：

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

【讨论】：

当您说“显式管理内存”时，您是指在 Java 代码中吗？虽然我们可以访问 Python 代码，但无法编辑/更新 Fedora Commons 代码。
是的，我说的是 Java，但你也可以看看你的 Python 分配。就像 puhlen 说的，你还应该看看其他一些指标，cpu 负载、内存使用等。没有这些就很难给出建议。