内容


利用 WebSphere Application Server for z/OS 中面向目标的工作负载管理

将 WebSphere Application Server 与 IBM Workload Manager for z/OS 集成

Comments

引言

运行在 z/OS 上的 J2EE 服务器由多个地址空间或进程实现。存在一个控制区域、至少一个服务区域,以及一个(或无)控制区域 Adjunct,如图 1 所示。

控制区域用于接受客户端请求(HTTP、IIOP),并根据预定义的规则将请求划分为不同的服务类别。例如,HTTP 请求基于不同的 URL 进行分类,从而提供了为部署在同一个应用程序服务器上的不同应用程序组件设定面向目标的服务级别的能力。完成工作负载分类以后,控制区域将请求插入到由 IBM Workload Manager (WLM) for z/OS 管理的队列。服务区域将从这些队列中选取请求,并在服务区域地址空间中处理请求。

控制区域由用户控制,从而意味着您可以使用命令启动或停止控制区域。用户不直接控制服务区域。相反,WLM 将根据需要动态地启动和维护服务区域,以满足工作负载的性能目标。IBM WebSphere Application Server 利用 WLM 的队列管理器服务维护队列,将请求从控制区域传递到服务区域。稍后将对此进行更多的讨论。(就本文而言,控制区域 Adjunct 并不重要,因此将不再做进一步的讨论。)

图 1. WebSphere Application Server for z/OS 体系结构
图 1. WebSphere Application Server for z/OS 特殊体系结构
图 1. WebSphere Application Server for z/OS 特殊体系结构

在研究此配置的细节之前,下面首先列出 WebSphere Application Server for z/OS 采用拆分地址空间体系结构的一些原因:

  • 面向业务的工作负载管理:

    • 体系结构提供了区分较高优先级查询(例如,在 0.05 秒内完成 95%)与较低优先级查询(例如,在 5 秒内完成 80%)的功能。
    • WLM 能够动态管理服务区域数量,以便实现总体系统吞吐量目标。
  • 分离事务与应用程序执行:

    • “受信任的代码”在控制区域中运行,用户应用程序代码在服务区域中运行,从而将应用程序执行与事务管理完全隔离。
    • 事务恢复由控制区域处理。
    • WebSphere Application Server 提供了附加的异常处理机制。例如,事务超时处理:在控制区域检测到事务超时的情况下,可设置控制区域重新启动服务区域以清理系统资源,从而防止由于应用程序挂起而阻塞资源。

本文的其余内容将详细研究 WebSphere Application Server for z/OS 与 Workload Manager for z/OS 之间的集成。

Enclave 和 WebSphere Application Server 事务分类

Enclave 的概念最初是在 MVS™ 5.2.0 中引入的,主要适用于来自 WebSphere Application Server、IBM DB2® DDF、IBM HTTP Server 等的“新工作负载”。Enclave 提供了跨 Sysplex 中的多个地址空间和系统管理业务事务性能的能力。换句话说,子系统(例如 WebSphere Application Server)将创建 Enclave(某种令牌)来表示每个工作请求,然后可以在 Enclave 边界内封装不同地址空间中用于事务执行的基础 z/OS 可分派单元(可信计算基础 (TCB) 或服务区域)。

Enclave 具有一些重要功能:

  • 可以独立于地址空间的性能目标对整个事务执行进行调度以满足 Enclave 的性能目标,可分派单元运行于这些地址空间之上。
  • 该业务事务的资源消耗(CPU、I/O))也可交由 Enclave 自己负责。
  • 使用 Enclave,可以对跨越从 WebSphere Application Server 到其他子系统的整个业务事务分配性能目标,并获得跨地址空间边界的事务资源消耗的集成视图。

共有两种类型的 Enclave:依赖 Enclave 实际上是现有地址空间的逻辑扩展。它简单地从原始地址空间继承服务分类。相反,独立 Enclave 则是单独地进行分类的。图 2 说明了依赖和独立 Enclave 的概念。WebSphere Application Server for z/OS 使用独立 Enclave,因此独立 Enclave 将是我们讨论的重点。

图 2. 依赖和独立 Enclave
图 2. 依赖和独立 Enclave
图 2. 依赖和独立 Enclave

使用独立 Enclave

如果没有为 J2EE 应用程序指定服务分类(甚至没有为 WebSphere Application Server 类型的工作负载设置缺省服务分类),则会将 Enclave 划分到 SYSOTHER 服务分类中,这是系统定义的服务分类,具有 WLM 的自助服务目标,该目标本质上就是让系统“竭尽所能地做得最好”。这样的结果在于,仅当没有资源竞争时才能为工作负载提供服务。因此,将 WebSphere Application Server 工作负载划分为 SYSOTHER 分类是不可取的,因为在受约束的环境中,该工作负载将无法与其他“更高优先级”的工作负载竞争资源。更糟的是,如果传入 WebSphere Application Server 的工作请求没有在某段时间内完成,则很可能会触及各种超时参数,例如 HTTP 超时、事务超时,等等。发生这种情况时,控制区域在缺省情况下将终止服务区域,以清理环境并防止重要系统资源被阻塞。服务区域将由 WLM 重新启动以继续该工作。如果 CPU 资源在该时段中非常紧张,则服务区域将很难启动。当所有这一切发生时,活动系统中的请求可能排队等候并超过另一个超时参数,从而导致另一个服务区域重新启动,同样影响到应用程序可用性。

请求分类

可以使用 XML 工作负载分类文档对具有不同服务分类的传入 HTTP、IIOP 和消息驱动 Bean 工作请求分类,并向传入请求分配 XML 文件事务分类 (TCLASS)。TCLASS 值将传递给 WLM,后者最终将 TCLASS 与某个服务分类和某个报告分类关联(如果指定了的话)。

有关使用 XML 工作负载分类文档和在 WLM 中分类的指导,请参见 WebSphere Application Server V6.1 信息中心

不要在系统中使用太多服务分类的建议实践仍然有效,即使对于 WebSphere Application Server 工作负载也是如此。从 z/OS 的角度看,由于 WLM 不断对系统资源进行采样和调整以帮助所有服务分类满足性能目标,太多的活动服务分类将会减慢调整过程(WLM 在每个十秒的间隔期间做出一次调整)。太多的服务分类可能导致某些急需资源的工作负载没有得到及时关注。通常,系统中的活动服务分类周期的数量不应该超过 30。通常,z/OS 用户采用将工作负载划分到较少服务分类中并根据情况组合相似工作负载的原则。

尽管您能够将不同的 WebSphere Application Server 应用程序或组件划分到不同的性能目标分类中,但是不应该通过定义非常细粒度的分类来滥用此机制。

要注意,并非所有 Web 应用程序都能够使用基于 URI 的分类。此类应用程序的示例包括诸如 Struts、Ajax 等使用框架的应用程序,其中客户端请求的 URL 对不同种类的请求来说是完全相同的。这些类型的应用程序将阻止您基于 URL 对不同的业务事务分类。

队列服务

工作队列

WebSphere Application Server 旨在处理大量的并行短时间任务,工作队列和线程池是两个经常用来处理并行工作负载的组件。

在所有平台上,WebSphere Application Server 均实现线程池来处理客户端发出的请求。WebSphere Application Server for z/OS 将工作队列机制与线程池组合起来为客户端请求提供服务。WebSphere Application Server for z/OS 的控制区域将请求插入与服务区域关联的工作队列,然后服务区域从绑定的工作队列中选择请求,并在线程池内进行处理。

工作队列机制是从 WLM 队列管理器服务继承而来的。此外,WebSphere Application Server for z/OS 还利用 WLM 应用程序环境来动态管理服务区域地址空间,以便满足应用程序的总体性能目标。

用 WLM 队列管理器服务的术语来讲,如图 3 所示,控制区域是队列管理器,服务区域是 WLM 管理的服务器地址空间。

图 3. Workload Manager 队列管理器服务
图 3. Workload Manager 队列管理器服务
图 3. Workload Manager 队列管理器服务

应用程序环境

在图 3 中,ApplEnv(应用程序环境)表示这样一种方法,此方法将相似的服务器程序分组在一起,并根据需要动态启动或停止服务器地址空间(WebSphere Application Server 服务区域),以处理工作负载变化和保证性能目标得到满足。WebSphere Application Server for z/OS 利用了动态应用程序环境,您不需要在 WLM 中手动定义该环境,因为 WebSphere Application Server 会自动处理此任务。

对于 J2EE 服务器,动态应用程序环境的名称通过管理控制台指定为 Cluster 过渡名称;请从管理控制台导航到 Application server => Custom Properties

缺省情况下,为 J2EE 服务器配置了单个服务区域。可以启用多个服务区域实例,最小和最大数量可以通过管理控制台设置,如图 4 所示。

图 4. 应用程序服务器实例
图 4. 应用程序服务器实例
图 4. 应用程序服务器实例

如果启用了多个服务区域,请确保指定服务区域的最大实例数量,以防止由于过多的服务区域启动而导致服务下降。同时,通过指定最小实例数量,您可以在 WebSphere Application Server 的整个生命周期中拥有许多活动的服务区域。

WLM 队列管理器服务依赖应用程序环境。如图 3 所示,控制区域将表示工作请求的 Enclave 插入到应用程序环境中与服务分类关联的 WLM 工作队列。在每个应用程序环境中,只有一个工作队列映射到一个服务分类;工作队列将仅遵循服务分类的名称。可以有更多的工作队列为单个服务分类提供服务,但是要将它们分离到不同的应用程序环境(服务器)中。

工作队列与服务区域的关系

正如上面提到过的,在 WebSphere Application Server 应用程序环境中,工作队列的数量等于为 WebSphere Application Server 上运行的应用程序划分的服务分类的数量。

下面,让我们研究一下工作队列与服务区域之间的关系,以及它们在这两种场景的上下文中对总体性能的影响(其中 M = 服务区域的数量):

  • 单个服务区域:M = 1
  • 多个服务区域:M >1

可以使用 WLM 工作队列查看工具 WLMQUE 来监视活动的服务器地址空间(WebSphere Application Server 服务区域)、服务分类工作队列、在工作队列中等待的当前请求数量、服务区域从队列中接收的请求总数、由于关联而直接发送到服务区域的请求数量,等等。(为了便于说明,下面包括了从 WLMQUE 工具中捕获的屏幕。)

单个服务区域:M=1

缺省情况下,z/OS 上的 J2EE 服务器有一个服务区域。在此场景中,服务区域没有与任何特定的服务分类绑定,这意味着所有的工作请求将由单个服务区域选择,并在该服务区域中得到服务。但是,如果出现可使用多个服务区域来缓解的性能瓶颈,WLM 将不能启动附加的服务区域,因为没有启用多个服务区域功能。因此,这种具有单个服务区域的应用程序环境称为“非托管”应用程序环境。

在此场景中,具有不同服务分类的所有请求都将在该服务区域中并发地执行。在该服务区域中,工作线程 (TCB) 将使用表示请求的 Enclave 的服务分类运行。

图 5. 显示单个服务区域的 WLMQUE 面板
图 5. 显示单个服务区域的 WLMQUE 面板
图 5. 显示单个服务区域的 WLMQUE 面板

取自 WLMQUE 工具的图 5 表明,存在单个名为 Y6C001 的 ApplEnv,并且属于 WebSphere Application Server 服务器 Y6SRVA1。请注意 ApplEnv 标题行中的以下重要列:

  • Dyn 指示该应用程序环境是动态还是静态的。
  • Qlen 显示队列中已准备好分派到某个服务区域的当前工作请求数量。如果为系统提供足够多的压力负载,您将观察到队列中当前正在等待的请求数量。
  • 值为 ******** 的 WorkQue 指示这是非托管应用程序环境。
  • SvAS 是 WebSphere Application Server 服务区域的地址空间的 ID,在上图中为“0097”。
  • WUQue 是从工作队列接收的请求总数。
  • AffQue 是由于客户端关联(将在稍后讨论)而直接发送到服务区域的工作请求数量。

多个服务区域:M > 1

在 WebSphere Application Server 中启用了多个服务区域时,行为将与单个服务区域场景不同。本质上,在任何给定的时间,任何服务区域将仅绑定到单个特定的服务分类工作队列,并从该队列选择请求。

为了说明这一点,下面使用以下设置为某个服务器启用了多个服务区域实例:

  • 服务区域实例数量设置为最小 2 个,最大 4 个。
  • 服务器上部署了单个应用程序,传入的工作负载划分为三个服务分类:CBDEF、CBHI 和 CBLO。
  • WebSphere Application Server 应用程序的缺省分类为 CBDEF。
图 6. 显示多个服务区域的 WLMQUE
图 6. 显示多个服务区域的 WLMQUE
图 6. 显示多个服务区域的 WLMQUE

图 6 显示了服务器已启动以后的 WLMQUE 工具。最小数量的两个服务区域已经启动,其 ASID 分别为 00A4 和 00AA。请注意单个服务区域与多个服务区域之间的区别。例如,WorkQue 列现在具有名称“CBDEF”,这是 WebSphere Application Server 类型的工作负载在此测试环境中的缺省服务分类。

当具有不同服务分类 CBHI 的新请求传入时,WLM 启动新的服务区域以绑定到新的工作队列 CBHI,该请求通过 CBHI 工作队列,然后在 ASID 为 00A9 的新服务区域中执行,如图 7 所述。

图 7. 显示具有新请求的多个服务区域的 WLMQUE
图 7. 显示具有新请求的多个服务区域的 WLMQUE
图 7. 显示具有新请求的多个服务区域的 WLMQUE

如果 WLM 能够启动新的服务区域(因为还没有达到最大服务区域数量),那么它将会那样做。WLM 并不是简单地将任何服务区域从 CBDEF 转换到 CBHI;仅当没有其他选择时,它才会将某个服务区域的绑定服务分类工作队列转换到另一个服务分类工作队列(例如,如果当前服务区域的数量达到服务区域最大数量限制)。此外,由于 WLM 可以帮助动态维护服务区域的数量以适应工作负载变化,它还可能在生产期间启动新的服务区域,以帮助工作负载实现性能目标。

如果 WLM 能够启动新的服务区域,则将由该服务区域提供服务的请求的处理将延迟到该服务区域启动以后。如果不能容忍动态启动新服务区域的延迟和开销——尤其是在所部署的应用程序非常复杂的情况下——则替代解决方案是将最小服务区域数量设置为等于最大数量。

多少服务分类才合适?

一般来说,为 WebSphere Application Server 应用程序划分的服务分类数量不要多于服务区域的最大数量。例如,如果将最大服务区域数量设置为 5,则不要将应用程序划分为五个以上的服务分类。

假设您的 WebSphere Application Server 正在保持最大服务区域数量,这些服务区域全都绑定到不同的服务分类工作队列。新的请求传入并滞留在新的服务分类工作队列中。现在所有服务区域均绑定到现有工作队列,没有任何服务区域能够立即转换到新的服务分类工作队列。转换持续时间无法精确计时;可能为数秒或数分钟。工作请求只能滞留在队列中,推迟不确定的时间长度,同时可能触及某些超时设置。

作为一般实践,始终要设置 N <= M,其中 N = 映射服务分类的数量(包括用于未分类的请求的服务分类),M = 服务区域的数量。

每个服务区域都具有对实际存储的需求。如果系统上的实际存储量有限,您可能担负不起拥有许多服务区域。请确保有足够的存储来支持预期的工作负载吞吐量所需要的最大服务区域数量。考虑到应用程序的服务分类数量应该少于服务区域数量的事实,您可能担负不起将应用程序划分为许多服务分类。

关联

在理想的世界中,高度可伸缩的系统将具有无状态的应用程序。然而在现实世界中,用户需要在服务器端存储某些信息(例如,典型零售应用程序中的购物车信息)。J2EE 应用程序通常将此类信息存储在内存中的会话对象中,以实现更好的性能或实现更好的用户体验。当将用户状态存储在会话对象中时,这通常意味着给定用户的请求全都针对同一个服务器实例。将给定会话的所有 HTTP 请求发送到特定 J2EE 服务器的实践称为会话关联。在 WebSphere Application Server for z/OS 中,单个 J2EE 服务器由多个服务区域提供支持,内存中的会话对象存储在服务区域中,显然需要确保由适当的服务区域为请求提供服务。

WebSphere Application Server 中的会话关联是通过利用 WLM 的临时关联扩展功能来实现的。通过在 IWM4QIN 界面中指定服务区域的区域令牌,队列管理器能够将请求直接发送到服务区域,而不是将请求插入到服务分类工作队列。

在 WLMQUE 工具(图 8)中,带客户端关联的请求直接发送到 AffQue 列中报告的服务器区域。WUQue 列仅报告从服务分类工作队列接收并绑定到该服务区域的请求数量。

图 8. 显示会话关联的 WLMQUE
图 8. 显示会话关联的 WLMQUE
图 8. 显示会话关联的 WLMQUE

仅当大部分请求在这些服务分类工作队列中排队并由服务区域选择时,WLM 才能够动态维护服务区域池以满足性能目标。考虑客户端关联后,工作请求将在 WLM 控制之外直接路由到服务区域。

此外,当某些服务区域中存在关联信息时,将会阻止 WLM 使用 IWMTAFF 界面终止服务区域,该界面将服务区域标记为后续的工作请求仍然需要它们。在 z/OS SDSF 面板(图 9)中,具有临时关联的服务区域由 TEMP-AFF 指示。

图 9. z/OS SDSF 面板
图 9. z/OS SDSF 面板
图 9. z/OS SDSF 面板

当队列管理器将带关联的工作请求直接发送到服务区域时,它将不通过为请求指定的服务分类工作队列。例如,可以将分类为 CBHI 的 HTTP 请求发送到与 CBDEF 工作队列绑定的服务区域,因为该请求附带了 Cookie,其中具有与先前绑定到 CBDEF 工作队列的服务区域建立的会话关联。

如果您是应用程序设计人员,要注意会话关联将覆盖服务分类映射。如果希望将应用程序划分到不同的服务分类,并将请求分离到不同的服务区域中以便处理,那么需要记住,会话关联可能将不同服务分类中的后续请求指引到之前创建会话对象的同一个服务区域。这可能阻止您在应用程序中利用“服务分类映射”。

均匀的 HTTP 请求分配

当多个服务区域与同一个服务分类工作队列绑定时,WebSphere Application Server 缺省将不带会话关联的新传入请求分配到某个“热”服务。热服务策略可以提供更好的性能,因为最常用应用程序方法的即时编译代码已经准备好运行,必需的页面已加载到内存中从而减少了 I/O 开销,数据已经缓存,等等。

热服务策略具有在服务区域之间不均衡地分配 HTTP 会话的可能。这取决于没有会话关联的请求到达系统中的速度,以及热服务中的空闲 TCB 的数量。如果热服务具有空闲 TCB,则缺省行为是将无会话关联的请求发送到还没有与该请求建立关联的服务区域。由于在建立关联以后不能将请求重定向到空闲服务区域,热服务可能由于过多的排队、实际存储不足或垃圾收集而导致性能下降。

避免热服务缺点涉及到确保均匀分配还没有与服务区域建立关联的 HTTP 请求,从而应该导致在服务区域之间均衡分布会话关联。为了确保 WLM 均匀分配 WebSphere Application Server 中的 HTTP 请求,应该将服务器的 WLMStatefulSession 参数设置为 true(图 10)。

图 10. 确保 HTTP 请求的均匀分配
图 10. 确保 HTTP 请求的均匀分配
图 10. 确保 HTTP 请求的均匀分配

此外,您可能还需要对分类映射文件和 WLM 做出某些更改,如 WebSphere Application Server 信息中心所述。

可以使用 WLMQUE 工具来监视均匀分配行为。在如图 11 所示的面板中,有两个服务区域与同一个服务分类工作队列 CBDEF 绑定。在传入一定量的请求之后,您可以看到两个可用服务区域之间的会话关联数量(Aff 列)相当均匀。

图 11. 显示会话关联的 WLMQUE
图 11. 显示会话关联的 WLMQUE
图 11. 显示会话关联的 WLMQUE

请注意,WLM 均匀分配实际并不以简单的循环方式,跨服务区域相等地平衡不带会话关联的 HTTP 请求。它实际保证的是会话关联在服务区域之间的均等分配。

线程池管理

正如前面提到过的,WebSphere Application Server for z/OS 在每个服务区域中有一个线程池为客户端请求提供服务。此线程池管理与 WebSphere Application Server 的分布式版本稍有不同。

请求占位符

当请求传入时,WebSphere Application Server 控制区域从网络接收请求,并创建 Enclave 来表示请求。在服务区域处理请求之前,请求被放在 WLM 工作队列中。与分布式 WebSphere Application Server 不同,WebSphere Application Server for z/OS 不需要使用线程来容纳请求,而是使用 WLM 队列作为占位符。

对于处理相对较高的压力负载的分布式 WebSphere Application Server 系统,您可能需要大量的线程来容纳客户端请求;由于密集的上下文切换,系统开销将会更高。在这点上,WebSphere Application Server for z/OS 为您提供了更容易的线程数量管理。您只需设置用于工作负载执行的适当工作线程数量,而不必考虑客户端请求的数量。

线程数量

在 WebSphere Application Server 中,请求处理是在工作线程上执行的。大量的系统基准测试已表明,对于设计和实现良好的应用程序,具有两到三倍于 CPU 数量的工作线程数量会使 LPAR 的处理器资源满负荷。取决于应用程序工作负载的性质,您可以使用管理控制台间接控制服务区域中的线程数量(图 12)。

图 12. 在管理控制台中控制工作线程
图 12. 在管理控制台中控制工作线程
图 12. 在管理控制台中控制工作线程

在 WebSphere Application Server 管理控制台中,您可以设置以下工作负载概要:

  • ISOLATE:1 个线程
  • CPUBOUND:(CPU 数量 – 1),最小值 = 3
  • IOBOUND:(CPU 数量 * 3),最小值 = 5,最大值 = 30;这是服务器的缺省概要。
  • LONGWAIT: 40

下面是一些针对各种工作负载概要设置的典型使用模式。任何给定环境的最适当值可能与这里显示的值不同,并且只能通过测试和性能数据分析推断出来。

例如,请考虑缺省概要 IOBOUND。工作线程的数量是 CPU 数量的三倍,但是不小于 5 和不大于 30。对于使用数据库的典型 WebSphere Application Server 应用程序,IOBOUND 足以让应用程序驱使系统达到最大的利用率。

如果应用程序是 CPU 密集型的(例如,涉及大量 XML 处理的应用程序),不需要多少线程就会使 CPU 达到满负荷。单个工作线程也许就能迫使 LPAR 中的一个逻辑 CPU 达到 100% 的利用率,因此将总线程数量设置为 CPU 数量减 1。

对于某些将会挂起工作线程以便对外部系统发出长时间等待的远程调用的应用程序,例如 ERP、CRM 或某些遗留应用程序,您肯定需要更多的线程,以通过并发地为多个请求提供服务来改进系统利用率和总体吞吐量。对于这样的应用程序,LONGWAIT 是适当的设置,它在缺省情况下产生 40 个线程。

如何选择正确的工作负载概要并设置恰当的工作线程数量才能实现最佳的吞吐量呢?答案取决于一些考虑事项。

创建足够的工作线程以实现最佳吞吐量。

要确认是否可以通过增加线程数量来实现更好的吞吐量,一种方法是检查负载测试运行的 RMF 报告。如果系统未得到充分利用,并且 QMPL 时间非常高(与执行时间比较而言),则存在通过增加线程数量实现更大吞吐量的潜力。

在 WebSphere Application Server for z/OS 的上下文中,请求在工作队列中等待服务区域进行处理所花的时间量将报告为某种类型的执行延迟,如 RMF Workload Activity 报告中的 QMPL 列所示(图 13)。

图 13. RMF Workload Activity 报告片段
图 13. RMF Workload Activity 报告片段
图 13. RMF Workload Activity 报告片段

如果 QMPL 延迟非常高,则服务区域工作线程不足,无法足够快地处理工作队列中等待的请求。但是如果 CPU 资源由于非常密集的工作负载而满负荷,则添加更多工作线程不会改进总体系统吞吐量。从 RMF 报告中,您可以看到 QMPL 减少,但是 CPU 延迟将增加。

如果已确定增加线程数量将对吞吐量有帮助,下面是您可以采取的一些方法:

  • 通过更改工作负载概要调整每个服务区域的工作线程数量。当服务区域 JVM 的垃圾收集合理和可接受时,此方法是首选的方法。
  • 通过更改最小和最大服务区域数量添加更多服务区域。当单个请求处理的存储需求非常高,从而导致过多的垃圾收集时,此方法非常有用。这也可以通过 WLM 自动维护服务区域数量的功能来实现。

其他要考虑的资源

仅当您知道存在足够的空闲系统资源时才调整线程数量。考虑到所有相关的子系统(例如 DB2、CICS® 等等),很大的总线程数量可能导致那些子系统中出现资源短缺。例如:

  • 带大量工作线程的大量服务区域所需要的连接数量可能超出 DB2 系统所能支持的总连接数量。
  • 一个服务地址空间总共只能有 100 个 EXCI 管道(APAR PQ92943 for CICS Transaction Server V2 使用新的 SYS1.PARMLIB LOGONLIM 参数将 100 个管道限制提高到 250 个管道)。如果您的应用程序通过不同的连接池与多个 CICS 区域通信,并且每个服务区域中存在大量的线程,则对 CICS 资源的要求可能由于 EXCI 管道短缺而随机地失败。

总结

本文说明了 IBM WebSphere Application Server for z/OS V6.x 如何与 IBM Workload Manager 服务合作,从而在不同的领域交付技术价值。本文提供了一些取自实际安装的示例,以说明 J2EE 应用程序如何也能够利用这些功能,并避免由某些使用模式导致的潜在风险。

致谢

我要感谢 Renuka Chekkala 女士对本文的审阅,以及她通过若干客户案例提供的支持和指导。此外,还要感谢 Mike Cox、David Follis、Robert Vaupel 和 Frank Chu 对本文进行了技术审阅并提供了出色的评论和建议。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=355945
ArticleTitle=利用 WebSphere Application Server for z/OS 中面向目标的工作负载管理
publish-date=12082008