要监控的9大WebLogic性能指标

什么是Oracle WebLogic Server？

Oracle WebLogic Server（WLS）是当今市场上领先的Java Enterprise Edition（Java EE）应用服务器之一。WebLogic Platform提供了J2EE规范的健壮，成熟和可扩展的实现，是一个统一的，可扩展的平台，用于基于面向服务的体系结构（SOA）来开发和部署应用程序。

为了确保此类应用程序的可用性和性能，性能监视至关重要。在此博客中，我们讨论了性能监视解决方案需要涵盖的前8个领域，以便为IT运营团队提供主动监视WebLogic应用程序服务器及其上托管的应用程序的性能所需的见解。

窥视WebLogic Server的体系结构

为了确定为使WebLogic应用服务器获得最佳性能而需要关注的关键领域，让我们看一下部署Oracle WebLogic的典型应用程序体系结构。

WebLogic Server集中了应用程序服务，例如Web服务器功能，业务组件以及对后端企业系统的访问。它使用诸如缓存和连接池之类的技术来改善资源使用和应用程序性能。WebLogic Server还提供企业级安全性和强大的管理功能。

WebLogic Server在多层（或n层）体系结构的中间层中运行。这是放置在前端外部应用程序“客户端层”和数据库服务器“后端层”之间的层。WebLogic Server从中间件的位置开始提供应用程序服务，例如Web服务器的多种功能，业务逻辑以及与后端数据存储的连接。

WebLogic Server群集选项允许管理员在多个协作的WebLogic Server之间分配客户端请求和后端服务。客户端可以像访问单个WebLogic Server一样访问群集。随着工作量的增加，您可以将WebLogic Server添加到群集中以共享工作。群集使用可选的负载平衡算法在群集中选择能够处理请求的WebLogic Server。

WebLogic应用服务器的体系结构

WebLogic性能监控的9个关键领域

监视JVM性能 监视WebLogic的执行队列 监视WebLogic的WorkManager和卡住的线程 监视JDBC连接池性能 监视WebLogic JMS性能 监视WebLogic Java事务处理 监视JSP和Servlet性能 商业交易绩效 监视WebLogic Server正常运行时间

＃1监视JVM性能

WebLogic应用程序服务器在Java虚拟机（JVM）之上运行。因此，JVM中的瓶颈会严重影响WebLogic应用程序服务器的性能。因此，必须监视WebLogic服务器的JVM的性能以解决服务器端瓶颈并回答以下问题：

• JVM堆和非堆内存池的大小是否正确？
• 是否有任何线程占用过多的CPU，并且在观察到该代码段时正在执行哪个代码段？
• 在应用程序执行期间是否发生了内存不足异常？
• 垃圾回收是否花费太多时间，从而影响了应用程序的性能？
• 如果JVM中的内存使用量不断增加，那么Oracle WebLogic上部署的应用程序中是否存在内存泄漏？如果是，在哪里？
• 是否存在线程阻塞或死锁的实例？如果是，则涉及哪些线程和哪些代码行？
• 什么时候进行垃圾回收，并且每次释放多少内存？

JVM的监视必须是任何Java应用程序性能监视策略的重要组成部分。IT Ops和DevOps团队使用JVM性能指标来解决服务器端瓶颈。通过发现代码级问题，开发人员和架构师还可以从JVM监视中受益。

实用提示：

• 各个存储空间的最大限制也必须正确调整。
• 连续监视JVM内存空间和增长模式，以在内存不足时主动检测情况。
• 修复了导致未使用的对象用完堆内存的代码级问题。
• 发生过多的垃圾回收时，JVM的CPU使用率很高。当您看不到应用程序线程占用CPU时，请检查垃圾回收的性能。内存问题可能表现为CPU使用率过高，从而使性能诊断变得困难。

＃2监视WebLogic的执行队列

WebLogic Server收到请求后，会将其放入执行队列中。然后将此请求分配给执行该请求的线程。线程消耗服务器上的资源，因此处理请求的大量线程会导致使用更多的内存，并且还会增加上下文切换，从而降低性能。WebLogic管理员通常为关键应用程序配置单独的执行队列。通过使用多个执行队列，可以确保选定的应用程序可以访问固定数量的执行线程，而不管WebLogic Server上的负载如何。

执行队列中的请求处理

监视执行队列非常重要，因为可以在其中确定WebLogic服务器是否能够满足其请求工作负载。跟踪每个执行队列中正在使用的线程数和线程利用率级别。这可以帮助您主动确定WebLogic服务器过载的时间。

如果打开的套接字数大于分配的套接字读取器线程数，则可能需要传入请求以等待直到套接字读取器线程空闲为止。但是，必须平衡专用于从套接字读取消息并在服务器中执行任务的执行线程的数量。不断监视打开的套接字的数量–过多打开的套接字会导致性能下降。

实用提示：

• 调优这些线程池并发现正确的线程估计非常耗时，并且需要进行大量尝试。如果传入客户端请求的数量导致分配了所有执行线程，则在100％利用率下，WebLogic服务器将没有任何线程可用于服务传入请求。这会降低您的性能。
• 随着执行队列长度的增加，监视WebLogic服务器的吞吐量。在某个时候，增加线程数将导致足够的上下文切换，从而使队列的吞吐量开始下降。
• 持续跟踪线程池指标，例如分配，释放，创建，关闭和托管的请求。

＃3监视WebLogic的WorkManager和卡住的线程

WebLogic使用称为WorkManager的概念来确定工作的优先级并维护线程和线程池。可以在WebLogic级别由管理员或在应用程序级别由应用程序开发人员创建和配置WorkManager。通过WorkManager，您可以保证每个应用程序都将获得其可用资源（线程/连接）的块，或者可以限制资源量。

在WebLogic服务器的操作过程中，跟踪每个WorkManager正在处理的请求和每个WorkManager的未决请求非常重要。另一个关键指标是工作管理器中的线程卡住。如果线程在设定的时间内连续工作（非空闲），则WebLogic Server会将其诊断为阻塞。您可以通过更改在诊断出线程被阻塞之前的时间长度（Stuck Thread Max Time），以及更改服务器检查线程是否被阻塞的频率，来调整服务器的线程检测行为。

卡住的线程无法完成其当前工作或接受新工作。如果检测到许多卡住的线程，则可以关闭WorkManager本身。因此，监视卡住的线程数可以提供问题情况的主动指示。

实用提示：

• 跟踪滞留线程的推荐方法是跟踪JVM中的线程活动。

＃4监视JDBC连接池性能

在WebLogic上运行的应用程序经常需要访问后端数据库。建立和断开与数据库服务器的连接通常需要时间，并且会产生大量开销。WebLogic包括对JDBC连接池的内置支持。每个连接池都是WebLogic建立和维护的与后端数据库服务器的一组连接。当应用程序请求JDBC连接时，WebLogic服务器为它提供来自现有池的连接。当应用程序完成其工作时，它将连接返回到池以供其他连接使用。连接池的使用缩短了应用程序响应时间，并最大程度地减少了开销，因为跨多个客户端请求重新使用了连接。

WebLogic访问其连接池

监视JDBC连接池至关重要，因为数据库访问通常是Java应用程序的瓶颈。首先，必须跟踪连接池的可用性。在WebLogic服务器运行期间，跟踪连接池的利用率–即正在使用该池中的多少个连接，以及连接池与使用分配给它的最大连接数有多近。如果连接池用完容量，则应用程序对数据库服务器的访问将失败。因此，如果连接池使用量达到了该池中可能的最大连接数，则应考虑增加连接池的最大设置。另一个重要的度量是从池中获取数据库连接的等待时间。通常较长的等待时间通常表明连接池容量对于服务器正在处理的工作负载而言太小。如果连接的等待时间较长，请考虑增加JDBC连接池的大小。

处理JDBC连接池时遇到的另一个常见问题是连接泄漏。应用程序可以从池中请求连接，但不能将其返回到池中。WebLogic会检测到这种情况，并将泄漏的连接记录在连接池中。跟踪泄漏的连接数可以提供应用程序逻辑中潜在问题的指示。

实用提示：

• 分析连接池中可用JDBC连接的利用率，以避免由于必须等待JDBC连接而导致的性能下降。
• 诊断JDBC连接泄漏的最佳方法是分析WebLogic服务器的日志。只要检测到连接泄漏，就会记录一条警告，并且提供的堆栈跟踪通常可以提供有关应用程序代码问题所在的线索。

＃5监视WebLogic JMS性能

WebLogic Java消息服务（JMS）使应用程序可以通过交换消息相互通信。通信可以是点对点或发布/订阅。

JMS如何在WebLogic中工作

使用点对点消息传递，消息到达队列，并一直保留在队列中，直到使用者处理该消息或消息过期为止。队列的删除或服务器的关闭（在非持久消息的情况下）也会导致该消息被删除。

使用发布和订阅模型，消息将发送到主题，并仅传递给活动的使用者。

可以通过监视WebLogic服务器的关键JMS指标来检测应用程序之间的通信问题。连续跟踪当前排队的消息，待处理的消息以及消息的发送和接收速率。如果这些指标中的任何一个显示异常趋势，则可能表明潜在的应用程序问题。使用点对点消息传递时，监视每个队列的上述指标。如果队列中的消息没有被足够快地处理或根本没有被处理，则WebLogic服务器上存在通信问题，它将影响在其上执行的一个或多个应用程序的功能和性能。

在发布和订阅消息传递的情况下，监视主题中的消息，主题的订阅者以及一段时间内的待处理消息。

实用提示：

• 大消息积压通常是有问题的。这可能会导致服务器上的内存不足异常，从而阻止服务器进行生产性工作。大量积压也可能导致大量垃圾收集开销。
• 有几种方法可以调整应用程序以提高JMS性能。使用多线程使用者是避免过多消息排队的一种方法。参见https://docs.oracle.com/middleware/11119/wls/PERFM/jmstuning.htm#CHDBHBGF
• 尽可能利用分布式JMS队列，以提高JMS性能。

＃6监视WebLogic Java事务处理

WebLogic内置了Java Transaction API（JTA）来管理事务。JTA允许应用程序执行分布式事务，即访问和更新两个或多个网络计算机资源上的数据的事务。JTA指定事务管理器与分布式事务系统中涉及的各方之间的标准Java接口：应用程序，应用程序服务器和控制对受事务影响的共享资源的访问的资源管理器。

事务管理器负责做出最终决定，以 提交 或 回滚 任何分布式事务。提交决定应导致成功的交易；回滚使数据库中的数据保持不变。

管理员必须跟踪活动事务的数量，事务中止，回滚，一段时间内的提交，以确定由于过多的事务中止和回滚而导致应用程序性能下降的时间。

实用提示：

• WebLogic包括对“记录最近的资源（LLR）”事务优化的支持。LLR为事务处理提供了显着的性能改进。

＃7监视JSP和Servlet性能

Web模块的核心应用程序逻辑是在服务器端的JSP页面和servlet文件中实现的。用户首次访问JSP页面时，WebLogic会自动将JSP文件转换为servlet。Servlet的主要功能是接受来自Web浏览器的HTTP请求并返回HTTP响应。

当Web模块遇到很多请求或处理时间很长时，直接的问题将是增加的通信量或较慢的处理归因于一个或多个Servlet正在处理。用于WebLogic的监视工具可深入了解每个Servlet处理的请求以及每个Servlet的处理时间。通过比较各个Servlet的处理时间，管理员可以确定Web应用程序中需要优化的区域。

实用提示：

• 监视Servlet的平均执行时间以及每个Servlet的工作量。
• 随着时间的推移，工作负载的变化可能会导致性能问题，必须进行调查。
• 比较各个Servlet的执行时间可能会指示可能需要优化的代码区域。

＃8商业交易绩效

知道一个特定的servlet需要花费时间是有用的，但是接下来的下一个问题是：“为什么servlet需要花费时间来执行？” 管理员想知道导致速度慢的确切代码行。他们还想知道速度慢是否在Java处理中（例如，昂贵的方法调用），或者是否是由于对远程服务的外部调用（例如，对支付处理服务的REST API调用）引起的，还是慢是由数据库处理引起的，如果是，则是由哪些查询/查询引起的。

要达到这一详细级别，需要深入研究应用程序代码。这就是 业务事务跟踪的 来源。这是Java应用程序监视工具使用的一种常用方法，其中，现代JVM的工具API用于添加字节码工具，以捕获Java中的所有方法调用以及来自JVM的外部调用。此功能为管理员提供了发现和解决Java应用程序缓慢 问题所需的见解 。

实用提示：

• 事务跟踪以确定代码级问题不是免费的。调整WebLogic服务器大小时，请考虑事务处理的其他开销（堆内存，可用的CPU等）。
• 监视工具通常具有开发模式和生产模式。确保在生产环境中部署事务跟踪时，已打开生产模式以进行事务跟踪。

＃9监视WebLogic Server正常运行时间

很多情况下，服务器崩溃可能会发生并且不会引起注意，因为已将自动操作配置为在发生崩溃时重新启动服务器。跟踪WebLogic服务器的JVM的正常运行时间，并在WebLogic服务器重新启动时收到实例警告。

实用提示：

• 重新启动之前，请调查JVM的CPU，内存和线程堆栈跟踪，以检测必须重新启动服务器的可能原因。

监视WebLogic性能的各个方面

必须有一个主动的监视工具来监视WebLogic性能的以上所有九个关键领域。管理员可以使用这些指标来了解WebLogic配置问题和瓶颈。开发团队还可以从这些监视工具提供的见解中受益。他们可以识别导致应用程序运行缓慢的应用程序代码行或数据库查询。