什么会导致 Tomcat (v8) 到 CPU 具有周期性规律性的尖峰
What would cause Tomcat (v8) to CPU spike with periodic regularity
在 windows 2012 RT (x64) 测试服务器上，我们是 运行 一个 Tomcat 8 安装，CPU 的使用令人不安，因为它经常达到峰值用法。
该行为发生在我们的应用程序安装之后，但在任何人访问它之前。我已经访问了几页并测试了一些功能，但据我所知，没有任何东西可以造成这种行为。
服务器上有 2 个虚拟处理器，每隔约 20 秒，CPU 使用率将飙升（在 运行 Tomcat 一个处理器上）到 100% 10 秒（给予或接受）。见下文：
模式的规律性向我表明 Tomcat 8.
的安装或设置有问题
我已经安装了 YourKit Java Profiler（根据 SO 推荐），我希望它能阐明导致这些峰值的原因，但无法看到线程启动的原因-- 至少部分是因为我对 YourKit 很陌生。我确实将它附加到 Tomcat 启动文件，它似乎在跟踪行为。
catalina 日志在尖峰事件期间保持沉默（我的应用程序日志也是如此）但是当我停止时 Tomcat 有一些关于 ThreadLocals 开始但无法删除的消息然后：“......线程将随着时间的推移而更新，以尝试避免可能的内存泄漏。"
我周末离开了服务器 运行，这种模式一直持续到今天，所以我认为我的症状不会消失。无论正在启动什么现在已经消耗了系统上所有可用的 RAM 只是每 20 秒启动这些线程（and/or YourKit）。
隔离此异常 Tomcat activity 并希望停止或纠正它的可能方法是什么？
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() 负责吗？
处理器峰值未知，相关 activity
2015-12-08 更新 #2
YourKit 预先配置为隐藏某些 java class 名称模式，这些模式掩盖了对 java.lang.Thread 的深入研究。清除过滤器启用以下屏幕截图，显示尖峰事件期间的绝大多数处理时间是通过调用以下 3 种方法：
- java.io.WinNTFileSystem.canonicalize0
- java.io.WinNTFileSystem.getBooleanAttributes (inFile.exists())
- StardardRoot.java
抱歉，我对 Tomcat 或 DSpace 的了解还不够，无法知道是谁在启动这些任务。 （以防万一，第一行正上方的行是 java.lang.Thread.run()，然后是 <All threads>）
不是一个明确的答案，但对于评论来说太长了
在回顾了这个问题的更新并阅读了一些内容之后，我怀疑这个反复出现的问题是由 CuratorTask 引起的。原因是：
您获取的堆栈跟踪清楚地表明由 DSpace 库管理的 WorkerThread（因此 Tomcat 无可厚非）正在使用当时的处理器。
在阅读了一些关于 DSpace 本身的内容后，看起来它 有一个功能 允许用户定义 curator tasks 应该 定期执行 .
除此之外至少有一项任务是 - 根据文档 - 它是默认激活的，所以理论上可以默认激活任意数量的任务。
此外 this 对话显示 至少 1 个管理 任务 每 10 秒激活一次 。
所有这些都指向同一个方向。我建议使用 DSpace 的 UI（可能在管理员模式下）环顾四周并 找到活动的管理任务并验证它们的调度是否与您观察到的相符。
感谢查看并回复此查询的人。正如许多人所猜测的那样，问题与我们的设置和 Tomcat 的使用有关——而不是 Tomcat 本身的问题（很可能）。
这是在没有完全了解安装 DSpace 应用程序和 Tomcat 的情况下尝试回答问题，但我认为我知道的足够多，可能对后续用户有帮助。
安装应用程序 DSpace 时，Tomcat 的配置目录中有一些安装属性决定是否允许在没有 [=76] 的情况下立即反映编码文件中的更改=] 重启。我们的这些设置以前位于目录 [tomcat]/conf/Catalina/localhost/ 中，三个文件中的每一个都包含一个小的、无关紧要的 XML 文件，例如（例如 oai.xml）：
<?xml version='1.0'?>
<Context docBase="E:/dspace/webapps/oai"
reloadable="false"
cachingAllowed="true"/>
您可以在以下位置找到有关这些属性的文档 link：
https://wiki.duraspace.org/display/DSDOC5x/Installing+DSpace
该文档中有关于 reloadable 和 cachingAllowed 属性的建议。搜索“Tomcat 生产中的上下文设置”。这是摘录（强调我的）：
These settings are extremely useful to have when you are first getting started with DSpace, as they let you tweak the DSpace XMLUI (XSLTs or CSS) or JSPUI (JSPs) and see your changes get automatically reloaded by Tomcat (without having to restart Tomcat). However, it is worth noting that the Apache Tomcat documentation recommends Production sites leave the default values in place (reloadable="false" cachingAllowed="true"), as allowing Tomcat to automatically reload all changes may result in "significant runtime overhead".
It is entirely up to you whether to keep these Tomcat settings in place. We just recommend beginning with them, so that you can more easily customize your site without having to require a Tomcat restart. Smaller DSpace sites may not notice any performance issues with keeping these settings in place in Production. Larger DSpace sites may wish to ensure that Tomcat performance is more streamlined.
当我将这些布尔标志切换为 reloadable="false" 和 cachingAllowed="true" 尖峰 CPU 体验立即停止。 我不知道是否关于“较大站点”的警告适用于我们，或者“简化的性能”是否指我观察到的负面 activity。
我认为我们的安装可能存在其他问题导致了这种特殊表现；一个不祥的线索是我们的生产服务器似乎在 reloadable="true" 配置中使用这些标志运行。 Java、Tomcat、Windows、和 DSpace 都在同时获得新版本，因此很难确定为什么相似 Tomcat <context> 设置产生如此不同的结果。
我至少对现在有了新的行为并且系统已经平静下来感到满意。如果我学到更多，我会 post 更多，但接下来会专注于其他难题。
更新
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
此外，这里是 Tomcat 8 文档中 reloadable 的帮助文本：
Set to true if you want Catalina to monitor classes in /WEB-INF/classes/ and /WEB-INF/lib for changes, and automatically reload the web application if a change is detected. This feature is very useful during application development, but it requires significant runtime overhead and is not recommended for use on deployed production applications. That's why the default setting for this attribute is false. You can use the Manager web application, however, to trigger reloads of deployed applications on demand.
所以看起来最终答案是 Tomcat 8 on Windows 2012-R2 with the flag reloadable='true'轮询 WEB-INF/lib 和 WEB-INF/classes 的更改。要仔细阅读的文件夹和文件的数量很可能是这些激烈的尖峰 CPU 事件的原因。现在我将依赖 reloadable='false' 这肯定会为我们消除症状。
在 windows 2012 RT (x64) 测试服务器上，我们是 运行 一个 Tomcat 8 安装，CPU 的使用令人不安，因为它经常达到峰值用法。
该行为发生在我们的应用程序安装之后，但在任何人访问它之前。我已经访问了几页并测试了一些功能，但据我所知，没有任何东西可以造成这种行为。
服务器上有 2 个虚拟处理器，每隔约 20 秒，CPU 使用率将飙升（在 运行 Tomcat 一个处理器上）到 100% 10 秒（给予或接受）。见下文：
模式的规律性向我表明 Tomcat 8.
的安装或设置有问题我已经安装了 YourKit Java Profiler（根据 SO 推荐），我希望它能阐明导致这些峰值的原因，但无法看到线程启动的原因-- 至少部分是因为我对 YourKit 很陌生。我确实将它附加到 Tomcat 启动文件，它似乎在跟踪行为。
catalina 日志在尖峰事件期间保持沉默（我的应用程序日志也是如此）但是当我停止时 Tomcat 有一些关于 ThreadLocals 开始但无法删除的消息然后：“......线程将随着时间的推移而更新，以尝试避免可能的内存泄漏。"
我周末离开了服务器 运行，这种模式一直持续到今天，所以我认为我的症状不会消失。无论正在启动什么现在已经消耗了系统上所有可用的 RAM 只是每 20 秒启动这些线程（and/or YourKit）。
隔离此异常 Tomcat activity 并希望停止或纠正它的可能方法是什么？
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() 负责吗？
处理器峰值未知，相关 activity
2015-12-08 更新 #2
YourKit 预先配置为隐藏某些 java class 名称模式，这些模式掩盖了对 java.lang.Thread 的深入研究。清除过滤器启用以下屏幕截图，显示尖峰事件期间的绝大多数处理时间是通过调用以下 3 种方法：
- java.io.WinNTFileSystem.canonicalize0
- java.io.WinNTFileSystem.getBooleanAttributes (inFile.exists())
- StardardRoot.java
抱歉，我对 Tomcat 或 DSpace 的了解还不够，无法知道是谁在启动这些任务。 （以防万一，第一行正上方的行是 java.lang.Thread.run()，然后是 <All threads>）
不是一个明确的答案，但对于评论来说太长了
在回顾了这个问题的更新并阅读了一些内容之后，我怀疑这个反复出现的问题是由 CuratorTask 引起的。原因是：
您获取的堆栈跟踪清楚地表明由 DSpace 库管理的 WorkerThread（因此 Tomcat 无可厚非）正在使用当时的处理器。
在阅读了一些关于 DSpace 本身的内容后，看起来它 有一个功能 允许用户定义 curator tasks 应该 定期执行 .
除此之外至少有一项任务是 - 根据文档 - 它是默认激活的，所以理论上可以默认激活任意数量的任务。
此外 this 对话显示 至少 1 个管理 任务 每 10 秒激活一次 。
所有这些都指向同一个方向。我建议使用 DSpace 的 UI（可能在管理员模式下）环顾四周并 找到活动的管理任务并验证它们的调度是否与您观察到的相符。
感谢查看并回复此查询的人。正如许多人所猜测的那样，问题与我们的设置和 Tomcat 的使用有关——而不是 Tomcat 本身的问题（很可能）。
这是在没有完全了解安装 DSpace 应用程序和 Tomcat 的情况下尝试回答问题，但我认为我知道的足够多，可能对后续用户有帮助。
安装应用程序 DSpace 时，Tomcat 的配置目录中有一些安装属性决定是否允许在没有 [=76] 的情况下立即反映编码文件中的更改=] 重启。我们的这些设置以前位于目录 [tomcat]/conf/Catalina/localhost/ 中，三个文件中的每一个都包含一个小的、无关紧要的 XML 文件，例如（例如 oai.xml）：
<?xml version='1.0'?>
<Context docBase="E:/dspace/webapps/oai"
reloadable="false"
cachingAllowed="true"/>
您可以在以下位置找到有关这些属性的文档 link： https://wiki.duraspace.org/display/DSDOC5x/Installing+DSpace
该文档中有关于 reloadable 和 cachingAllowed 属性的建议。搜索“Tomcat 生产中的上下文设置”。这是摘录（强调我的）：
These settings are extremely useful to have when you are first getting started with DSpace, as they let you tweak the DSpace XMLUI (XSLTs or CSS) or JSPUI (JSPs) and see your changes get automatically reloaded by Tomcat (without having to restart Tomcat). However, it is worth noting that the Apache Tomcat documentation recommends Production sites leave the default values in place (reloadable="false" cachingAllowed="true"), as allowing Tomcat to automatically reload all changes may result in "significant runtime overhead".
It is entirely up to you whether to keep these Tomcat settings in place. We just recommend beginning with them, so that you can more easily customize your site without having to require a Tomcat restart. Smaller DSpace sites may not notice any performance issues with keeping these settings in place in Production. Larger DSpace sites may wish to ensure that Tomcat performance is more streamlined.
当我将这些布尔标志切换为 reloadable="false" 和 cachingAllowed="true" 尖峰 CPU 体验立即停止。 我不知道是否关于“较大站点”的警告适用于我们，或者“简化的性能”是否指我观察到的负面 activity。
我认为我们的安装可能存在其他问题导致了这种特殊表现；一个不祥的线索是我们的生产服务器似乎在 reloadable="true" 配置中使用这些标志运行。 Java、Tomcat、Windows、和 DSpace 都在同时获得新版本，因此很难确定为什么相似 Tomcat <context> 设置产生如此不同的结果。
我至少对现在有了新的行为并且系统已经平静下来感到满意。如果我学到更多，我会 post 更多，但接下来会专注于其他难题。
更新
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
此外，这里是 Tomcat 8 文档中 reloadable 的帮助文本：
Set to true if you want Catalina to monitor classes in /WEB-INF/classes/ and /WEB-INF/lib for changes, and automatically reload the web application if a change is detected. This feature is very useful during application development, but it requires significant runtime overhead and is not recommended for use on deployed production applications. That's why the default setting for this attribute is false. You can use the Manager web application, however, to trigger reloads of deployed applications on demand.
所以看起来最终答案是 Tomcat 8 on Windows 2012-R2 with the flag reloadable='true'轮询 WEB-INF/lib 和 WEB-INF/classes 的更改。要仔细阅读的文件夹和文件的数量很可能是这些激烈的尖峰 CPU 事件的原因。现在我将依赖 reloadable='false' 这肯定会为我们消除症状。