处理缓慢的资源泄漏

使用Java监视器查找资源泄漏

查找缓慢的资源泄漏是使应用程序服务器长时间保持正常运行的关键。在这里，我解释了如何使用Java监视器来发现缓慢的资源泄漏，以及如何验证它们是实际的泄漏，而不仅仅是额外的预分配到某些HTTP连接器或数据库池中。如果执行这些步骤，则可以摆脱定期重新启动，并真正开始依赖服务器。

缓慢的资源泄漏是一个问题，因为它们迫使您定期重新启动应用程序服务器。反过来，这意味着您始终必须密切注意服务器，因为它们随时可能崩溃。最终，您不能依赖遭受缓慢资源泄漏的服务器。跟踪和解决缓慢的资源泄漏需要时间和耐心。一旦完成几次，这并不是很难做到的。

您还需要一个监视工具，该工具可以显示过去几周甚至几个月内来自服务器的统计信息。如果在服务器上启用了更长的数据存储，则可以使用Java监视器来执行此操作。要在Java监视器中启用此功能，请首先开始对服务器使用Java监视器。在带有服务器图形的页面上，可以通过切换到“ 1周”或“ 1个月”视图来启用更长的数据，如下所示。

第一步是查看过去一周中服务器的数据。为了发现资源泄漏，我发现绘制一周的数据比查看Java监视器标准的两天的数据要好。峰平滑了，这些图让我看看例如内存使用随时间如何发展。

为了预测即将发生的中断和缓慢的资源泄漏，我寻找两种模式。首先要检查的模式是，资源使用量不会随时间增加，而会随着每日流量的增加和减少而增加和减少。当一天的流量减少后，我预计资源使用量将回落到名义水平。我检查资源使用率是否每次都回落到同一水平。

请注意，我故意使用模糊的术语，例如“资源”。在实践中，我查看所有内存，文件描述符以及HTTP连接器和数据库连接池的图形。所有这些都是缓慢的资源泄漏的候选者。

当我看到资源似乎在增长的时候，我切换到数据的每月视图，甚至年度视图。这将压缩图中的数据，并使缓慢的资源泄漏更容易发现。

这是资源使用情况可疑更改的示例。在这种情况下，系统上的垃圾收集器突然变得更加活跃。此时，系统或系统负载没有变化。

我要注意的第二种模式是服务器重启重启后资源分配急剧下降。重新启动应用程序服务器时，如果资源使用量显着下降，则可能表明资源泄漏缓慢。重新启动之后，通常会像重新启动之前那样降低资源使用量，因为所有池和缓存都开始为空。

这是一个与重启相关的资源使用变化的示例，该变化并不表示有问题。重新启动后一段时间（甚至几天），资源使用情况已更改，但随后又恢复到正常水平并停留在该水平。

这是另一个。甚至更加可疑，因为重新启动后资源使用率并未恢复。它只是掉下来并停留下来。这几乎肯定是一个问题。

一旦确定资源使用模式可疑，就必须确认这实际上是一个缓慢的泄漏。很有可能是缓存或池中填充了更多缓存，从而随着时间的推移提高了资源使用率，而没有实际的泄漏。在这一步中，我将遍历线程和数据库池的图以及HTTP会话的图。我试图从那里的图表来解释提高的资源使用情况。

例如，在这里我们看到JVM中活动的线程，但线程数量有些奇怪的下降。这些下降表明系统重新启动。

但是，如果将该图与同一台服务器上的HTTP连接器池图进行比较，我会发现HTTP连接器池中预分配的线程数同样会上下波动。

这可能意味着没有缓慢的资源泄漏。最有可能的是，池中的额外线程保持状态，从而导致其他资源也增加。我可能会记下具体注意此服务器的信息，但我还没有开始深入研究资源泄漏。

只有当我无法解释池中分配的额外资源和活动HTTP会话的数量时，我才真正开始挖掘。如下所述：如何找到资源泄漏缓慢的根本原因。

解决缓慢的资源泄漏

我们研究了如何较早发现缓慢的内存泄漏。在那里，我们看到了如何找到缓慢的资源泄漏，以及如何将其与预期的池增长行为区分开。

在这里，我想解释一下如何确定缓慢的资源泄漏的根本原因，以及最终如何解决它们。修复缓慢的资源泄漏几乎总是需要更改代码，因此，如果您无法更改代码，则无法修复缓慢的资源泄漏。在这种情况下，您将必须找到可以的人。

确定缓慢的资源泄漏的根本原因的过程类似于发现快速泄漏的过程。主要的区别是时间对您不利。对于快速泄漏，您可以轻松地进行几次迭代，而缓慢的泄漏则可能需要数周或数月的时间才能显现出来。迭代可能是一年的四分之一。为了加快泄漏速度，您可以快速更改代码并“实时查看其运行状况”。对于较慢的泄漏，这仅意味着您将永远找不到真正的问题。

要遵循的步骤是：