10

在 Windows 2012 RT (x64) TEST 服务器上，我们正在运行 Tomcat 8 安装，CPU 使用率在其达到峰值使用率的规律性方面令人不安。

该行为发生在我们的应用程序安装之后但在任何人访问它之前。我已经访问了几页并测试了一些功能，但没有任何东西可以创建我所知道的这种行为。

服务器上有 2 个虚拟处理器，每隔约 20 秒，CPU 使用率（在运行 Tomcat 的一个处理器上）会飙升至 100%，持续 10 秒（给予或接受）。见下文：

周期性尖峰图

模式的规律性向我表明，Tomcat 8 的安装或设置有问题。

我已经安装了 YourKit Java Profiler（通过 SO 推荐），我希望它可以阐明导致这些峰值的原因，但无法看到线程启动的原因——至少部分是因为我的新奇到 YourKit。我确实将它附加到 Tomcat 启动文件中，它似乎正在跟踪行为。

catalina 日志在尖峰事件期间保持沉默（就像我的应用程序日志一样），但是当我停止 Tomcat 时，有一些关于 ThreadLocals 启动但无法删除的消息，然后：“......线程将随着时间的推移而更新尽量避免可能的内存泄漏。”

我让服务器在周末运行，这种模式一直持续到今天，所以我认为我的症状不会消失。现在无论启动什么，只要每 20 秒启动一次这些线程（和/或 YourKit） ，就已经消耗了系统上所有可用的 RAM 。

隔离这种异常的 Tomcat 活动并希望停止或纠正它的可能方法是什么？

YourKit 中有很多图表和标签，所以我不愿列出所有可能有用的东西。感谢您帮助我缩小 YourKit（或其他工具）可以提供给我的问题。

catalina 日志中有关启动的信息：

Apache Tomcat/8.0.23
Architecture: amd64
Java Home: C:\Program Files\Java\jre1.8.0_65
CATALINA_BASE: C:\Program Files\Apache Software Foundation\Tomcat 8.0

2015-12-08 更新

根据 Gergely 的要求，该应用程序是 DSpace 的本地安装。这是一个带有 Postgres SQL 数据库后端的 Java 应用程序。我们正在从这里定制它的开源版本：http ://www.dspace.org/introducing 。我不确定还有什么有用的，我认为堆栈跟踪更能说明什么正在运行（和没有运行）——见下文。

通过在 YourKit 中打开 Stack Telemetry，“CPU Estimation”可以通过将光标拖过一段时间的分析器历史来实现。对我来说，看起来所有 CPU 都在空转。Java 文件是Tomcat 例程下图所示的吗？它们并没有因为与 DSpace 相关（尽管我不是专家）而让我感到震惊，而且在 CPU 达到峰值时看起来也没有任何工作正在完成。

注意：堆栈跟踪在安静期间是相同的——唯一的区别是 CPU 时间（毫秒）是数百毫秒而不是数千毫秒。为了比下面更直接的比较，驼峰在 Thread.run() 中表示约 8,000 毫秒，而安静期消耗约 125 毫秒的 cpu 时间（尽管涵盖的时间量大致相同）。

最后，当请求应用程序的页面时，调用树中会出现一个后续的代码分支。如果它发生在峰值期间，加载整个页面可能只需要 400 毫秒的 CPU 时间。出现的代码分支是 ApplicationFilterChain.java 作为与 PooledExecutor$Worker.run() 旁边的一个完整的单独分支——两者都位于层次结构中的 java.lang.Thread.run() 之下。

试图解释堆栈跟踪时：EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run()负责吗？

没有已知的相关活动的处理器峰值

CPU 分析

2015-12-08 更新 #2

YourKit 预先配置为隐藏某些 java 类名模式，这些模式掩盖了对 java.lang.Thread 的深入了解。清除过滤器启用了以下屏幕截图，显示峰值事件期间的绝大多数处理时间是通过调用以下 3 个方法：

  • java.io.WinNTFileSystem.canonicalize0
  • java.io.WinNTFileSystem.getBooleanAttributes (inFile.exists())
  • StardardRoot.java

我对 Tomcat 或 DSpace 还不够了解，无法知道是谁在启动这些任务，我深表歉意。（如果重要的话，第一行正上方的行是java.lang.Thread.run()then <All threads>）

更好的堆栈跟踪

4

2 回答 2

15

感谢那些查看并回复此询问的人。正如许多人推测的那样，问题与我们的设置和 Tomcat 的使用有关——而不是 Tomcat 本身的问题（很可能）。

这是在不完全了解安装 DSpace 应用程序和 Tomcat 的情况下回答问题的尝试，但我认为我知道的足够危险，并且可能对后续用户有所帮助。

安装应用程序DSpace时，Tomcat 的配置目录中有一些安装属性，这些属性决定是否允许在不重新启动 Tomcat 的情况下立即反映编码文件的更改。我们的这些设置以前在目录[tomcat]/conf/Catalina/localhost/中，三个文件中的每一个都包含一个小的、无关紧要的 XML 文件，例如（例如 oai.xml）：

<?xml version='1.0'?>
<Context docBase="E:/dspace/webapps/oai"
    reloadable="false"
    cachingAllowed="true"/>

您可以在以下链接中找到有关这些属性的文档： https ://wiki.duraspace.org/display/DSDOC5x/Installing+DSpace

该文档中包含有关reloadable和cachingAllowed属性的建议。搜索“生产环境中的 Tomcat 上下文设置”。这是摘录（重点是我的）：

当您第一次开始使用 DSpace 时，这些设置非常有用，因为它们可以让您调整 DSpace XMLUI（XSLT 或 CSS）或 JSPUI（JSP）并看到您的更改由 Tomcat 自动重新加载（无需重新启动 Tomcat） . 然而，值得注意的是，Apache Tomcat 文档建议生产站点保留默认值（reloadable="false" cachingAllowed="true"），因为允许 Tomcat 自动重新加载所有更改可能会导致“显着的运行时开销”。

是否保留这些 Tomcat 设置完全取决于您。我们只是建议从它们开始，这样您就可以更轻松地自定义您的站点，而无需重新启动 Tomcat。较小的 DSpace 站点可能不会注意到将这些设置保留在生产环境中的任何性能问题。 较大的 DSpace 站点可能希望确保 Tomcat 的性能更加精简。

当我将这些布尔标志切换到时reloadable="false"，cachingAllowed="true" CPU 体验立即停止。我不知道关于“大型网站”的警告是否适用于我们，或者“精简性能”是否可以指我观察到的负面活动。

我认为我们的安装可能存在其他问题，导致了这种特殊的表现；一个不祥的线索是我们的生产服务器似乎在reloadable="true"配置中使用这些标志运行。Java、Tomcat、Windows和DSpace 都在同时获得新版本，因此很难确定为什么类似的 Tomcat<context>设置会产生如此不同的结果。

我至少现在满足于有新的行为并且系统已经平静下来。如果我了解更多，我会发布更多信息，但接下来将关注其他难题。

更新

FWIW，属性是直接控制 Tomcat 的设置，它们在版本之间发生了变化。例如，cachingAllowed在版本 8 中被移除，这意味着它可以从Context元素中移除。相比：

https://tomcat.apache.org/tomcat-8.0-doc/config/context.html#Attributes https://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Attributes

为了更好地衡量，这里是reloadableTomcat 8 文档中的帮助文本：

如果您希望 Catalina 监视 /WEB-INF/classes/ 和 /WEB-INF/lib 中的类的更改，请设置为 true，并在检测到更改时自动重新加载 Web 应用程序。此功能在应用程序开发期间非常有用，但它需要大量运行时开销，因此不建议在已部署的生产应用程序中使用。这就是该属性的默认设置为 false 的原因。但是，您可以使用 Manager Web 应用程序来按需触发重新加载已部署的应用程序。

因此，最终的答案似乎是 Windows 2012-R2 上带有 reloadable='true' 标志的 Tomcat 8 轮询对 WEB-INF/lib 和 WEB-INF/classes 的更改。要仔细阅读的文件夹和文件的数量很可能是这些激烈的、尖峰 CPU 事件的原因。现在我将依赖 reloadable='false' ，这肯定会为我们消除症状。

于 2015-12-09T20:56:17.877 回答
1

不是一个明确的答案，但评论太长了

在查看了有关此问题的更新并阅读了一些内容后，我怀疑此反复出现的问题是由 CuratorTask 引起的。原因是：

  • 您获得的堆栈跟踪清楚地表明，由 DSpace 库管理的 WorkerThread（因此不应责怪 Tomcat）当时正在使用处理器。

  • 在阅读了一些关于DSpace本身的信息后，它似乎有一个功能，允许用户定义应该定期执行的curator 任务。

  • 除此之外，至少有一个任务- 根据文档 - 它是默认激活的，因此理论上可以默认激活任意数量的任务。

  • 此外，此对话显示至少 1个每 10 秒激活一次的策展任务。

所有这些共同指向同一个方向。我建议使用 DSpace 的 UI（可能在管理员模式下）环顾四周并找到活动的策展任务，并验证它们的调度是否与您观察到的相符。

于 2015-12-08T18:46:01.200 回答