Insert VERITAS™ White Paper Title...

W H I T E P A P E R

VERITAS Storage Foundation 4.0 for DB2 - Performance Brief

OLTP COMPARISON

Solaris 9

1

TABLE OF CONTENTS Introduction.................................................................................................................................................................3 Test Configuration ......................................................................................................................................................3 Results and Analysis ..................................................................................................................................................4 Summary ....................................................................................................................................................................7 Appendix A .................................................................................................................................................................9 Appendix B ...............................................................................................................................................................12

Copyright © 2003 VERITAS Software Corporation. All rights reserved. VERITAS, the VERITAS Logo and all other VERITAS product names and slogans are trademarks or registered trademarks of VERITAS Software Corporation. VERITAS, the VERITAS Logo Reg. U.S. Pat. & Tm. Off. Other product names and/or slogans mentioned herein may be trademarks or registered trademarks of their respective companies. Specifications and product offerings subject to change without notice.

2

INTRODUCTION This document describes the performance of VERITAS Storage Foundation 4.0 for DB2 in a 64-bit Solaris 9 operating environment as measured by an Online Transaction Processing (OLTP) workload. The purpose of this brief is to illustrate the impact of different I/O and memory configurations on the database performance. The benchmark used for this performance comparison was derived from the commonly known TPC-C benchmark that comprises a mixture of read-only and update intensive transactions to simulate a warehouse supplier environment. (Details on this benchmark can be obtained from the Transaction Processing Council’s web page at http://www.tpc.org.) VERITAS Storage Foundation 4.0 for DB2 is comprised of the following components: •

• • • •

• • • • • •

• • •

• • •

•

• • • • • •

VERITAS Storage Foundation, including: VERITAS Volume ManagerTM (VxVM) 4.0 VERITAS File SystemTM (VxFS) 4.0 Quick I/O (a VERITAS File System feature, unique to Storage Foundation for Databases) Cached Quick I/O (a VERITAS File System feature, unique to Storage Foundation for Databases)

FlashSnap Storage Mapping Storage Checkpoint / Rollback VERITAS Enterprise Administrator (user interface) VERITAS Cluster Server (included with HA version of Storage Foundation for DB2) VERITAS Cluster Server agent for DB2 (included with HA version of Storage Foundation for DB2)

The following software releases were used in the tests:

Storage Foundation 4.0 for DB2 DB2 Universal Database 7.2 (version 7.2, 32-bit, with fixpak10a) Solaris 9 (release 8/02, 64bit)

TEST CONFIGURATION The OLTP benchmark tests were conducted using the following server and storage configuration:

1 x Sun Microsystems Ultra Enterprise F15000 server domain 8 x 1.05GHz UltraSPARC III processors 32 GB of physical memory.

The UE F15000 system was attached to:

1 x 3PAR InServ S400 X-Series Storage System via 4 x Sun StorEdge PCI dual port host bus adapters

3PAR Storage System included: 2 x 3PAR X-Series Controller Nodes 12 Drive Enclosures 2 x 2-GB Control Cache (4 GB Total) 2 x 4-GB Data Cache (8 GB Total) 136 x 36-GB Hitachi disk drives (plus 12 hot spares)


3

http://www.tpc.org/

The 136 physical drives were configured into 20 VLUNs: •

• •

• •

• • •

RAID-5 VLUN s 16 x 95-GB RAID-5 VLUNs Each RAID-5 VLUN used 7 disks (6 disks for data and 1 for parity) and was configured with a default stripe size of 128 KB The 16 RAID-5 VLUNs were used to store database tables

RAID-1 VLUNs 4 x 16-GB RAID-1 VLUNs Each RAID-1 VLUN configuration was a simple mirror across 2 physical drives The 4 x RAID-1 VLUNs were used for DB2 log files

A single file system used for DB2 containers was configured on top of a 16-way, striped, 164-GB volume that was, in turn, built on 16 RAID-5 VLUNs. This setup was used for all I/O configurations that involved file systems. For the raw I/O configuration, all DB2 containers were striped, 16-way on the same set of VLUNs as the file system described above to ensure equal drive usage. A separate file system for DB2 log files was configured on a 4-way, striped 8-GB volume, built on the 4 RAID-1 VLUNs. The same file system for DB2 log files was used for all I/O configurations that were tested. VERITAS Volume Manager was used to create the striped volumes for all configurations. The size of the DB2 database used for the test was roughly 93 GB, representing a fully scaled TPC-C database with a scale factor of 1,000 warehouses. Five (5) DB2 tablespaces and 20 x 8-GB DB2 containers were created to house all the database tables. The benchmark tests were conducted using 4 DB2 Bufferpool sizes (500MB, 1.0GB, 1.5GB, and 2.0GB) for each of the following 6 I/O configurations: RAW – using the VERITAS Volume Manager raw volumes directly QIO – using the Quick I/O feature of VERITAS File System CQIO – using the Cached Quick I/O feature of VERITAS File System BIO – using the VERITAS File System’s default Buffered I/O mode DIO – using the VERITAS File System’s Direct I/O mode1 QCKPT - using the Quick I/O feature of VERITAS File System with VERITAS Storage Checkpoint The DB2 block size used for all of the tests was 4k. During the tests, vmstat, iostat and vxstat were used to gather system and I/O statistics. The system parameters and DB2 parameters used in the benchmark tests are provided in Appendix A and B.

RESULTS AND ANALYSIS The primary performance metric used in this brief is a throughput metric that measures the number of transactions completed per minute (TPM). The transaction mix in this OLTP benchmark represents the processing of an order as it is entered, paid for, checked, and delivered, following the model of a complete business transaction. The TPM metric is, therefore, considered a measure of business throughput. Table 1 lists the relative TPM throughput of each I/O configuration compared to VERITAS Volume Manager (VxVM) raw throughput under different DB2 Bufferpool sizes, while the number of concurrent TPCC clients was fixed at 60. The plot of TPM throughput, relative to raw throughput, is shown in Figure 1.

1 VxFS DIO mode uses the mount option “–o convosync=direct.”


4

Table 1 –Relative TPM Throughput for Various I/O and Memory Configurations versus Raw I/O

Transactions per Minute (TPM) Throughput Relative to Raw I/O (1.00)

(60 Concurrent Users)

I/O Configurations

DB2 Bufferpool Size Quick I/O Cached

Quick I/O Buffered I/O Direct I/OQuick I/O with

Storage Checkpoints

0.5 GB .99 1.51 .88 .51 .85

1.0 GB .99 1.47 .88 .51 .85

1.5 GB .99 1.43 .88 .51 .84

2.0 GB .99 1.44 .90 .45 .84

Figure 1 - Plot of Relative TPM Throughput Compared to Raw I/O

60 User TPM-C Throughput Comparison

0.00

0.200.40

0.60

0.80

1.001.20

1.40

1.60

0.5GB 1.0GB 1.5GB 2.0GB

IO configurations

Rel

ativ

e Th

roug

hput

Rat

io w

ith V

xVM

R

AW

= 1 qio

cqiobiodioqio_ckpt


5

Figure 1 shows that the throughput of Quick I/O is practically identical to that of the VERITAS Volume Manager raw I/O configuration, which is set to the value of 1.00. This confirms that Quick I/O provides an excellent method for achieving raw I/O performance while still delivering the ease of file system manageability to DB2 databases. The large performance gain (even beyond raw I/O throughput) that was achieved with Cached Quick I/O can be observed in Figure 1, especially with smaller DB2 Bufferpool cache sizes. Although the UE F15K domain used in this test was equipped with 32 GB of physical memory, the maximum DB2 Bufferpool cache size that can be configured with a 32-bit DB2 database is limited to 2 GB. Cached Quick I/O, however, is able to use the vast amount of remaining operating system memory, external to the DB2 Bufferpool, as a second level (page) cache, thereby increasing ‘read’ performance. This performance enhancement, however, decreases as the DB2 Bufferpool size becomes larger, thereby allowing more data blocks to be cached in the DB2 Bufferpool area. The throughput of VERITAS File System Buffered I/O (BIO) was close to 90% of the raw I/O performance. The good performance can be attributed to the large amount of extra physical memory available on the system for file system caching. VERITAS File System Direct I/O achieved roughly half of the raw I/O throughput. Table 2 lists the average CPU utilization during the benchmark tests for all tested I/O configurations. The plot of the average CPU utilization is shown in Figure 2.

Table 2 – Average CPU Utilization of the I/O Configurations

Average CPU Utilization Relative to Raw I/O (1.00)

I/O Configurations

DB2 Bufferpool Size Raw I/O Quick I/O Cached

Quick I/OBuffered

I/O Direct I/O Quick I/O with

Storage Checkpoints

0.5 GB 1.00 1.05 1.40 1.11 .67 1.21

1.0 GB 1.00 1.07 1.40 1.12 .65 1.19

1.5 GB 1.00 1.05 1.36 1.13 .64 1.18

2.0 GB 1.00 1.04 1.33 1.14 .52 1.17


6

Figure 2 – Average CPU Utilization of Various I/O Configurations

Average CPU Utilization with 60 Concurrent Clients

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

.5GB 1.0GB 1.5GB 2.0GBDB2 Bufferpool Size

CPU

Util

izat

ion

Rat

io R

elat

ive

to

VxVM

Raw

(= 1

.00)

qiocqiobiodioqio_ckpt

From Figure 1, the relative throughput chart, we observed that Quick I/O was able to achieve near raw I/O performance. In Figure 2 we observe that Quick I/O achieved near raw performance while consuming only small percentages of additional CPU cycles compared to that of raw I/O. Cached Quick I/O, achieved almost 50% more throughput than raw I/O, but required only 33 to 40% additional CPU resources. The system was clearly restrained on CPU capacity at this throughput level. Had there been more CPU resources available, we might see Cached Quick I/O achieve even higher throughput levels. The enabling of VERITAS Storage Checkpoint with Quick I/O caused roughly 15% throughput degradation at the 60-user workload level, while consuming an additional 12 to 15% of CPU resources compared to Quick I/O. SUMMARY The OLTP benchmark used in this study represents a common method of evaluating database performance with specific hardware and software configurations. By normalizing the system configuration and varying the file system I/O configuration, it was possible to study the impact of various storage layouts on DB2 database performance with this benchmark.


7

The OLTP performance measurements illustrate that Quick I/O, a feature of VERITAS Storage Foundation 4.0 for DB2, enables DB2 to achieve performance that is virtually equal to the VERITAS Volume Manager raw I/O configuration. This performance behavior is consistent with what has been observed for other VERITAS products, such as Storage Foundation 4.0 for Oracle. The benchmark tests conducted for this brief used 32-bit DB2. When 32-bit DB2 is used, the largest Bufferpool size that can be allocated for DB2 is 2 GB. VERITAS Cached Quick I/O enables systems with large amounts of memory to utilize the memory beyond the 2-GB DB2 Bufferpool size limit as a second level cache. As shown in the results above, the second level cache improved DB2 performance significantly, when data blocks that could not be cached in the DB2 Bufferpool were cached in the operating system cache. In this 64-bit Solaris 9 environment Cached Quick I/O achieved an almost 50% performance gain over that experienced with raw partitions. The benefit of the second level cache however diminished gradually as the size of DB2 Bufferpool increased. In 64-bit DB2 environments, as there is no practical limit to the size of the DB2 Bufferpool that can be allocated, the advantage of enabling VERITAS Cached Quick I/O may not be as obvious. However, Cached Quick I/O can still help enhance database performance, especially if the System Administrator or Database Administrator is unwilling to commit a large DB2 Bufferpool at database startup time. The dynamic memory allocation provided by Cached Quick I/O is an ideal way to take advantage of the extra physical memory to help improve database performance as needed. Careful tuning on the memory usage may be necessary to achieve optimal performance. At this time, OLTP performance testing of Storage Foundation for DB2 in 64-bit DB2 environments has not yet been conducted. In addition to Quick I/O and Cached Quick I/O, Storage Foundation 4.0 for DB2 provides many other features that can enhance DB2 performance and enable customers to meet higher performance service level agreements. Here are some examples of such features: •

• • •

• •

• •

• •

• •

• •

•

Flexible storage infrastructure Automated database storage administration Online growth of database file systems and volumes Dynamic multi-pathing

Multi-Volume File System Support Policy-based, on-line movement of datafiles to different classes of storage without affecting user or application access

o Move important or busy database files to faster storage o Move unimportant files off faster storage

FlashSnap for off-host processing Maintain performance on production database by moving resource intensive tasks to secondary host

Storage Mapping Obtain complete topological view of storage hierarchy to map database objects down the storage stack to the individual disk level Find and eliminate hotspots

Performance Monitoring Utilities that allow Database / System Administrators to monitor each database file / container

Storage Checkpoints Space-saving snapshots at the file system level that simplify and speed up database backup and restore processes.

For additional information on VERITAS Storage Foundation for DB2 and other VERITAS offerings for DB2 UDB Database environments, please visit the Database Technology Zone at: http://www.veritas.com/van/technologyzone/db2.jsp


8

http://www.veritas.com/van/technologyzone/db2.jsp

APPENDIX A The following /etc/system file was used to configure Solaris 9 for the benchmark tests. *ident "@(#)system 1.18 97/06/27 SMI" /* SVR4 1.5 */ * * SYSTEM SPECIFICATION FILE * * moddir: * * Set the search path for modules. This has a format similar to the * csh path variable. If the module isn't found in the first directory * it tries the second and so on. The default is /kernel /usr/kernel * * Example: * moddir: /kernel /usr/kernel /other/modules * root device and root filesystem configuration: * * The following may be used to override the defaults provided by * the boot program: * * rootfs: Set the filesystem type of the root. * * rootdev: Set the root device. This should be a fully * expanded physical pathname. The default is the * physical pathname of the device where the boot * program resides. The physical pathname is * highly platform and configuration dependent. * * Example: * rootfs:ufs * rootdev:/sbus@1,f8000000/esp@0,800000/sd@3,0:a * * (Swap device configuration should be specified in /etc/vfstab.) * exclude: * * Modules appearing in the moddir path which are NOT to be loaded, * even if referenced. Note that `exclude' accepts either a module name, * or a filename which includes the directory. * * Examples: * exclude: win * exclude: sys/shmsys * exclude drv/ohci exclude: drv/ohci * forceload: * * Cause these modules to be loaded at boot time, (just before mounting * the root filesystem) rather than at first reference. Note that * forceload expects a filename which includes the directory. Also * note that loading a module does not necessarily imply that it will


9

* be installed. * * Example: * forceload: drv/foo * set: * * Set an integer variable in the kernel or a module to a new value. * This facility should be used with caution. See system(4). * * Examples: * * To set variables in 'unix': * * set nautopush=32 * set maxusers=40 * * To set a variable named 'debug' in the module named 'test_module' * * set test_module:debug = 0x13 * Begin MDD root info (do not edit) *forceload: misc/md_trans *forceload: misc/md_raid *forceload: misc/md_hotspares *forceload: misc/md_sp *forceload: misc/md_stripe *forceload: misc/md_mirror *forceload: drv/pcisch *forceload: drv/pci_pci *forceload: drv/glm *forceload: drv/sd *rootdev:/pseudo/md@0:0,0,blk * End MDD root info (do not edit) * * Recommended kernel parameters for "DB2 for Solaris" * for systems with more than 512MB of physical memory * set msgsys:msginfo_msgmax = 65535 set msgsys:msginfo_msgmnb = 65535 set msgsys:msginfo_msgmap = 258 set msgsys:msginfo_msgmni = 256 set msgsys:msginfo_msgssz = 16 set msgsys:msginfo_msgtql = 1024 set msgsys:msginfo_msgseg = 32768 * *set shmsys:shminfo_shmmax = 536870912 set shmsys:shminfo_shmmax = 2147483648 set shmsys:shminfo_shmseg = 16 set shmsys:shminfo_shmmni = 300 * set semsys:seminfo_semmni = 1024 set semsys:seminfo_semmap = 1026


10

set semsys:seminfo_semmns = 2048 set semsys:seminfo_semmnu = 2048 * vxvm_START (do not remove) forceload: drv/vxdmp forceload: drv/vxio forceload: drv/vxspec * vxvm_END (do not remove) * vxfs_START -- do not remove the following lines: * VxFS requires a stack size greater than the default 8K. * The following value allows the kernel stack size to be * increased to 24K for Solaris 7, 8 and 9, and 16K for Solaris 2.6. set lwp_default_stksize=0x6000 * vxfs_END * vxfs_START -- do not remove the following lines: * VxFS requires a stack size greater than the default 8K. * The following value allows the kernel stack size to be * increased to 24K for Solaris 7, 8 and 9, and 16K for Solaris 2.6. set rpcmod:svc_default_stksize=0x6000 * vxfs_END


11

APPENDIX B

The following DB2 database configuration file was used in the benchmark tests. The BUFFPAGE parameter was changed for different DB2 Bufferpool sizes. Database Configuration for Database TPCC Database configuration release level = 0x0900 Database release level = 0x0900 Database territory = US Database code page = 819 Database code set = ISO8859-1 Database country code = 1 Dynamic SQL Query management (DYN_QUERY_MGMT) = DISABLE Directory object name (DIR_OBJ_NAME) = Discovery support for this database (DISCOVER_DB) = ENABLE Default query optimization class (DFT_QUERYOPT) = 5 Degree of parallelism (DFT_DEGREE) = 1 Continue upon arithmetic exceptions (DFT_SQLMATHWARN) = NO Default refresh age (DFT_REFRESH_AGE) = 0 Number of frequent values retained (NUM_FREQVALUES) = 10 Number of quantiles retained (NUM_QUANTILES) = 20 Backup pending = NO Database is consistent = YES Rollforward pending = NO Restore pending = NO Multi-page file allocation enabled = NO Log retain for recovery status = NO User exit for logging status = NO Data Links Token Expiry Interval (sec) (DL_EXPINT) = 60 Data Links Number of Copies (DL_NUM_COPIES) = 1 Data Links Time after Drop (days) (DL_TIME_DROP) = 1 Data Links Token in Uppercase (DL_UPPER) = NO Data Links Token Algorithm (DL_TOKEN) = MAC0 Database heap (4KB) (DBHEAP) = 512 Catalog cache size (4KB) (CATALOGCACHE_SZ) = 64 Log buffer size (4KB) (LOGBUFSZ) = 32 Utilities heap size (4KB) (UTIL_HEAP_SZ) = 5000 Buffer pool size (pages) (BUFFPAGE) = 500000 Extended storage segments size (4KB) (ESTORE_SEG_SZ) = 16000 Number of extended storage segments (NUM_ESTORE_SEGS) = 0 Max storage for lock list (4KB) (LOCKLIST) = 150 Max appl. control heap size (4KB) (APP_CTL_HEAP_SZ) = 128 Sort list heap (4KB) (SORTHEAP) = 16 SQL statement heap (4KB) (STMTHEAP) = 2048 Default application heap (4KB) (APPLHEAPSZ) = 328 Package cache size (4KB) (PCKCACHESZ) = 40 Statistics heap size (4KB) (STAT_HEAP_SZ) = 4384 Interval for checking deadlock (ms) (DLCHKTIME) = 3000 Percent. of lock lists per application (MAXLOCKS) = 20 Lock timeout (sec) (LOCKTIMEOUT) = -1 Changed pages threshold (CHNGPGS_THRESH) = 40 Number of asynchronous page cleaners (NUM_IOCLEANERS) = 4 Number of I/O servers (NUM_IOSERVERS) = 1


12

Index sort flag (INDEXSORT) = YES Sequential detect flag (SEQDETECT) = NO Default prefetch size (pages) (DFT_PREFETCH_SZ) = 32 Track modified pages (TRACKMOD) = OFF Default number of containers = 1 Default tablespace extentsize (pages) (DFT_EXTENT_SZ) = 32 Max number of active applications (MAXAPPLS) = 128 Average number of active applications (AVG_APPLS) = 1 Max DB files open per application (MAXFILOP) = 800 Log file size (4KB) (LOGFILSIZ) = 4000 Number of primary log files (LOGPRIMARY) = 10 Number of secondary log files (LOGSECOND) = 20 Changed path to log files (NEWLOGPATH) = Path to log files = /db2log/LOGDIR/ First active log file = Group commit count (MINCOMMIT) = 1 Percent log file reclaimed before soft chckpt (SOFTMAX) = 250 Log retain for recovery enabled (LOGRETAIN) = OFF User exit for logging enabled (USEREXIT) = OFF Auto restart enabled (AUTORESTART) = ON Index re-creation time (INDEXREC) = SYSTEM (RESTART) Default number of loadrec sessions (DFT_LOADREC_SES) = 1 Number of database backups to retain (NUM_DB_BACKUPS) = 12 Recovery history retention (days) (REC_HIS_RETENTN) = 366 TSM management class (TSM_MGMTCLASS) = TSM node name (TSM_NODENAME) = TSM owner (TSM_OWNER) = TSM password (TSM_PASSWORD) =


13

VERITAS Software Corporation Corporate Headquarters 350 Ellis Street Mountain View, CA 94043 650-527-8000 or 866-837-4827

For additional information about VERITAS Software, its products, or the location of an office near you, please call our corporate headquarters or visit our Web site at www.veritas.com.


14

http://www.veritas.com/

Date post:	18-Jul-2018
Category:	Documents
Upload:	buikhuong
View:	231 times
Download:	0 times

Insert VERITAS™ White Paper Title...

Documents