Contents: IBM Mashup Center Performance Tuning Guide
Download this content as a PDF file
General tuning for both Lotus Mashups and MashupHub databases
DB2 tuning generally revolves around these three R
- runstats: update statistics using the following command: db2 "runstats on table <schema>.<tablename> with distribution and detailed indexes all". You should update statistics regularly to ensure that queries run optimally.
- reorg: reorganize tables using the following command: db2 "reorg table <schema>.<tablename>". Based on our measurements, you only need to reorganize tables occasionally after the database is populated.
- rebind: rebind the database using the following command: db2rbind -l logfile all -u <db2admin id> -p <db2admin password>. Rebinding the database is needed only intermittently, for example after any database schema change such as an index addition or column change.
To review table and index reorg
needs, run the following command from a DB2 command window: db2 "reorgchk current statistics all table all" > reorgreport.txt
. This command creates a TXT file with output that you can review. In the last column, if you see a *
character, then you should plan to reorganize the table or index in the near future. If you see two or more *
characters, you should reorganize the table immediately. Most times, the indexes for a table will have at least some *
designators. This is because a clean and sequential physical order of many indexes for a single table is not possible.
To review your database configuration settings, run the following command from a DB2 command window: db2 "get db cfg for <yourdb>"
We also recommend that you review the DB2 general error log frequently. There, you may see true process stopping errors as well as general warnings. For a Microsoft® Windows® server, you can locate this file at %DB2PATH%/db2/db2diag.log
, where db2
reflects that your database is in the default DB2 instance named DB2. It could specify a different folder if you are using another instance name.
Buffer pool tuning for both Lotus Mashups and MashupHub databases
Since disk I/O can be a performance bottleneck for Mashup Center, we recommend that you set up and configure a powerful disk array. To improve performance, you can also separate the Lotus® Mashups and MashupHub databases to different hosts as well as add more disks to the table space to share the I/O workload.
The default size of the buffer pool MASHUPSBP32K
is too small. We recommend that you issue the following command to increase the size to 2000: db2 alter BUFFERPOOL MASHUPBP32K IMMEDIATE SIZE 20000
Large object (LOB) data tuning for the MashupHub database
The queries to LOB data on the MashupHub database are not very efficient. This kind of data does not stay in the buffer pool memory, so each LOB query is a disk access, and no real DB2 caching takes place. Several optimization methods are available. One possible method is to reorganize the binary large object (BLOB) and character large object (CLOB) data and turn off the file system caching for the table space.
To reorganize the BLOB and CLOB data, issue the following two commands:
db2 "reorg table <schema>.resources longlobdata"
db2 "reorg table <schema>.plugindata longlobdata"
To turn off the file system caching for the table space, issue the following command:
db2 alter tablespace <tablespacename> no file system caching
In addition, to improve server-side capacity, you may consider adding a new disk storage for the MashupHub table space in order to share the overhead on the disk I/O.
Previous topic: Tuning IBM WebSphere Edge Server
Next topic: Tuning MashupHub feeds