IBM WebSphere Portal Web Content Manager 和 DB2 调优指南

正在寻找一个资源中心来调优 WebSphere® Portal Web Content Management 和 IBM® DB2® for Linux®, UNIX®, and Windows® 环境？本文描述该环境独特的、需要特殊考虑的各个部分。您将学习如何调优 Application Server 和 WebSphere Portal。作为良好的开端，您将学习一些应该设置为指定值的各种注册表变量和数据库管理器及数据库配置参数。最后，持续维护小节提供了如何使 DB2 系统随系统增长仍然高效运行的指导原则。

对环境进行性能调优

WebSphere Portal 环境的调优涉及到对该环境的不同的系统和组件的调优和配置。本节讨论一些通用的概念，并详细描述本文评测环境所使用的配置的特征。 WebSphere Portal Web Content Management (WCM) AIX® Power4 评测环境的配置和调优是基于 WebSphere Portal AIX Power4 环境的，IBM WebSphere Portal Version 6.0 Tuning Guide 对后者作了详细阐述。用于评测 WCM 的环境的所有不同之处在本章中都会明确提出。对任何 WebSphere Portal 环境的完整的调优和配置方法包括：

配置应用服务器和为这个应用服务器定义的资源

确定用于扩展环境的复制策略

调优数据库和数据库服务器

调优目录服务器和它的数据库

调优 web 服务器

调优操作系统和网络

调优 WebSphere Portal 服务

在调优各个系统时，首先应该具备一个基准，并监视性能指标，以确定是否应该更改某个参数，当作出更改时，也要监视性能指标，以确定更改的效果。

了解环境

WebSphere Portal V6.0 使用附加的服务器来提供其功能。在我的评测环境中，除了 portal 服务器本身以外，还有一个 Web 服务器，一个数据库服务器和一个目录服务器，这些服务器放在 WebSphere Portal 系统之外的单独的系统上。采用这种配置的主要好处是可以避免同一个系统上的多个服务器之间争用资源。如果其他服务器与 WebSphere Portal 服务器争用资源，就会影响系统可达到的吞吐率。在本报告中，用于评测的配置将 IBM HTTP Server 与 WebSphere Portal 放在同一个系统上。

应用服务器调优

在 WebSphere Application Server 中，应用服务器的配置和调优有很多方面。我发现，本文和 IBM WebSphere Portal Version 6.0 Tuning Guide 中描述的那些方面对于 WebSphere Portal 在我们的实验环境中正确、高效地运行非常关键。

根据我对于本文描述的工作负载的经验，表 1 展示了与用于 Power4 平台的 AIX 的 IBM WebSphere Portal Version 6.0 Tuning Guide 不同的一些配置：

表 1. 应用服务器参数

JVM 最大堆大小限制

在为应用服务器设置堆大小时，要记住：确保系统有足够的物理空间，以便将所有进程装入物理内存，并满足操作系统需要。如果分配的内存大于系统的物理内存，就会发生分页，从而导致糟糕的性能。

我将堆大小的最小值和最大值设置为相同的值，对于在 IBM JDK 上运行的生产系统来说，这可能不是最佳选择。在我的评测中，系统承受负载的时间很短（大约 3 小时），并且运行的 portlet 的内存需求不大。如果使用内存需求较大的 portlet，或者要持续运行，那么通过将初始堆大小设置为 320 MB 可能会减少堆碎片。

对堆大小进行调优之后，要监视系统，以确保没有发生分页。如前所述，换页会导致糟糕的性能。

如何设置参数：

在 WebSphere Administrative Console 中，选择 Servers -> Application Servers -> WebSphere Portal -> Server Infrastructure: Java and Process Management -> Process Definition -> Java Virtual Machine

可以在下面两个地方更改堆大小：

- Initial Heap Size

- Maximum Heap Size

JVM 堆大内存页

该设置可以与 IBM JVM 一起使用，以使用大内存页分配堆空间。为支持大内存页，AIX 操作系统必须进行配置。使用大内存页可以减少跟踪堆所需的 CPU 开销。通过这样的调优，我的评测吞吐率提高了 10%。

如何设置参数：

在 WebSphere Administrative Console 中，选择 Servers -> Application Servers -> WebSphere Portal -> Server Infrastructure: Java and Process Management -> Process Definition -> Java Virtual Machine -> Generic JVM Argument

添加： -Xlp

在 WebSphere Administrative Console 中，选择 Servers -> Application Servers -> WebSphere Portal -> Server Infrastructure: Java and Process Management -> Process Definition -> Custom Properties -> New -> EXTSHM=OFF

（注意：当 EXTSHM 开启时，会阻止大内存页的使用。）

停止 Portal 服务器

配置 AIX，以支持大内存页。我使用以下步骤分配 1856 MB 的 RAM 作为大内存页（16MB）。之所以选择这个大小，是因为这些系统中有 4GB 的物理内存。对于采用不同物理内存大小的系统，这些值应有所调整。

vmo -r -o lgpg_regions=116 -o lgpg_size=16777216

bosboot -a

reboot -q

vmo -p -o v_pinshm=1

chuser capabilities=CAP_BYPASS_RAC_VMM,CAP_PROPAGATE $USER

重新启动 Portal Server。要确认是否正在使用大内存页，运行 AIX 命令 vmstat -l 1 5 并查看 “alp” 列，它是当前使用的活动大内存页。如果正在使用大内存页，那么它应该是一个非 0 值。

kCluster 和 pCluster

JVM 堆上的对象通常是移动的；也就是说，Garbage Collector（GC）在决定重排列堆时，可能会移动这些对象。但是，无论是永久地还是暂时地，有些对象是不能移动的。那些不能移动的对象被称作固化对象（pinned object）。

在版本 1.3.1 Service Refresh 7 及之前版本中，GC 首先在堆的底部分配一个 kCluster 作为第一个对象。kCluster 是一个存储区域，专门用于类块。它大到足以容纳 1280 个条目。每个类块长度为 256 字节。

然后，GC 分配一个 pCluster 作为堆上的第二个对象。pCluster 是用于分配固化对象的存储区域。它的长度为 16 KB。

当 kCluster 耗尽时，GC 将类块分配在 pCluster 中。当 pCluster 也耗尽时，GC 分配一个 2 KB 的新的 pCluster。

由于这个新的 pCluster 可以分配在堆中的任何位置，并且必须是固定的，因此可能导致碎片问题。固化对象使 GC 不能在堆压缩期间合并空闲空间，因而可能导致一个堆有很多容量较小的空闲空间，所以即使某次分配明显少于空闲空间总量，也不能成功分配。为解决这个问题，1.3.1 和更高版本的 SR7 提供了一些命令行选项，用于指定 kCluster（-Xk）、pCluster（-Xp）和 pCluster 的溢出大小（-Xp）。使用这些选项将簇的初始大小设置得足够大，以避免碎片问题。

如何设置参数：

在 WebSphere Administrative Console 中，选择 Servers -> Application Servers -> WebSphere Portal -> Server Infrastructure: Java and Process Management -> Process Definition -> Java Virtual Machine -> Generic JVM Argument

输入 -Xk30000 -Xp24000k,2400k

数据源调优

根据 WebSphere Portal 信息中心的描述，WebSphere Portal V6.0 使用多个数据库。在我的例子中，我使用 7 个独立的数据库，每个数据库都有它自己的数据源。这些数据源是：

表 2. 数据源名称

对于预置语句缓存大小，路径为 Resources -> JDBC Providers -> provider name -> Data Sources -> datasource name -> WebSphere Application Server data source properties。provider name 和 datasource name 随数据库迁移期间为数据库选定的名称而定。查看参数 statement cache size。

我们将所有数据源的预置语句缓存大小设为 1 条语句，以减少对本地内存的需求，从而避免系统崩溃。

DB2 注册表变量

下面的注册表变量应该在实例级设置（使用 db2set 命令）：

表 3. DB2 注册表变量解释

以实例用户身份，输入以下命令，以设置 DB2 注册表变量：

db2set DB2_RR_TO_RS=YES
db2set DB2_EVALUNCOMMITTED=YES
db2set DB2_SKIPDELETED=ON
db2set DB2_INLIST_TO_NLJN=YES
db2set DB2_MINIMIZE_LISTPREFETCH=ON

可选变量

如果 DB2 所在系统是 CPU 密集型，那么还可以设置下面的参数。由于这个变量对于所有包含多于 5 个连接的语句都有影响，因此要小心使用。该参数可以帮助减少优化期间占用的时间和资源。虽然这样可以减少优化所需的时间和资源，但是同时也会增加生成非最佳数据访问计划的风险。

DB2_REDUCED_OPTIMIZATION=5

注意： 只有在 IBM 明确建议的情况下，才应该设置该参数。

数据库管理器配置参数

表 4 展示了数据库管理器配置参数：

表 4. 数据库管理器配置参数

以实例用户的身份，输入以下命令，更新数据库管理器配置：

db2 "update dbm cfg using query_heap_sz 32768"
db2 "update dbm cfg using maxagents 1000"
db2 "update dbm cfg using sheapthres 50000"
db2 "update dbm cfg using health_mon off"
db2 "update dbm cfg using aslheapsz 60"
db2 "update dbm cfg using rqrioblk 65535"
db2 "update dbm cfg using federated no"

注意： 如果需要联邦数据库支持，不能将 FEDERATED 设为 NO。

数据库配置参数

用于所有数据库的参数

表 5 展示了应该为所有数据库设置的数据库配置参数：

表 5. 用于所有数据库的数据库配置参数

以实例用户的身份，输入以下命令，为所有数据库更新数据库配置。注意将 DBNAME 改为实际的数据库名称：

db2 "update db cfg for DBNAME using applheapsz 4096"
db2 "update db cfg for DBNAME using app_ctl_heap_sz 1024"
db2 "update db cfg for DBNAME using stmtheap 8192"
db2 "update db cfg for DBNAME using dbheap 2400"
db2 "update db cfg for DBNAME using locklist 1000"
db2 "update db cfg for DBNAME using logfilsiz 1000"
db2 "update db cfg for DBNAME using logprimary 12"
db2 "update db cfg for DBNAME using logsecond 20"
db2 "update db cfg for DBNAME using logbufsz 128"
db2 "update db cfg for DBNAME using avg_appls 5"
db2 "update db cfg for DBNAME using locktimeout 30"
db2 "update db cfg for DBNAME using maxlocks 70"
db2 "update db cfg for DBNAME using maxappls automatic"

用于 JCR 数据库的参数

表 6 展示了应该为 JCR 数据库设置的数据库参数：

表 6. 用于 JCR 数据库的数据库参数

以实例用户的身份，输入以下命令，更新特定于 JCRDB 的数据库配置。将 JCRDB 改为实际的数据库名称：

db2 "update db cfg for JCRDB using dbheap 4800"
db2 "update db cfg for JCRDB using sortheap 4096"
db2 "update db cfg for JCRDB using applheapsz 16384"
db2 "update db cfg for JCRDB using app_ctl_heap_sz 20000"
db2 "update db cfg for JCRDB using stmtheap 16384"
db2 "update db cfg for JCRDB using num_iocleaners 11"
db2 "update db cfg for JCRDB using num_ioservers 11"

数据库调优

数据库性能对于从 WCM 获得良好性能十分重要。本文和 IBM WebSphere Portal Version 6.0 Tuning Guide 中提到的维护任务和实践对于 WebSphere Portal 在我们的实验环境中正确、高效地运行非常关键。在您的生产环境中，可能还需要进行一些其他的数据库维护和调优。

校正序列

在创建数据库时，DB2 允许对序列进行校正（collate）。这将对性能产生影响。虽然在本报告描述的场景中，使用 UCA400_NO collation 实际上对吞吐率没有影响，但是它会产生高得多的数据库 CPU 开销。然而，在单独的调查评测中，UCA400_NO 校正（collation）的使用对于某些 WCM 事务创建有明显的影响。根据经验，需要对特定于地区的特殊数据排序需求和可能导致的更高的数据库 CPU 开销之间进行权衡。当我创建数据库时，没有指定任何 COLLATE 选项。

将 JCR 表变为稳定状态

JCR 模式的 DB2 配置将大多数表标记为 VOLATILE CARDINALITY。在初始填充期间，这是正确的，因为很多表从 0 行或少数几行增长到多行。这个属性告诉 DB2 优化器不要信任表统计信息，因为这些统计信息表明表非常小，如果信任这些统计信息，优化器会像往常一样利用针对小表的索引对表进行扫描。而一旦数据库达到稳定状态，则希望优化器根据编目统计信息选择最佳访问计划（要获得关于如何维护这些统计信息的建议，请参阅后面的小节）。为此，运行以下命令：

db2 -x -r "nonVolatile.db2" "select rtrim(concat('alter table ', concat(rtrim(tabSchema),
concat('.', concat(rtrim(tabname), ' not volatile'))))) from syscat.tables where type='T'
and volatile='C' and tabSchema='JCR'"
db2 -v -f "nonVolatile.db2"

持续的数据库维护

Runstats 和 reorg

DB2 赖以高效运行的两个数据库属性是数据库编目统计信息和数据在表中的物理组织。在数据库的生命周期中，特别是经过重大的数据修改（插入、更新和删除），例如填充阶段之后，应该定期地重新计算编目统计信息。由于计算这些统计信息时需要占用很多的资源，因此最好在非繁忙时段、低需求阶段或者 portal 离线时执行这种维护。DB2 runstats 命令用于计算和记录关于表、索引和列的统计信息。在我们的环境中，我使用了两种方法来计算这些统计信息。 我推荐的形式是：

+
db2 "runstats on table tableschema.tablename on all columns with distribution
on all columns and sampled detailed indexes all allow write access"

这些选项使优化器可以为复杂的 SQL 确定最佳访问计划。对于计算编目统计信息，一种更简单、更方便的方法是：

db2 reorgchk update statistics on table all

该命令不仅计算并记录一些相同的编目统计信息，它还产生一个报告，通过查看该报告可以发现表组织方面的问题。但是，我发现该命令所产生的信息不够充分，不足以让优化器为复杂的 SQL（特别是对于 JCR 数据库的查询）选择高效的访问计划。如果您想使用一种与 reorgchk 命令一样方便，同时又能提供优化器所需的详细统计信息的方法，那么可以使用下面的命令：

db2 -x -r "runstats.db2" "select rtrim(concat('runstats on table',
concat(rtrim(tabSchema), concat('.',concat(rtrim(tabname),
' on all columns with distribution on all columns and sampled detailed
indexes all allow write access'))))) from syscat.tables where type='T'"
db2 -v -f "runstats.db2"

在生产环境中，重组所有的表是无法接受的。为了确定哪些表可以通过重组获益，可以使用下面的命令：

db2 reorgchk current statistics on table all > "reorgchk.txt"

表名旁的三个列当中至少有一个列中标记有 * 符号的表，这就是需要重组的表。对于需要重组的表，使用以下命令：

db2 reorg table tableschema.tablename

监视

快照监视用于识别数据库在一段时间内的行为。它被进一步用于对系统进行细微调节，以及发现与性能相关的问题。

要启用快照监视，首先需要激活不同的监视器。有两种方式可以激活监视器。一种方式是配置数据库管理器，在实例级别激活监视，另一种方式是在特定的时候为当前会话启用监视。

要在实例级别启用默认的监视，使用以下命令：

db2 update dbm cfg using DFT_MON on

其中 DFT_MON 在以下值当中取值：

DFT_MON_BUFPOOL DFT_MON_LOCK DFT_MON_SORT DFT_MON_STMT DFT_MON_TABLE DFT_MON_TIMESTAMP DFT_MON_UOW

要为当前会话启用监视，使用命令：

db2 update monitor switches using MON_SWITCH on

其中 MON_SWITCH 在以下值当中取值：

表 7. 监视器开关

注意：由于活动的监视器会增加对 CPU 的使用，所以应当只在必要时才激活所有的监视器。

要获得当前被激活的监视器开关，可以使用以下命令：

db2 get monitor switches

要获得数据库的快照，可以运行以下命令：

db2 get snapshot for all on DBNAME >snap.out

监视 DB2 系统的另一种方法是 db2top。

缓冲池分析

缓冲池是在从磁盘读取或修改表和索引数据页时，用于缓存它们的内存。由于缓冲池允许从内存而不是磁盘访问数据，因此可以提高数据库系统的性能。由于内存访问比磁盘访问快很多，因此数据库管理器读写磁盘的次数越少，性能就越好。

由于 DB2 v8 中没有 SYSIBMADM.BP_HITRATIO 表，我编写了两个存储过程，用于计算缓冲池的命中率：bphr 显示实际数据库的缓冲池命中率，而 bphr_all 显示实例中所有活动数据库的缓冲池命中率。

可以使用以下命令来调用这两个存储过程：

db2 call bphr
db2 call bphr_all

连接到一个数据库之后，可以使用以下命令安装这两个存储过程：

db2 -td@ -f bphr.db2

清单 1. 计算缓冲池命中率的存储过程的代码

CREATE PROCEDURE bphr ()
SPECIFIC tessus_bphr LANGUAGE SQL DYNAMIC RESULT SETS 1
BEGIN
　DECLARE res CURSOR WITH RETURN FOR
WITH bp_snap (snapshot_timestamp, database, bufferpool, bp_hr, data_hr,
　　　　　　　idx_hr, page_clean_ratio )
AS
(
　SELECT snapshot_timestamp, SUBSTR(db_name,1,16), SUBSTR(bp_name,1,32),
　CASE
　　WHEN ((pool_data_p_reads > 0 OR pool_index_p_reads > 0) AND
　　　　　(pool_data_l_reads > 0 OR pool_index_l_reads > 0))
　　　THEN
　　　　DECIMAL( ((1-(double(pool_data_p_reads + pool_index_p_reads)/
　　　　DOUBLE(pool_data_l_reads + pool_index_l_reads+1)) )*100.0),3,1 )
　　　ELSE
　　　　NULL
　　　END CASE,
　　　CAST( (CAST( pool_data_l_reads - pool_data_p_reads
　　　　AS DOUBLE)*100.0)/(pool_data_l_reads+1) AS DECIMAL(3,1)),
　　　CAST( (CAST( pool_index_l_reads - pool_index_p_reads
　　　　AS DOUBLE)*100.0)/(pool_index_l_reads+1) AS DECIMAL(3,1)),
　　　CAST( (CAST( pool_async_data_writes + pool_async_index_writes
　　　　AS DOUBLE)*100.0)/(pool_data_writes+pool_index_writes+1)
　　　　AS DECIMAL(3,1))
　FROM TABLE(snapshot_bp('',-1)) AS BP
　ORDER BY 2,3
)
SELECT snapshot_timestamp, database, bufferpool, bp_hr, data_hr, idx_hr
FROM bp_snap;
　OPEN res;
END@
CREATE PROCEDURE bphr_all ()
SPECIFIC tessus_bphr_all LANGUAGE SQL DYNAMIC RESULT SETS 1
BEGIN
　DECLARE res CURSOR WITH RETURN FOR
WITH bp_snap (snapshot_timestamp, database, bufferpool, bp_hr, data_hr,
　　　　　　　idx_hr, page_clean_ratio )
AS
(
　SELECT snapshot_timestamp, SUBSTR(db_name,1,16), SUBSTR(bp_name,1,32),
　CASE
　　WHEN ((pool_data_p_reads > 0 OR pool_index_p_reads > 0) AND
　　　　　(pool_data_l_reads > 0 OR pool_index_l_reads > 0))
　　　THEN
　　　　DECIMAL( ((1-(double(pool_data_p_reads + pool_index_p_reads)/
　　　　DOUBLE(pool_data_l_reads + pool_index_l_reads+1)) )*100.0),3,1 )
　　　ELSE
　　　　NULL
　　　END CASE,
　　　CAST( (CAST( pool_data_l_reads - pool_data_p_reads
　　　　AS DOUBLE)*100.0)/(pool_data_l_reads+1) AS DECIMAL(3,1)),
　　　CAST( (CAST( pool_index_l_reads - pool_index_p_reads
　　　　AS DOUBLE)*100.0)/(pool_index_l_reads+1) AS DECIMAL(3,1)),
　　　CAST( (CAST( pool_async_data_writes + pool_async_index_writes
　　　　AS DOUBLE)*100.0)/(pool_data_writes+pool_index_writes+1)
　　　　AS DECIMAL(3,1))
　FROM TABLE(snapshot_bp(CAST(NULL AS VARCHAR(128)),-1)) AS BP
　ORDER BY 2,3
)
SELECT snapshot_timestamp, database, bufferpool, bp_hr, data_hr, idx_hr
FROM bp_snap;
　OPEN res;
END@

在 DB2 9 中，可以使用这两个存储过程，也可以使用以下 SQL 语句来获得缓冲池命中率：

db2 "select snapshot_timestamp, substr(db_name,1,10) as dbname,
substr(bp_name,1,18) as bufferpool, total_hit_ratio_percent as total,
data_hit_ratio_percent as data, index_hit_ratio_percent as index
from sysibmadm.bp_hitratio"

理想的缓冲池命中率是高于 96%。首先可以尝试增加缓冲池大小，看能否提高命中率。如果命中率仍然较低，那么可能需要重新设计表空间和缓冲池的逻辑布局。

可以使用以下命令在线更改缓冲池的大小：

db2 alter bufferpool BPNAME immediate size NUMBER_OF_PAGES

目录服务器调优

我的评测使用 IBM Tivoli Directory Server (ITDS) version 5.2 作为目录服务器。该目录服务器配置方面的细节与 IBM WebSphere Portal Version 6.0 Tuning Guide 中指定的 AIX ITDS V5.2 目录服务器的配置相同。

WebSphere Portal Service 属性

WebSphere Portal 有很多可配置的服务；每个服务都有一些可用的参数。本节描述我对哪些服务进行了不同于 IBM WebSphere Portal Version 6.0 Tuning Guide 的调优。

惟一进行了不同调优的服务是 Cache Manager Service。对于这个服务，除了下面表中列出的更改外，我接受了 WebSphere Portal 的默认设置：

表 8. Cache Manager Service 参数

结束语

本教程展示了调优 WebSphere Portal WCM 和 DB2 环境涉及的步骤。您应该看到了这个环境的独特之处，对它进行调优时需要作一些特殊的考虑。本文展示了那些应该设置为指定值的各种注册表变量和一些数据库管理器及数据库配置参数的重要性。最后，您看到了如何维护 DB2 系统，使之随系统增长仍然可以高效运行。