WHITE PAPER. VERITAS Database Edition 1.0 for DB2 PERFORMANCE BRIEF OLTP COMPARISON. Solaris 8. August

Size: px

Start display at page:

Download "WHITE PAPER. VERITAS Database Edition 1.0 for DB2 PERFORMANCE BRIEF OLTP COMPARISON. Solaris 8. August"

Joleen Alexis McGee
5 years ago
Views:

1 WHITE PAPER VERITAS Database Edition 1.0 for DB2 PERFORMANCE BRIEF OLTP COMPARISON Solaris 8 August

2 TABLE OF CONTENTS Introduction...3 Test Configuration...3 Results and Analysis...4 Summary...5 Appendix A...6 Appendix B...9 2

3 Introduction This brief describes the performance of VERITAS Database Edition 1.0 fordb2 in a 64-bit Solaris 8 operating environment as measured by an Online Transaction Processing (OLTP) workload. It illustrates the impact of different I/O and memory configurations on 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 that simulate a warehouse supplier environment. (you can obtain details on this benchmark from the Transaction Processing Council s web page at VERITAS Database Edition 1.0 for DB2 consists of the following components: VERITAS Volume Manager TM (VxVM ) 3.2 VERITAS Volume Manager Storage Administrator TM (VMSA ) 3.2 VERITAS File System TM (VxFS ) 3.4, patch 2 (including Quick I/O, and Cached Quick I/O) Test Configuration The OLTP benchmark tests were conducted on a Sun Microsystems Enterprise 4500 server with 8 processors and 8 GB of memory. The E4500 system was attached with three SUN A5200 disk bricks via three Sun TM StorEdge TM SBus Socal Host Adapters. Each A5200 brick contained GB Seagate drives. The following software releases were used in the tests: DB2 Universal Database Enterprise Edition 7.2 (version 7 release 2, 32-bit) DB2 Universal Database 7.2 (version 7 release 2, 32-bit) Solaris 8, Update 4 (release 4/01, 64-bit) The file systems under test were configured over one 30-way striped 32 GB volume built on 30 disks that were attached to two controllers. Except for the DB2 log volume, all file systems were built on this striped volume. The DB2 log volume was built on a separate 4-way striped volume. For the raw I/O configuration, all the database files except DB2 logs were striped 30-way on the same set of disk drives to ensure equal drive usage. VERITAS Volume Manager was used to create the striped volumes for all configurations. The size of the database used for the test was 25 GB. A USER TABLESPACE with a single container was created to house all the user database tables. The size of the database is that of a fully scaled TPC-C database with a scale factor of 250 warehouses. The benchmark tests were conducted with four DB2 buffer pool sizes: 500MB, 1.0GB, 1.5GB, and 2.0GB, with the following five I/O configurations: RAW uses the VERITAS Volume Manager raw volumes directly, QIO uses the Quick I/O feature of VERITAS File System, CQIO uses the Cached Quick I/O feature of VERITAS File System, BIO uses the default VERITAS File System Buffered I/O mode, DIO uses the VERITAS File System Direct I/O mode 1, The DB2 block size used for all these tests was 4K. During the test, vmstat and iostat were used to gather system statistics. The system parameter and DB2 parameters used in the benchmark tests are provided in Appendices A and B. 1 VxFS DIO mode uses the mount option o convosync=direct. 3

4 Results and Analysis The primary performance metric used here 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 activity. The tpm metric is, therefore, considered a measure of business throughput. Table 1 lists the database throughput of the benchmark tests in different I/O configurations and various DB2 buffer pool sizes. The relative plot of database throughput compared to Raw I/O is shown in Figure 1. Table 1 - Database throughput of the benchmark tests. Database Throughput in Transactions per minutes (TPM) I/O Configuration Size of DB2 Buffer Pool Cache 500MB 1.0GB 1.5GB 2.0GB Raw I/O 5,242 7,013 9,055 11,950 Quick I/O (QIO) 5,240 7,072 9,249 12,226 Cached Quick I/O (CQIO) 11,233 11,761 12,264 12,511 VxFS Buffered I/O (BIO) VxFS Direct I/O (DIO) Figure 1 Relative database throughput compared to RAW I/O. 180% Percentage of Raw Performance RAW=100% 160% 140% 120% 100% 80% 60% 40% 20% 0% 500MB 1.0GB 1.5GB 2.0GB DB2 Bufferpool Size QIO CQIO BIO DIO Figure 1 shows that the database throughput with Quick I/O matches closely with that of the Raw I/O configuration. This graph confirms the excellence of Quick I/O for achieving performance equivalent to that of Raw I/O, while still providing file system manageability to DB2 databases. Figure 1 shows a large performance gain for Cached Quick I/O, especially with smaller DB2 buffer pool cache sizes. This gain is the result of Cached Quick I/O being able to use the vast amount of operating system memory, external to the DB2 buffer pool as a second level cache. However, this performance gap decreases when the DB2 buffer pool size increases. An 4

5 increase in the size of the DB2 buffer pool allows more data blocks to be cached in the DB2 buffer pool area. It thus improves the buffer pool cache hit ratio and reduces the benefit of using the operating system page cache. The throughput of VERITAS File System Buffered I/O and VERITAS File System Direct I/O configurations were just a fraction of the Raw I/O throughput. The results were a consequence of the TPC-C database being housed in a single TABLESPACE container. Each container is essentially a file under the Solaris file system construct. As a result, the single-file writer lock contributed to the low throughput in the test of these three I/O configurations. For the other I/O configurations, the single container setup helped to achieve better throughput as compared with striping the TPC-C database tables across 15 containers. Table 2 lists the average CPU utilization of the benchmark tests for Raw I/O and Quick I/O configurations. The table shows that Raw I/O and Quick I/O configurations were very close in average CPU utilization. Table 2 - Average CPU utilization of the benchmark tests. Average CPU Utilization I/O Configuration Size of DB2 Buffer Pool Cache 500MB 1.0GB 1.5GB 2.0GB Raw I/O 37.4% 46.4% 57.1 % 80.1% Quick I/O 39.4% 48.1% 61.1% 83.5% Summary The OLTP benchmark used in this study is commonly used to evaluate database performance of specific hardware and software configurations. By normalizing the system configuration and varying the file system I/O configuration, it became possible to study the impact of various storage layouts on database performance with this benchmark. The OLTP performance measurements illustrate that Quick I/O enables the VERITAS Database Edition for DB2 to perform at the same levels as raw volume configurations. This finding is consistent with what had previously been observed in other VERITAS Database editions, such as VERITAS Database Edition TM for Oracle. When 32-bit DB2 and a 4K data block size are used, the largest buffer pool size that can be allocated by DB2 is 2GB. For systems with a large memory, the memory beyond the 2GB DB2 buffer pool size limit can be used to provide a second-level cache with Cached Quick I/O. The second-level cache improves DB2 performance when data blocks that could not be cached in the DB2 buffer pool can be cached in the operating system cache. In the 64-bit Solaris 8 environment Cached Quick I/O achieved up to a 160% performance gain over that experienced with raw volumes. The benefit of the second-level cache may be diminished somewhat when 64-bit DB2 is available 64-bit DB2 allows for more than 2GB memory to be allocated for the DB2 buffer pool. However, Cached Quick I/O may still be able to help the database performance because of its read-ahead algorithm. Careful tuning of the memory usage may be necessary to achieve optimal performance. In addition, the ease of installation of Database Edition for DB2, the Quick I/O utility that allows administrator to monitor each database container separately, and the support for VERITAS FlashSnap TM to ease DB2 online backup/restore may prove to be crucial in maintaining an optimal DB2 environment. 5

6 Appendix A The following /etc/system file was used to configure Solaris 8 for the benchmark tests. ident "@(#)system /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,f /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 6

7 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 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 set shmsys:shminfo_shmmax= set shmsys:shminfo_shmmax= set shmsys:shminfo_shmmax= set shmsys:shminfo_shmmax=0xffffffff set shmsys:shminfo_shmmax= set shmsys:shminfo_shmmni=256 set shmsys:shminfo_shmseg=100 set shmsys:shminfo_shmmin=1 set semsys:seminfo_semmap=256 set semsys:seminfo_semmni=4096 set semsys:seminfo_semmns=4096 set semsys:seminfo_semmsl=75 set semsys:seminfo_semmnu=4096 set semsys:seminfo_semume=64 set semsys:seminfo_semopm=50 Recommended kernel parameters for "DB2 for Solaris" for systems with more than 512MB of physical memory set msgsys:msginfo_msgmax = set msgsys:msginfo_msgmnb = set msgsys:msginfo_msgmap = 258 7

8 set msgsys:msginfo_msgmni = 256 set msgsys:msginfo_msgssz = 16 set msgsys:msginfo_msgtql = 1024 set msgsys:msginfo_msgseg = set shmsys:shminfo_shmmax = set shmsys:shminfo_shmseg = 16 set shmsys:shminfo_shmmni = 300 set semsys:seminfo_semmni = 1024 set semsys:seminfo_semmap = 1026 set semsys:seminfo_semmns = 2048 set semsys:seminfo_semume = 64 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 values allow the kernel stack size for all threads to be increased to 16K. set lwp_default_stksize=0x4000 vxfs_end vxfs_start -- do not remove the following lines: VxFS requires a stack size greater than the default 8K. The following values allow the kernel stack size for nfs threads to be increased to 16K. set rpcmod:svc_default_stksize=0x4000 vxfs_end 8

9 Appendix B The following DB2 database configuration file was used in the benchmark tests. Database Configuration for Database TPCC Database configuration release level = 0x0900 Database release level = 0x0900 Database territory = US Database code page = 819 Database code set = ISO 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) Default refresh age (DFT_REFRESH_AGE) = 0 Number of frequent values retained (NUM_FREQVALUES) = 10 Number of quantiles retained (NUM_QUANTILES) = 20 Backup pending Database is consistent = YES Rollforward pending Restore pending Multi-page file allocation enabled Log retain for recovery status User exit for logging status 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) 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) = Extended storage segments size (4KB) (ESTORE_SEG_SZ) = 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 9

10 Index sort flag (INDEXSORT) = YES Sequential detect flag (SEQDETECT) 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) = VERITAS Software Corporation Corporate Headquarters 350 Ellis Street Mountain View, CA or 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 10

WHITE PAPER. VERITAS Database Edition 1.0 for DB2 PERFORMANCE BRIEF OLTP COMPARISON AIX 5L. September

WHITE PAPER. VERITAS Database Edition 1.0 for DB2 PERFORMANCE BRIEF OLTP COMPARISON AIX 5L. September WHITE PAPER VERITAS Database Edition 1.0 for DB2 PERFORMANCE BRIEF OLTP COMPARISON AIX 5L September 2002 1 TABLE OF CONTENTS Introduction...3 Test Configuration...3 Results and Analysis...4 Conclusions...6