SAP SD Benchmark using DB2 running Red Hat Enterprise ... · PDF fileSAP® SD Benchmark...

SAP® SD Benchmark using DB2® running Red Hat® Enterprise Linux® 5 Virtualization on IBM System x3850 M2

Version 1.0 December 2008

www.redhat.com 2 www.ibm.com

SAP® SD Benchmark using DB2 running Red Hat® Enterprise Linux® 5 Virtualization on IBM System x3850 M2 1801 Varsity Drive Raleigh NC 27606-2072 USA Phone: +1 919 754 3700 Phone: 888 733 4281 Fax: +1 919 754 3701 PO Box 13588 Research Triangle Park NC 27709 USA The following terms used in this publication are trademarks of other companies as follows:

• IBM System x, IBM, ServeRAID, DB2 and all other IBM products and services mentioned herein are trademarks of International Business Machines Corporation in the United States and other countries

• Linux is a registered trademark of Linus Torvalds • Red Hat, Red Hat Enterprise Linux and the Red Hat "Shadowman" logo are registered

trademarks of Red Hat, Inc. in the United States and other countries • SAP® software, SAP NetWeaver™ platform, SAP® R/3® Enterprise sofware, mySAP® and all

other SAP products and services mentioned herein are registered trademarks of SAP AG in Germany and other countries

• Intel and Xeon are registered trademarks of Intel Corporation All other trademarks referenced herein are the property of their respective owners. © 2008 by Red Hat, Inc. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, V1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). The information contained herein is subject to change without notice. Red Hat, Inc. and IBM Corporation shall not be liable for technical or editorial errors or omissions contained herein. Distribution of modified versions of this document is prohibited without the explicit permission of Red Hat Inc. and Corporation. Distribution of this work or derivative of this work in any standard (paper) book form for commercial purposes is prohibited unless prior permission is obtained from Red Hat Inc. and IBM Corporation. The GPG fingerprint of the [email protected] key is: CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E

www.ibm.com 3 www.redhat.com

Table of Contents

1. Introduction & Executive Summary ..................................................................................................... 4

1.1 Introduction to Red Hat Enterprise Linux (RHEL) 5 Virtualization .............................................. 4 1.2 Running the SAP SD Benchmark using RHEL 5 Virtualization .................................................... 5 1.3 Virtualization Efficiency of RHEL 5 running the SAP SD Benchmark in a Large Guest ............. 6 1.4 SAP SD Benchmark Performance on Competing Virtualization Technologies ............................. 7

2. SAP SD Benchmark Overview ............................................................................................................. 9 2.1 Benchmark Description & Methodology ........................................................................................ 9 2.2 Key Performance Metrics ............................................................................................................. 11

2.2.1 Benchmark Users and Average Dialog Response Time ........................................................ 11 2.2.2 Throughput Measurement in SAPS ....................................................................................... 11

2.3 What must be published ................................................................................................................ 11 3. System Configuration ......................................................................................................................... 13

3.1 Hardware Configuration ............................................................................................................... 14 3.2 Software Configuration ................................................................................................................. 15

4. Configuration Steps & Tuning ............................................................................................................ 17 4.1 DB2 Database Tuning ................................................................................................................... 17 4.2 SAP Tuning ................................................................................................................................... 17

5. Benchmark Performance Results ........................................................................................................ 18 6. Scaling of Throughput with Size of RHEL 5 Guest ........................................................................... 19 7. References ........................................................................................................................................... 20 Appendix A: Certification of this Benchmark by SAP AG .................................................................... 21 Appendix B: Other SAP SD Benchmarks Referenced in Figure 3 ......................................................... 22 Appendix C: Database Tuning ................................................................................................................ 24

Database Parameters ........................................................................................................................... 25


1. Introduction & Executive Summary

1.1 Introduction to Red Hat Enterprise Linux (RHEL) 5 Virtualization Traditional virtualization products relied on hardware emulation, intercepting and translating hardware requests from the guest virtual machines. This approach created significant overhead, especially for I/O intensive workloads and limited the scalability of the virtual environment. For this reason enterprise class workloads such as databases or ERP systems were seldom virtualized in production. “Common wisdom” told us that any system that needed high performance, or needed to scale was not a candidate for virtualization – and this was borne out by customer experience. Hence, applications that require low latency or are time sensitive, such as financial trading applications have so far been unable to benefit from virtualization. In Red Hat Enterprise Linux 5, Red Hat has optimized the operating system to work in a virtualized environment, using para-virtualization (PV) to eliminate the I/O bottlenecks removing the need for complete system emulation. Removing this overhead results in significantly better performance, especially on I/O intensive workloads. Para-virtualization solves issues that have plagued traditional virtualization solutions, such as clock-skew, where issues such as synchronizing the clock between the hypervisor and multiple virtual machines cause time to be “lost” as the guest clock runs more slowly that the host. Red Hat Virtualization supports dynamic resource allocation, allowing memory and CPUs to be dynamically added or removed from the guest. For example, if a guest needs more CPU resources to complete a resource intensive processing job, the user may dynamically add more virtual CPUs (vCPUs), and when the job completes, the extra vCPUs may be reassigned to other guests. Red Hat integrated virtualization supports up to 32 vCPUs per virtual machine, allowing even the largest workloads to be virtualized.


1.2 Running the SAP SD Benchmark using RHEL 5 Virtualization The SAP Sales and Distribution (SD) Standard Application Benchmark has become a de facto standard for evaluating the performance of many ERP solutions. This represents the first time the SAP SD benchmark has been run using Red Hat Enterprise Linux (RHEL) 5 Virtualization. Figure 1 shows the configuration benchmarked. The remainder of this section summarizes some of the key results.

Figure 1: Configuration Benchmarked


1.3 Virtualization Efficiency of RHEL 5 running the SAP SD Benchmark in a Large Guest Figure 2 shows the virtualization efficiency for large guests in RHEL 5.

Figure 2: Virtualization Efficiency of SAP SD on Red Hat Enterprise Linux 5 The bare metal SAP SD benchmark result achieved in November 2008 was documented in a separate report (reference #2):

• 5,156 SAP SD (2-tier) benchmark users achieved by IBM, with Red Hat Enterprise Linux 5.2 and DB2 9.5 running with SAP ECC 6.0 running on IBM System x3850 M2 (4 Processors / 24 Cores / 24 Threads, Intel Xeon Processor X7460, 2.66 Ghz, 64 KB L1 cache per core and 3 MB L2 cache per 2 cores, 16 MB L3 cache per processor. 64 GB RAM.) IBM TotalStorage DS4500 (5 drawers of 14x36GB 15K RPM disks). SAP certification number 2008066.

This report documents the virtual server SAP SD benchmark result achieved in December 2008 by running the benchmark in a Red Hat Enterprise Linux 5 para-virtualized guest:


• 4,400 SAP SD (2-tier) benchmark users achieved by IBM, with Red Hat Enterprise Linux 5.2 (using 24 virtual CPUs) and DB2 9.5 running with SAP ECC 6.0 running on IBM System x3850 M2 (4 Processors / 24 Cores / 24 Threads, Intel Xeon Processor X7460, 2.66 Ghz, 64 KB L1 cache per core and 3 MB L2 cache per 2 cores, 16 MB L3 cache per processor. 64 GB RAM.) IBM TotalStorage DS4500 (5 drawers of 14x36GB 15K RPM disks). SAP certification number 2008077.

1.4 SAP SD Benchmark Performance on Competing Virtualization Technologies Figure 3 shows the best SAP SD results run in virtual servers using different virtualization technologies. At 4400, RHEL 5 Virtualization achieved the largest number of SAP SD users in a virtual sever – compared with 501 for Micorsoft’s Hyper-V and 550 for VMware.

Figure 3: SAP Performance on Competing Virtualization Technologies


• Best Hyper-V SAP SD benchmark result: 501 SAP SD (2-tier) Benchmark users

achieved by Dell, with Windows Server 2003 Enterprise Edition on Windows 2008 Hyper-V (using 2 virtual CPUs) and SQL Server 2005 with SAP ECC 6.0 running on Dell PowerEdge Model R900 (4 Processors / 16 Cores / 16 Threads, Quad-Core Intel Xeon Processor X7350, 2.93 Ghz, 64 KB L1 cache per core and 4 MB L2 cache per 2 cores. 90 GB RAM.) SAP certification number 2008055.

• Best VMware SAP SD benchmark result: 550 SAP SD (2-tier) Benchmark users achieved by VMware, with SuSE Linux Enterprise Server 10 on VMware ESX Server 3.5 (using 2 virtual CPUs) and MaxDB 7.7 with SAP ECC 6.0 running on Fujitsu Siemens Computers PRIMERGY Model TX300 S4 | RX300 S4 (2 Processors / 8 Cores / 8 Threads, Quad-Core Intel Xeon Processor X5460, 3.16 Ghz, 64 KB L1 cache per core and 6 MB L2 cache per 2 cores.) SAP certification number 20080009.

For more details, refer to Appendix B and the SAP benchmark results site: http://www.sap.com/solutions/benchmark/sd2tier.epx More details of these and every other SAP benchmark can be found at http://www.sap.com/benchmark. This benchmark result is a demonstration of the close and continued cooperation between IBM Corp. and Red Hat Inc. to showcase the superior combined performance of Red Hat Enterprise Linux (RHEL) and DB2 running on IBM’s Intel Xeon-based System x servers.


2. SAP SD Benchmark Overview SAP Standard Application Benchmarks help customers and partners find the appropriate hardware configuration for their IT solutions. SAP, working in concert with its hardware partners, has developed the SAP Standard Application Benchmarks to test the hardware and database performance of SAP applications and components. The benchmarking procedure is standardized and well defined. It is monitored by the SAP Benchmark Council made up of representatives of SAP and technology partners involved in benchmarking. Originally introduced to strengthen quality assurance, the SAP Standard Application Benchmarks can also be used to test and verify scalability, concurrency, and multi-user behavior of system software components, RDBMS, and business applications. Customers can benefit from the benchmark results in various ways. For example, benchmark results illuminate the scalability and manageability of large installations. The benchmark results:

• Provide basic information to configure and size SAP Business Suite • Allow users to compare different platforms • Enable Proof-of-concepts scenarios • Provide an outlook for future performance levels (new platforms, new servers, and so

on)

2.1 Benchmark Description & Methodology The SAP SD benchmark can be configured as either two-tier or three-tier. Within the two-tier configuration, the database server and the SAP NetWeaver application server run on the same physical machine. In the three-tier configuration, the presentation tier, application tier, and database tier each run on separate physical servers. This benchmark was run using a two-tier configuration. In the two-tier configuration architecture the database and application layer reside on a single system – the simulation is driven by the presentation server (aka benchmark driver). A SAP Standard Application Benchmark consists of script files that simulate the most typical transactions and workflow of a user scenario. It has a predefined SAP client database that contains sample company data against which the benchmark is run. The benchmark transactions of each component usually reflect the data throughput of an installation (for example orders, number of goods movements, etc.). Note: Each benchmark user has his or her own master data, such as material, vendor, or customer master data to avoid data-locking situations. The Sales and Distribution benchmark is one of the most CPU intensive benchmarks available and has become a de-facto standard for SAP's platform partners and in the ERP (Enterprise Resource Planning) environment. During the benchmark a defined set of business


transactions are run through as shown in the table below. The SD benchmark driver provided by SAP simulates end users driving business transactions in dialog steps. The Sales and Distribution (SD) Benchmark covers a sell-from-stock scenario, which includes the creation of a customer order with five line items and the corresponding delivery with subsequent goods movement and invoicing. It consists of the following SAP transactions:

Create an order with five line items. (VA01) Create a delivery for this order. (VL01N) Display the customer order. (VA03) Change the delivery (VL02N) and post goods issue. List 40 orders for one sold-to party (VA05) Create an invoice. (VF01)

Table 1: Dialog steps of the standard Sales & Distribution (SD) benchmark Each of the simulated users repeats this series of transactions from the start to the end of a benchmark run. During the so-called ramp-up phase the number of concurrently working users is increased until the expected limit (e.g. 5000) is reached. When all users are active the test interval starts. This performance level must be maintained for at least 15 minutes (benchmark rule). After at least 5 minutes of the high load phase one or more database checkpoints must be forced (i.e. all log file data is flushed back to the database) to stress the I/O subsystem in a realistic way (benchmark rule). At the end of the high load phase users are gradually taken off the system until none is active. When the test concludes all relevant data (some are gathered with a SAP developed Operating System monitor) are then transferred to the presentation server for further evaluation.

Figure 4: Benchmark Run


The SAP Standard Application Benchmarks measure all performance relevant metrics such as database request times, wait times, CPU utilization, average dialog response times by a given number of benchmark users (with a fixed think time of 10 seconds between each dialog step) and the achieved throughput.

2.2 Key Performance Metrics

2.2.1 Benchmark Users and Average Dialog Response Time A benchmark can only be certified if the average dialog response time is less than two seconds (this is the number which some time ago was accepted as a tolerable system reaction time). More and more benchmark users are ‘switched’ to the system under test until the response time is outside the granted time frame. Only SAP certified and audited benchmarks may be published by partners to ensure results that can be fairly compared with each other. A typical result would read like ‘5000 SD benchmark users with an average dialog response time of 1.98 seconds’.

2.2.2 Throughput Measurement in SAPS SAP has defined a unit for measuring throughput in a mySAP® Business Suite environment: SAPS (SAP Application Benchmark Performance Standard). 100 SAPS are defined as 2,000 fully processed business line items per hour in the standard SD application benchmark. This throughput is achieved by processing 6,000 dialog steps (screen changes) and 2,000 postings per hour in the SD benchmark or processing 2,400 SAP transactions. In the SD standard benchmark ‘fully business processed’ means the full business workflow of an order line item (creating the order, creating a delivery note for this order, displaying the order, changing the delivery, posting a goods issue, listing orders and creating an invoice) has completed.

2.3 What must be published The following information must be part of a benchmark press release:

• Type of client/server configuration (2-tier or 3-tier) • The mySAP Business Suite component • RDBMS type and version number • Operating System type and version number • Tested standard mySAP Business Suite components (FI, PP, SD,... or a combination


of these) • Number of tested benchmark users • Average dialog response time in ‘n.nn sec’ • Achieved throughput in dialog steps / hour • A detailed description of hardware configuration (type, size of main memory, average

CPU utilization and func-tion for all servers involved in the benchmark) • Confirmation that the benchmark is certified by SAP (e.g. "This benchmark fully

complies with SAP's issued benchmark regulations and has been audited and certified by SAP.")

• Reference where readers can get more information (e.g. "Details regarding this benchmark are available upon request from hardware partner or SAP AG.").


3. System Configuration

Figure 5: Hardware Configuration


3.1 Hardware Configuration Hardware Configuration:

• IBM System x3850 M2, equipment with: o 4x Intel Xeon X7460 six core processors running at 2.66GHz, with 3MB L2

cache per core, and 16MB L3 cache per processor. 24 cores in total. o 64GB DDR2 RAM o 1 x 146GB internal SAS disk o 1 x IBM 4GB Dual Port FibreChannel PCI-E HBA

• IBM Total Storage DS4500 controller, 1742-900, with

o 2 I/O controllers with 1GB of cache memory each o 4 EXP-710 enclosures, with 14 x 36GB, 10K RPM drives, for a total of 56 disks o Five volumes were created from the 56 disks

1 RAID5 volume striped across all 14 disks in one enclosure for the SAP binaries, backup, and other indicadental files

1 RAID0 volume striped across all 14 disks of another enclosure for the database log

1 RAID5 volume striped across all 14 disks of the third enclosure for the main portion of the DB2 database

1 RAID0 volume striped across all 14 disks and of the fourth enclosure to hold the multiplexed VBDATA tables

and 1 RAID0 volume stripped across all 14 disks of the fifth enclosure hold the I/O sensitive database tables.


3.2 Software Configuration Software Configuration:

• Red Hat Enterprise Linux 5.2 • SAP Enterprise Core Component (ECC) 6.0, with the NetWeaver 7.0 kernel • DB2 v9.5 Enterprise Server, Fix Pack 2

Figure 6: SAP SD Benchmark on RHEL 5 on Bare Metal (See Reference #2)


Figure 7: SAP SD Benchmark on RHEL 5 Para-Virtualized Guest


4. Configuration Steps & Tuning

4.1 DB2 Database Tuning The database was tuned to provide sufficient buffer cache to allow the database to perform with 99%+ database buffer access. The database log device was created on a large striped volume on the DS4500 and was created using raw disk volume on the operating system level. Another volume was used to hold the “hot” tables that were accessed extensively in the operation of the benchmark. This allowed for custom tuning of the table parameters and to separate the I/O of these tables from the rest of the database activity. The VBDATA tables (VBDATA, VBMOD and VBHDR) were also separated out from their default tablespace and put on another raw device that allowed for less contention with the core database activity and to allow for a custom buffer pool to be used to hold the contents of those tables for faster transaction processing.

4.2 SAP Tuning After the initial installation of the SAP environment, which included the installation of the SAP central instance (CI) and 15 dialog instances, the environment was tuned to set up the appropriately sized buffers and work processes. Each of the 16 SAP instances was configured with 4 Dialog and 1 Update Processes. This allowed for better resource allocation for the SD benchmark workload.


5. Benchmark Performance Results The benchmark result is shown in Table 2. The official certification of this benchmark is shown in Appendix A – SAP certification number 2008077. Benchmark 2-Tier SAP Sales & Distribution (SD) SAP Components SAP ECC 6.0 / NetWeaver 7.0 Database DB2 9.5

Operating System

Red Hat Enterprise Linux (RHEL) 5.2 + RHEL 5 Virtualization (Xen 3.1) on a Virtual Machine using 24 Virtual CPUs running on a server with 24 Physical Cores (= 4 sockets x 6 cores/socket)

Number of simulated users 4,400 (Sales & Distribution) Number of dialog steps / hour 1,322,000 Fully Processed Order Line items/hour 440,670 Average dialog response time 1.99 seconds Average DB request time Dialog = 0.047 sec. / Update = 0.036 sec. Average CPU utilization of central server 84%

Table 2: Results of 2-Tier SAP Sales & Distribution (SD) Benchmark


6. Scaling of Throughput with Size of RHEL 5 Guest This section demonstrates the scaling of throughput with the size of a large para-virtualized RHEL5 guest.

Figure 8: Scaling of Virtualization Performance

Guest Size # SAP Application Server Instances

24 vCPUs 16

12 vCPUs 10

6 vCPUs 6

Table 3: Number of SAP Instances for different Guest Sizes

Figure 8 shows how RHEL5 continues to scale even for a very large guest running an CPU & memory intensive ERP workload.


7. References

1. Performance & Salability of Virtualized SAP® Servers on Red Hat® Enterprise Linux® 5 at the 2008 SAP Linux Virtualization Certification Workshop using the SAP LinuxLab Certification Suite (SLCS) - Red Hat White Paper, March 2008.

2. SAP® SD Benchmark using DB2® and Red Hat® Enterprise Linux® 5 on IBM System x3850 M2 - Red Hat and IBM White Paper, November 2008.

3. SAP Sales and Distribution (SD) Benchmark http://www.sap.com/solutions/benchmark/sd.epx

4. SAP SD Standard Application Benchmark - Published Results, Two-Tier Internet Configuration http://www.sap.com/solutions/benchmark/sd2tier.epx


Appendix A: Certification of this Benchmark by SAP AG


Appendix B: Other SAP SD Benchmarks Referenced in Figure 3 Virtualization Technology

System Summary

SAP SD Users System Specification SAP

Cert. #

VMware Fujitsu - Windows – SQL Server

250

Windows Server 2003 Enterprise Edition on VMware ESX Server 3.0.2 (using 2 virtual CPUs) and SQL Server 2005 with SAP ECC 6.0 running on Fujitsu Siemens Computers PRIMERGY Model TX600 S3 | RX600 S3, 4 Processors / 8 Cores / 16 Threads, Dual-Core Intel Xeon Processor 7040, 3 Ghz, 16 KB L1 cache per core, 2 MB L2 cache per core. 24 GB RAM.

2007060

VMware Dell - Windows – SQL Server

350

Windows Server 2003 Enterprise Edition on VMWare ESX Server 3.0.1 (using 2 virtual CPUs) and SQL Server 2005 with SAP ECC 6.0 running on Dell PowerEdge 6950, 4 Processors / 8 Cores / 8 Threads, AMD Opteron Processor Model 8220SE, 2.8 Ghz, 128 KB L1 cache and 1 MB L2 cache per core. 32 GB RAM.

2007029

VMware Sun - Windows – SQL Server

380

Windows Server 2003 Enterprise Edition on VMware ESX Server 3.0.1 (using 2 virtual CPUs) and SQL Server 2005 with SAP ECC 6.0 running on Sun Fire Model X2200 M2, 2 Processors / 4 Cores / 4 Threads, AMD Opteron processor Model 2218, 2.6 Ghz, 128 KB L1 cache and 1 MB L2 cache per core. 32 GB RAM.

2007067

VMware HP - Windows – SQL Server

402

Windows Server 2003 Enterprise Edition on VMWare ESX Server 3.0.1 (using 2 virtual CPUs) and SQL Server 2005 with SAP ECC 6.0 running on HP ProLiant BL460c, 2 Processors / 8 Cores / 8 Threads, Quad-Core Intel Xeon Processor X5355, 2.66 Ghz, 64 KB L1 cache per core and 4 MB L2 cache per 2 cores. 32 GB RAM.

2007035


420

Windows Server 2003 Enterprise Edition on VMware ESX Server 3.0.1 (using 2 virtual CPUs and SQL Server 2005 with SAP ECC 6.0 running on Fujitsu Siemens Computers PRIMERGY Model TX300 S3 | RX300 S3, 2 Processors / 8 Cores / 8 Threads, Quad-Core Intel Xeon Processor X5355, 2.66 Ghz, 64 KB L1 cache per core and 4 MB L2 cache per 2 cores. 32 GB RAM.

2007045

VMware Dell - Windows – SQL Server

421

Windows Server 2003 Enterprise Edition on VMware ESX Server 3.0.1 (using 2 virtual CPUs and SQL Server 2005 with SAP ECC 6.0 running on Dell PowerEdge 2900, 2 Processors / 8 Cores / 8 Threads, Quad-Core Intel Xeon Processor X5355, 2.66 Ghz, 64 KB L1 cache per core and 4 MB L2 cache per 2 cores. 32 GB RAM.

2007048

VMware Fujitsu - SuSE – MaxDB

430

SuSE Linux Enterprise Server 10 on VMware ESX Server 3.0.2 (using 2 virtual CPUs and MaxDB 7.7 with SAP ECC 6.0 running on Fujitsu Siemens Computers PRIMERGY Model TX300 S4 | RX300 S4, 2 Processors / 8 Cores / 8 Threads, Quad-Core Intel Xeon Processor X5355, 2.66 Ghz, 64 KB L1 cache per core and 4 MB L2 cache per 2 cores. 32 GB RAM.

2007070

VMware IBM - Windows - DB2

445

Windows Server 2003 Enterprise Edition on VMware ESX Server 3.0.1 (using 2 virtual CPUs and DB2 9 with SAP ECC 6.0 running on IBM System x3755, 2 Processors / 4 Cores / 4 Threads, AMD Opteron Processor Model 8220SE, 2.8 Ghz, 128 KB L1 cache and 1 MB L2 cache per core.

2007046


450

Windows Server 2003 Enterprise Edition on VMware ESX Server 3.0.2 (using 2 virtual CPUs) and SQL Server 2005 with SAP ECC 6.0 running on Fujitsu Siemens Computers PRIMERGY Model TX300 S4 | RX300 S4, 2 Processors / 8 Cores / 8 Threads, Quad-Core Intel Xeon Processor X5355, 2.66 Ghz, 64 KB L1 cache per core and 4 MB L2 cache per 2 cores. 16 GB RAM.

2007071


470

Windows Server 2003 Enterprise Edition on VMware ESX Server 3.0.2 (using 2 virtual CPUs) and SQL Server 2005 with SAP ECC 6.0 running on Fujitsu Siemens Computers PRIMERGY Model RX600 S4, 4 Processors / 16 Cores / 16 Threads, Quad-Core Intel Xeon Processor X7350, 2.93 Ghz, 64 KB L1 cache per core and 4 MB L2 cache per 2 cores. 32 GB RAM.

2007074



490

Windows Server 2003 Enterprise Edition on VMware ESX Server 3.5 (using 2 virtual CPUs) and SQL Server 2005 with SAP ECC 6.0 running on Fujitsu Siemens Computers PRIMERGY Model BX630 S2, 4 Processors / 8 Cores / 8 Threads, Dual-Core AMD Opteron Processor 8224 SE, 3.2 Ghz, 128 KB L1 cache and 1 MB L2 cache per core. 64 GB RAM.

2008008


490

Windows Server 2003 Enterprise Edition on VMware ESX Server 3.0.2 (using 2 virtual CPUs) and DB2 9.5 with SAP ECC 6.0 running on IBM System x Model x3850 M2, 2 Processors / 8 Cores / 8 Threads, Quad-Core Intel Xeon Processor X7350, 2.93 Ghz, 64 KB L1 cache per core and 4 MB L2 cache per 2 cores. 32 GB RAM.

2008005

Hyper-V Dell - Windows – SQL Server

501

Windows Server 2003 Enterprise Edition on Windows 2008 Hyper-V (using 2 virtual CPUs) and SQL Server 2005 with SAP ECC 6.0 running on Dell PowerEdge Model R900, 4 Processors / 16 Cores / 16 Threads, Quad-Core Intel Xeon Processor X7350, 2.93 Ghz, 64 KB L1 cache per core and 4 MB L2 cache per 2 cores. 90 GB RAM.

2008055

VMware HP - Windows – SQL Server

516

Windows Server 2003 Enterprise Edition on VMware ESX Server 3.5 (using 2 virtual CPUs) and SQL Server 2005 with SAP ECC 6.0 running on HP ProLiant DL580 G5, 4 Processors / 16 Cores / 16 Threads, Quad-Core Intel Xeon Processor X7350, 2.93 Ghz, 64 KB L1 cache per core and 4 MB L2 cache per 2 cores. 64 GB RAM.

2008007


545

Windows Server 2003 Enterprise Edition on VMware ESX Server 3.5 (using 2 virtual CPUs and DB2 9.5 with SAP ECC 6.0 running on IBM System x3850 M2, 4 Processors / 16 Cores / 16 Threads, Quad-Core Intel Xeon Processor X7350, 2.93 Ghz, 64 KB L1 cache per core and 4 MB L2 cache per 2 cores. 64 GB RAM.

2008044

VMware Fujitsu - SuSE – MaxDB

550

SuSE Linux Enterprise Server 10 on VMware ESX Server 3.5 (using 2 virtual CPUs) and MaxDB 7.7 with SAP ECC 6.0 running on Fujitsu Siemens Computers PRIMERGY Model TX300 S4 | RX300 S4, 2 Processors / 8 Cores / 8 Threads, Quad-Core Intel Xeon Processor X5460, 3.16 Ghz, 64 KB L1 cache per core and 6 MB L2 cache per 2 cores. 32 GB RAM. 32 GB RAM.

2008009

Red Hat Enterprise

Linux 5 Xen

IBM – Red Hat Enterprise Linux - DB2

4,400

Red Hat Enterprise Linux 5.2 (Para-Virtualized guest with 24 vCPUs) and DB2 9.5 with SAP ECC 6.0 running on IBM System x3850 M2, 4 Processors / 24 Cores / 24 Threads, Intel Xeon Processor MP X7460, 2.66 Ghz, 64 KB L1 cache per core and 3 MB L2 cache per 2 cores, 16 MB L3 cache per processor. 64 GB RAM.

2008077

Table 4: Certified SAP SD Benchmarks run in Virtual Servers


Appendix C: Database Tuning One of the database tuning activities in this benchmark was to identify transaction-intensive tables. These tables were separated from the predefined SAP tablespace and placed into DMS raw tablespaces. In addition to the performance gain of using raw device containers, the tables benefited from having their own buffer pool which could be finely tuned to improve buffer hit rates. Basically, these transaction- intensive tables can be classified into four categories:

VB tables (including VBMOD, VBHDR, and VBDATA), Insert-only tables, Volatile tables, and Mixed tables.

VB tables are the most transaction-intensive tables for SAP SD Benchmark applications. The VBDATA, VBHDR and VBMOD tables were separated into tablespaces with their own buffer pools. The tablespace for the VBDATA table was created using 32KB pages since VBDATA has a VARCHAR field of 31000 bytes. Insert-only tables are tables that have only insert transactions and few or no reads on the inserted data. Because of this characteristic, the buffer pool for these tables was small, thus freeing up more memory for other buffer pools that could benefit from higher cache hit rates. The tablespace for insert-only tables was created using 16KB pages. Volatile tables are tables where inserts and deletes are performed during the course of the application, so the sizes of the tables fluctuate greatly during execution. The contents of these tables can vary from empty to very large at run time. The volatility in size of this type of table makes reliance on the statistics collected by RUNSTATS inaccurate. To prevent this, the tables are declared VOLATILE using the ALTER TABLE statement. With the table declared volatile, the optimizer will always prefer to use an index scan rather than a table scan. Finally, mixed tables are those tables that have a mixture of transactions. These include inserts, deletes, and selects.


Database Parameters The following table lists the database parameters that have the most impact on the performance of a SAP database.

DBHEAP = 100000 Dbheap must be larger than LOGBUFSZ. We used the database system monitor to track the highest amount of memory that was used for the database heap.

LOGBUFSZ = 1024 This is larger than the default size of 128 pages.

LOCKLIST = 10000 LOCKLIST was set to the smallest size which avoided lock escalations.

CHNGPGS_THRESH = 60 For an update-heavy transaction workload, we needed to make sure that there were enough clean pages in the buffer pool by setting the parameter to be lower than the default value.

NUM_IOCLEANERS = AUTOMATICNUM_IOSERVERS = AUTOMATIC

DB2 has been smart enough to self tune the num_iocleaners and num_ioservers. In SAP SD benchmark, the number of IO cleaners is more important than IO servers.

SAP SD Benchmark using DB2 running Red Hat Enterprise ... · PDF fileSAP® SD Benchmark...

Documents

Transcript of SAP SD Benchmark using DB2 running Red Hat Enterprise ... · PDF fileSAP® SD Benchmark...