wp6 WCM db2-TuningGuide

IBM
WebSphere Portal Version 6.0

Web Content Management
and
DB2
Tuning Guide
IBM WPLC Performance Team and IBM Toronto Lab
December 18, 2007
RCSfile: wp6wcmdb2-TuningGuide.tex,v Date: 2007/12/18 17:23:34 Revision: 1.3

Contents
Preface ii
1 Performance Tuning the Environment 1
2 Understanding the Environment 1
3 Application Server Tuning 2

3.1 JVM Max Heap Size Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3.2 JVM Large Page Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.3 kCluster and pCluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4 Datasource Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.5 Application Server Cloning . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 DB2 registry variables 5

4.1 Optional variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5 Database Manager configuration parameters 7
6 Database configuration parameters 8

6.1 Parameters for all databases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2 Parameters for the JCR database . . . . . . . . . . . . . . . . . . . . . . . 9
7 Database Tuning 10
7.1 Collating Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2 changing JCR tables to be not volatile . . . . . . . . . . . . . . . . . . . . 10
8 Ongoing database maintainence 11

8.1 runstats and reorg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2 Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2.1 Buffer pool analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9 Directory Server Tuning 14
10 WebSphere Portal Service Properties 15
A Stored Procedures - Buffer Pool Hit Ratio 16

A.1 bphr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
A.2 bphr all . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
B References 18
C Credits 19
i
Preface
This document was written with intent to be a central source for tuning a Websphere
Portal Web Content Management and DB2 environment.
It describes the different parts of the environment that are special to that environment.
It was written by the IBM WPLC Performance Team and IBM Toronto Lab.
The document describes how to tune the Application Server and the WebSphere Portal.
Furthermore it points out various registry variables and several database manager and
database configuration parameters that should be set to the specified values as a good
start.
The ongoing maintenance section is a guideline how to keep the DB2 system perfor-
mant during the growth of the system.
ii
IBM WebSphere Portal Web Content Manager and DB2 Tuning Guide
1 Performance Tuning the Environment

Tuning a WebSphere Portal environment involves tuning and configuring the various sys-
tems and components of the environment. This chapter discusses some general concepts
and details the specifics of the configuration used in our measurement environment. The
tuning and configuration for the WebSphere Portal Web Content Management (WCM)
AIX Power4 measurement environment was based upon the WebSphere Portal AIX
Power4 environment detailed in the IBM WebSphere Portal Version 6.0 Tuning Guide.
All differences in the environment used to measure WCM are explicitly mentioned in
this chapter. The overall tuning and configuration approach to any WebSphere Portal
environment includes:
• Configuring the application server and the resources defined for that application
server
• Determining the cloning strategy for expanding or extending the environment
• Tuning the database(s) and database server
• Tuning the directory server and its database
• Tuning the web server
• Tuning the operating system and network
• Tuning the WebSphere Portal services
When tuning your individual systems, it is important to begin with a baseline, monitor
the performance metrics to determine if any parameters should be changed and, when a
change is made, monitor the performance metrics to determine the effectiveness of the
change.
2 Understanding the Environment

WebSphere Portal V6.0 uses additional servers to provide its functionality. In our mea-
surement environment, there is a web server, database server and directory server in
addition to the portal server itself. For maximum performance, these servers should
reside on separate systems from the WebSphere Portal system. The primary benefit of
having such a configuration is to avoid resource contention from multiple servers residing
on a single system. Additional servers contending with the WebSphere Portal server for
system resources impacts the system’s achievable throughput. The configuration used
for the measurements in this report had the IBM HTTP Server on the same system as
WebSphere Portal.
See Appendix B: WCM Benchmark Environment for the details of our lab configuration.
Date: 2007/12/18 17:23:34 1 / 20 Revision: 1.3

3 Application Server Tuning

There are many aspects to configuring and tuning an application server in WebSphere
Application Server. We found that those presented here, and in the IBM WebSphere
Portal Version 6.0 Tuning Guide were critical to a correctly functioning and optimally
performing WebSphere Portal in our laboratory environment. For more details on tun-
ing a WebSphere Application Server, see the Tuning Section of the information center
located at:
http://www.ibm.com/software/webservers/appserv/was/library/
The following are settings, based on our experience with the workloads described in
this document, which differed from those in the IBM WebSphere Portal Version 6.0
Tuning Guide for AIX on the Power4 platform:
Parameter Setting Additional Details

Java Virtual 1792 Remember that the value of the JVM
Machine heap Heap size is directly related to the
size amount of physical memory on the
system. Never set the JVM heap size
larger than the physical memory on the
system
see section 3.1

JVM Heap -Xlp Used with the IBM JVM to allocate
Large page the heap using large pages.
see section 3.2

kCluster and -Xk30000 Pinned clusters. Pre-allocates JVM
pCluster -Xp24000k,2400k heap for class files, since they are oth-
erwise pinned in memory once loaded.
see section 3.3
3.1 JVM Max Heap Size Limits

When setting the heap size for an application server, keep the following in mind: Make
sure that the system has enough physical memory for all of the processes to fit into phys-
ical memory, plus enough for the operating system. When more memory is allocated
than the physical memory in the system, paging will occur, and this can result in very
poor performance.
While we set the minimum and maximum heap sizes to the same values, this may
not be the best choice for production systems which are running on IBM JDKs. In our
Date: 2007/12/18 17:23:34 2 / 20 Revision: 1.3

measurement runs, the system is under load for a relatively short time (around 3 hours),
and it is running with portlets which do not have large memory requirements. When
using portlets which will have larger memory requirements, or for continuous operation,
it may be possible to reduce heap fragmentation by setting the initial heap size to 320
megabytes.
After doing any tuning of heap sizes, monitor the system to make sure that paging
is not occurring. As mentioned above, paging can cause poor performance.
How-To Set Parameter:
In the 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
3.2 JVM Large Page Tuning

This setting can be used with the IBM JVM to allocate the heap using large pages.
AIX operating system must be configured to support large pages. Using large pages can
reduce the CPU overhead needed to keep track of heap. With this tuning, we have seen
10% throughput improvement in our measurements.
1. In the WebSphere Administrative Console: Servers → Application Servers → Web-

Sphere Portal → Server Infrastructure: Java and Process Management → Process
Definition → Java Virtual Machine → Generic JVM Argument, Add: -Xlp
2. In the WebSphere Administrative Console: Servers → Application Servers → Web-
Sphere Portal → Server Infrastructure: Java and Process Management → Process
Definition → Custom Properties → New → EXTSHM=OFF
(note: When EXTSHM is on it prevents use of large page).
3. Stop Portal server
4. Configure AIX to support large pages. We use the following steps to allocate 1856
MB of RAM as large pages (16MB). We chose this amount based on having 4GB
of physical memory in these systems. These values may need to be adjusted on
systems with different amounts of physical memory.
vmo -r -o lgpg regions=116 -o lgpg size=16777216
bosboot -a
reboot -q
Date: 2007/12/18 17:23:34 3 / 20 Revision: 1.3

vmo -p -o v pinshm=1
chuser capabilities=CAP BYPASS RAC VMM,CAP PROPAGATE $USER
5. Restart Portal Server. To verify if large pages are being used, run the AIX com-
mand vmstat -l 1 5 and check the ”alp” column which is the active large page
used. It should be a non-zero value if large pages are being used.
3.3 kCluster and pCluster

Objects that are on the JVM heap are usually mobile; that is, the Garbage Collector
can move them around if it decides to re-sequence the heap. Some objects, however,
cannot be moved either permanently or temporarily. Such immovable objects are known
as pinned objects.
In release 1.3.1 Service Refresh 7 and above, the Garbage Collector allocates a kCluster
as the first object at the bottom of the heap. A kCluster is an area of storage that is
used exclusively for class blocks. It is large enough to hold 1280 entries. Each class block
is 256 bytes long.
The Garbage Collector then allocates a pCluster as the second object on the heap.
A pCluster is an area of storage that is used to allocate any pinned objects. It is 16 KB
long.
When the kCluster is full, the Garbage Collector allocates class blocks in the pClus-
ter. When the pCluster is full, the Garbage Collector allocates a new pCluster of 2 KB
Because this new pCluster can be allocated anywhere in the heap and must be pinned,
it can cause fragmentation problems. The pinned objects effectively deny the GC the
ability to combine free space during heap compaction and could result in a heap that
contains a lot of free space but in relatively small discrete amounts, so that an allocation
that appears to be well below the total free heap space will fail. To solve this problem,
release 1.3.1 at SR7, and later, provides command-line options to specify the kCluster
(-Xk), pCluster (-Xp) and pCluster overflowsize (-Xp). Use these options to set the ini-
tial sizes of the ’clusters’ to be large enough to avoid fragmentation issues.
In the 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
3.4 Datasource Tuning

As is described in the WebSphere Portal information center, multiple databases are used
with WebSphere Portal V6.0. We used seven separate databases, each with their own
Date: 2007/12/18 17:23:34 4 / 20 Revision: 1.3

datasources. These are:
Database Database name Datasource name

Release release reldbDS
Community community commdbDS
Customization custom cusdbDS
Feedback fdbkdb fdbkdbDS
Likeminds lmdb lmdbDS
JCR jcrdb jcrdbDS
Member Manager wmmdb wmmdbDS
For the prepared statement cache size, the path is Resources → JDBC Providers →
provider name → Data Sources → datasource name → WebSphere Application Server
data source properties. The provider name and datasource name are based on the names
selected for that database during the database transfer step. Look for the parameter
Statement cache size.
We set the prepared statement cache size to 1 statement for all Datasources to reduce
the demands on native memory, thus avoiding crashes.
3.5 Application Server Cloning

We did not measure any cloned environment for this report.
4 DB2 registry variables

The following registry variables should be set (by using the db2set command) at the
instance level:
DB2_RR_TO_RS=YES
DB2_EVALUNCOMMITTED=YES
DB2_SKIPDELETED=ON
DB2_INLIST_TO_NLJN=YES
DB2_MINIMIZE_LISTPREFETCH=ON
DB2 RR TO RS This parameter is deprecated since DB2 v8.2. If you don’t get an
error when trying to set the parameter in DB2 higher than version 8.2, it is ok to have
it set. If you get an error, never mind. The next two variables are the replacement for
it.
When DB2 RR TO RS is on, RR behavior cannot be guaranteed for scans on user tables
because next key locking is not done during index key insertion and deletion. Cata-
log tables are not affected by this option. The other change in behavior is that with
DB2 RR TO RS on, scans will skip over rows that have been deleted but not committed,
even though the row may have qualified for the scan.
Date: 2007/12/18 17:23:34 5 / 20 Revision: 1.3

DB2 EVALUNCOMMITTED When enabled, this variable allows, where possible, ta-
ble or index access scans to defer or avoid row locking until a data record is known to
satisfy predicate evaluation. DB2 EVALUNCOMMITTED is applicable only to statements us-
ing either Cursor Stability or Read Stability isolation levels. For index scans, the index
must be a type-2 index. Furthermore, deleted rows are skipped unconditionally on table
scan access while deleted keys are not skipped for type-2 index scans unless the registry
variable DB2 SKIPDELETED is also set.
DB2 SKIPDELETED When enabled, this variable allows statements using either Cur-
sor Stability or Read Stability isolation levels to unconditionally skip deleted keys during
index access and deleted rows during table access. With DB2 EVALUNCOMMITTED enabled,
deleted rows are automatically skipped, but uncommitted pseudo-deleted keys in type-2
indexes are not skipped unless DB2 SKIPDELETED is also enabled.
DB2 INLIST TO NLJN Sometimes the optimizer does not have accurate information
to determine the best join method for the rewritten version of the query. This can occur
if the IN list contains parameter markers or host variables which prevent the optimizer
from using catalog statistics to determine the selectivity. This registry variable causes
the optimizer to favor nested loop joins to join the list of values, using the table that
contributes the IN list as the inner table in the join.
DB2 MINIMIZE LISTPREFETCH Necessary to avoid an inefficient access plan for a

common query on one of the tables in the JCR database.
4.1 Optional variables

If the system, where DB2 is running, is CPU bound, then the following parameter can
be set as well. Since this variable affects all statements that have more than 5 joins
involved, it should be used with caution. This parameter can help to reduce time and
resource usage during optimization. Although optimization time and resource use might
be reduced, the risk of producing a less than optimal data access plan is increased.
DB2_REDUCED_OPTIMIZATION=5
Attention: This parameter should only be set when explicitly advised by IBM.
Date: 2007/12/18 17:23:34 6 / 20 Revision: 1.3

5 Database Manager configuration parameters

parameter value
QUERY HEAP SZ 32768

MAXAGENTS 1000
SHEAPTHRES 50000
HEALTH MON OFF
ASLHEAPSZ 60
RQRIOBLK 65535
FEDERATED NO
As the instance user enter the following commands:
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"
Note: If you need federated database support, you must not set FEDERATED to NO.
Date: 2007/12/18 17:23:34 7 / 20 Revision: 1.3

6 Database configuration parameters

6.1 Parameters for all databases
parameter value
APPLHEAPSZ 4096
APP CTL HEAP SZ 1024
STMTHEAP 8192
DBHEAP 2400
LOCKLIST 1000
LOGFILSIZ 1000
LOGPRIMARY 12
LOGSECOND 20
LOGBUFSZ 128
AVG APPLS 5
LOCKTIMEOUT 30
MAXLOCKS 70
MAXAPPLS AUTOMATIC
As the instance user enter the following commands, but change DBNAME to the actual
database name:
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"
Date: 2007/12/18 17:23:34 8 / 20 Revision: 1.3

6.2 Parameters for the JCR database

parameter value
DBHEAP 4800
SORTHEAP 4096
APPLHEAPSZ 16384
APP CTL HEAP SZ 20000
STMTHEAP 16384
NUM IOCLEANERS 11
NUM IOSERVERS 11
As the instance user enter the following commands, but change JCRDB to the name of
the JCR database:
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"
Date: 2007/12/18 17:23:34 9 / 20 Revision: 1.3

7 Database Tuning
Database performance is very important for obtaining good performance from WCM.
The maintenance tasks and practices mentioned here and in the IBM WebSphere Portal
Version 6.0 Tuning Guide were found to be critical to the performance and correct op-
eration of WebSphere Portal in our lab environment. Additional database maintenance
and tuning may be needed in your production environments. For further information on
DB2 administration, tuning, and monitoring refer to the DB2 Information Center.
7.1 Collating Sequence

DB2 offers a choice of collating sequences when creating databases. We have found that
this choice can have a performance impact. While the use of UCA400 NO collation
had virtually no effect on the throughput for the scenario described in this report, it
yielded much higher database CPU costs. But in a separate investigative measurement
the use of the UCA400 NO collation had an obvious impact on some WCM authoring
transactions. As a rule of thumb, the need for special locale specific data ordering should
be weighed against some possible higher database CPU cost. We did not specify any
COLLATE option when we created our databases.
7.2 changing JCR tables to be not volatile

The DB2 configuration of the JCR schema marks most of the tables as having VOLATILE
CARDINALITY. This is true during the initial population since many tables grow from
zero or a few rows to many rows. This attribute is an indication to the DB2 optimizer to
not trust the table statistics indicating that the table is very small since the optimizer
would normally choose scanning the table over utilizing an index for a small table. Once
the database has reached a steady state we want the optimizer to choose the best access
plan according to the catalog statistics (see the following section for recommendations
on how to maintain these statistics). In order to accomplish this we ran the following
commands:
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"
Date: 2007/12/18 17:23:34 10 / 20 Revision: 1.3

8 Ongoing database maintainence

8.1 runstats and reorg
Two of the database attributes, which DB2 relies upon to perform optimally, are the
database catalog statistics and the physical organization of the data in the tables. Cat-
alog statistics should be recomputed periodically during the life of the database, par-
ticularly after periods of heavy data modifications (inserts, updates, and deletes) such
as a population phase. Due to the heavy contention of computing these statistics, we
recommend performing this maintenance during off hours, periods of low demand, or
when the portal is off-line. The DB2 runstats command is used to count and record
the statistical details about tables, indexes and columns. We have used two techniques
in our environment to compute these statistics. The form we recommend is:
db2 runstats on table tableschema.tablename on all columns with distribution

on all columns and sampled detailed indexes all allow write access
These options allow the optimizer to determine optimal access plans for complex SQL.
A simpler, more convenient technique for computing catalog statistics is:
db2 reorgchk update statistics on table all
Not only does this command count and record some of the same catalog statistics,
it also produces a report that can be reviewed to identify table organization issues.
However, we have found instances where this produces insufficient information for the
optimizer to select an efficient access plan for complex SQL, particularly for queries of
the JCR database. We have determined a technique that has the same convenience of
the reorgchk command and provides the detailed statistics preferred by the optimizer.
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"
Reorganizing all the tables would be over-kill in a production environment. To determine
which tables might benefit from reorganization, use the command:
db2 reorgchk current statistics on table all > "reorgchk.txt"
The tables that need reorganization are indicated by a ∗ in at least one of the three
columns next to the table name. For those tables that require reorganization, use the
command:
db2 reorg table tableschema.tablename
to reorganize the table based upon its primary key.
Date: 2007/12/18 17:23:34 11 / 20 Revision: 1.3

8.2 Monitoring
Snapshot monitoring is used to identify the behavior of a database over a period of time.
It is further used for fine-tuning the system and finding problems regarding performance.
For snapshot monitoring to work, you need to active the different monitors first. There
are two ways to do this. You can either configure the database manager to activate
monitoring at instance level, or you can turn on monitoring at a specific time for the
current session.
To turn on default monitoring at instance activation or instance level use the follow-
ing command:
db2 update dbm cfg using DFT_MON on
where DFT MON is one of the following values:
DFT_MON_BUFPOOL DFT_MON_LOCK DFT_MON_SORT DFT_MON_STMT

DFT_MON_TABLE DFT_MON_TIMESTAMP DFT_MON_UOW
To turn on monitoring for the current session use the command:
db2 update monitor switches using MON_SWITCH on
where MON SWITCH is one of the following values:
monitor value
Buffer Pool Activity Information BUFFERPOOL

Lock Information LOCK
Sorting Information SORT
SQL Statement Information STATEMENT
Table Activity Information TABLE
Take Timestamp Information TIMESTAMP
Unit of Work Information UOW
Note: Since activated monitors increase the utilisation of the CPU, you should activate
all monitors only when needed.
To get the currently activated monitor switches use the following command:
db2 get monitor switches
Date: 2007/12/18 17:23:34 12 / 20 Revision: 1.3

To get a snapshot for a database, run the following command:
db2 get snapshot for all on DBNAME >snap.out
Another way to monitor a DB2 system is db2top. You can get this utility at:
http://www.alphaworks.ibm.com/tech/db2top
8.2.1 Buffer pool analysis

A buffer pool is memory used to cache table and index data pages as they are being read
from disk, or being modified. The buffer pool improves database system performance by
allowing data to be accessed from memory instead of from disk. Because memory access
is much faster than disk access, the less often the database manager needs to read from
or write to a disk, the better the performance.
Since there is no SYSIBMADM.BP HITRATIO table in DB2 v8, I’ve written two stored
procedures1 , for calculating the buffer pool hit ratio:
stored procedure description
bphr shows the bufferpool hit ratio of the actual

database
bphr all shows the bufferpool hit ratio of all active
databases within the instance
The stored procedure is invoked with the following command:
db2 call SPNAME
where SPNAME is the name of the stored procedure.
You can download the latest version of the stored procedures at:
http://www.evermeet.cx/cvs/db2scripts/
They are installed (after connecting to a database) with the following command:
db2 -td@ -f bphr.db2
1
see Appendix A
Date: 2007/12/18 17:23:34 13 / 20 Revision: 1.3

In DB2 9, you can either use the two stored procedures, or the following SQL statement
to get the buffer pool hit ratio:
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"
An ideal buffer pool hit ratio is above 96%. It would be well worthwhile to increase the
size of the buffer pool and see if the hit ratio increases. If the hit ratio remains low, you
may need to redesign your logical layout of your table spaces and buffer pools.
The size of the buffer pool can be changed online by the following command:
db2 alter bufferpool BPNAME immediate size NUMBER_OF_PAGES
9 Directory Server Tuning

Our measurements used IBM Tivoli Directory Server (ITDS) version 5.2 as the directory
server. The configuration details are the same of the AIX ITDS V5.2 directory server
configuration specified in the IBM WebSphere Portal Version 6.0 Tuning Guide.
Date: 2007/12/18 17:23:34 14 / 20 Revision: 1.3

10 WebSphere Portal Service Properties

WebSphere Portal has a number of configurable ”services”; each service has several pa-
rameters available to it. This section describes which services we tuned different from
that described in the IBM WebSphere Portal Version 6.0 Tuning Guide.
The only service we tuned differently was the Cache Manager Service. For this ser-
vice we accepted the defaults shipped with WebSphere Portal except for the changes
listed in the following table:
Cache Name AIX POWER4 WCM

Rendering Scenario
com.ibm.wps.ac.ExplicitEntitlementsCache. 2000
ICM CONTENT.size
com.ibm.wps.datastore.services.Identification. 5000
SerializedOidStringCache.size
com.ibm.wps.model.content.impl.ResourceCache. 14400
lifetime
Date: 2007/12/18 17:23:34 15 / 20 Revision: 1.3

A Stored Procedures - Buffer Pool Hit Ratio

A.1 bphr
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@
Date: 2007/12/18 17:23:34 16 / 20 Revision: 1.3

A.2 bphr all

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@
Date: 2007/12/18 17:23:34 17 / 20 Revision: 1.3

B References
WebSphere Portal Information Center:
http://www.ibm.com/developerworks/websphere/zones/portal/proddoc.html
WebSphere Application Server Information Center:

http://www.ibm.com/software/webservers/appserv/was/library/
DB2 Information Center:

http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp
http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp
http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp
IBM WebSphere Portal Version 6.0 Tuning Guide:

http://www-1.ibm.com/support/docview.wss?rs=688&uid=swg27008511
IBM WebSphere Portal Version 6.0 Benchmark Results and Tuning Guide is available
by request from the WPLC Performance Team.
IBM WebSphere Portal Version 6.0 Document Manager Benchmark Results and Tuning
Guide is available by request from the WPLC Performance Team.
For additional performance-related information, consult the following resources:
WebSphere Application Server Performance information:

http://www.ibm.com/software/webservers/appserv/was/performance.html
Recommended reading list: J2EE and WebSphere Application Server

http://www.ibm.com/developerworks/websphere/library/techarticles/0305_issw/
recommendedreading.html
WebSphere Application Server Development Best Practices for Performance and Scala-
bility:
http://www.ibm.com/software/webservers/appserv/ws_bestpractices.pdf
Diagnosing Performance Problems for WebSphere Portal 5.1 (though this document
was written for WebSphere Portal 5.1, the lessons apply to WebSphere Portal 6.0 as
well):
http://www.ibm.com/support/docview.wss?uid=swg27007059
IBM Developer Kit and Runtime Environment, Java(TM) 2 Technology Edition, Version
1.4.2 Diagnostics Guide
http://www-128.ibm.com/developerworks/java/jdk/diagnosis/142.html
Date: 2007/12/18 17:23:34 18 / 20 Revision: 1.3

C Credits
Thanks to the following team members of the WPLC Performance Team for contributing
to this document.
Mark Alkins, manager
Nathan Cook, report author
Rich Hall, report author
Andrew Citron
Susan Hanis
Ruthie Lyle
Denny Pichardo
Martin Presler-Marshall
Evan Thompson
Terence Walker
Laura Yen
Thanks to the following people from the IBM Toronto Lab.
Helmut K. C. Tessarek, DB2 Performance, report author
Date: 2007/12/18 17:23:34 19 / 20 Revision: 1.3


c Copyright IBM Corporation 2006-2007
IBM United States of America
Produced in the United States of America
All Rights Reserved
The e-business logo, the eServer logo, IBM, the IBM logo, IBM Directory Server, DB2, Lotus, WebSphere,
POWER4 and POWER5 are trademarks of International Business Machines Corporation in the United States,
other countries or both.
Lotus and Domino are trademarks of Lotus Development Corporation and/or IBM Corporation.
The following are trademarks of other companies:
Linux is a registered trademark of Linus Torvalds.
Solaris, Java and all Java-based trademarks and logos are trademarks of Sun Microsystems, Inc. in the United
States, other countries or both.
Windows and Windows 2003 Enterprise Server are trademarks of Microsoft Corporation in the United States
and/or other countries
Oracle 10 and all Oracle-based trademarks and logos are trademarks of the Oracle Corporation in the United
States, other countries or both.
LoadRunner is a trademark of Mercury in the United States and/or other countries.
Other company, product and service names may be trademarks or service marks of others.
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PAPER ”AS IS” WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain trans-
actions, therefore, this statement may not apply to you.
Information in this paper as to the availability of products (including portlets) was believed accurate as of the
time of publication. IBM cannot guarantee that identified products (including portlets) will continue to be made
available by their suppliers.
This information could include technical inaccuracies or typographical errors. Changes may be made periodi-
cally to the information herein; these changes may be incorporated in subsequent versions of the paper. IBM may
make improvements and/or changes in the product(s) and/or the program(s) described in this paper at any time
without notice.
Any references in this document to non-IBM web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the mate-
rials for this IBM product and use of those Web sites is at your own risk.
IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not give you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing

IBM Corporation
North Castle Drive
Armonk, NY, USA 10504-1785
Date: 2007/12/18 17:23:34 20 / 20 Revision: 1.3

wp6 WCM db2-TuningGuide

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

wp6 WCM db2-TuningGuide

Загружено:

Авторское право:

Доступные форматы

IBM

WebSphere Portal Version 6.0

December 18, 2007

RCSfile: wp6wcmdb2-TuningGuide.tex,v Date: 2007/12/18 17:23:34 Revision: 1.3

1 Performance Tuning the Environment 1

2 Understanding the Environment 1

3 Application Server Tuning 2

4 DB2 registry variables 5

5 Database Manager configuration parameters 7

6 Database configuration parameters 8

8 Ongoing database maintainence 11

9 Directory Server Tuning 14

10 WebSphere Portal Service Properties 15

A Stored Procedures - Buffer Pool Hit Ratio 16

1 Performance Tuning the Environment

• Determining the cloning strategy for expanding or extending the environment

• Tuning the database(s) and database server

• Tuning the directory server and its database

• Tuning the web server

• Tuning the operating system and network

• Tuning the WebSphere Portal services

2 Understanding the Environment

Date: 2007/12/18 17:23:34 1 / 20 Revision: 1.3

3 Application Server Tuning

Parameter Setting Additional Details

see section 3.1

see section 3.2

see section 3.3

3.1 JVM Max Heap Size Limits

Date: 2007/12/18 17:23:34 2 / 20 Revision: 1.3

How-To Set Parameter:

In the WebSphere Administrative Console: Servers → Application Servers → WebSphere

3.2 JVM Large Page Tuning

How-To Set Parameter:

1. In the WebSphere Administrative Console: Servers → Application Servers → Web-

Date: 2007/12/18 17:23:34 3 / 20 Revision: 1.3

3.3 kCluster and pCluster

How-To Set Parameter:

In the WebSphere Administrative Console: Servers → Application Servers → WebSphere

3.4 Datasource Tuning

Date: 2007/12/18 17:23:34 4 / 20 Revision: 1.3

datasources. These are:

Database Database name Datasource name

3.5 Application Server Cloning

4 DB2 registry variables

Date: 2007/12/18 17:23:34 5 / 20 Revision: 1.3

DB2 MINIMIZE LISTPREFETCH Necessary to avoid an inefficient access plan for a

4.1 Optional variables

Date: 2007/12/18 17:23:34 6 / 20 Revision: 1.3

5 Database Manager configuration parameters

QUERY HEAP SZ 32768

As the instance user enter the following commands:

db2 "update dbm cfg using query_heap_sz 32768"

Date: 2007/12/18 17:23:34 7 / 20 Revision: 1.3

6 Database configuration parameters

db2 "update db cfg for DBNAME using applheapsz 4096"

Date: 2007/12/18 17:23:34 8 / 20 Revision: 1.3

6.2 Parameters for the JCR database

db2 "update db cfg for JCRDB using dbheap 4800"

Date: 2007/12/18 17:23:34 9 / 20 Revision: 1.3

7.1 Collating Sequence

7.2 changing JCR tables to be not volatile

db2 -x -r "nonVolatile.db2" "select rtrim(concat(’alter table ’,