White Paper Template Updated August 2002€¦ · Web viewOracle11iApps Version 11.5.8. Database...

Sizing and Capacity Analysis of Oracle E-

Business Suite running on Dell Servers

EMEA Application Solution Centre (ASC)

Dell White PaperBy John Page

March 2004

ContentsIntroduction................................................................................................................................. 3Executive Summary.................................................................................................................... 5Test Infrastructure....................................................................................................................... 8

Load Generation Hardware..................................................................................................8Application Layer.................................................................................................................. 8Database Servers.................................................................................................................. 8Shared Storage..................................................................................................................... 8Networking Equipment.........................................................................................................9Load Generation Software...................................................................................................9Application Software............................................................................................................9Database Software................................................................................................................9Test Data................................................................................................................................ 9

Hardware Layout....................................................................................................................... 10Workload Characteristics.........................................................................................................11Data Collection and Analysis...................................................................................................14Results....................................................................................................................................... 16

Cycle 1: One PowerEdge 2650 running 11iApps and 9i Database.................................17Cycle 2: One PowerEdge 2650 in Apps Layer, One PowerEdge 2650 in DB Layer.......18Cycle 3: Two PowerEdge 2650s in Apps Layer, One PowerEdge 2650 in DB Layer.....20Cycle 4: 3xPE2650s in App Layer, 1xPE6650 (8G) in DB Layer......................................21Cycle 5: 5xPE2650s in App Layer, 1xPE6650 (16G) in DB Layer....................................22Cycle 6: 10 x PowerEdge 2650s in App Layer, 2 x PowerEdge 6650 (16G) in DB Layer.............................................................................................................................................. 23Cycle 7: 15xPE2650s in App Layer, 3xPE6650(16G) in DB Layer...................................24

Conclusions................................................................................................................................. 27

March 2004 Page 2 Dell Enterprise Product Group

Section 1Introduction

Almost all businesses of any size depend to a greater or lesser extent on their IT infrastructure. One of the key demands placed by the business on this infrastructure is to scale easily as the business grows, so that it can handle increasing user and transaction volumes. To support this requirement, Dell emphasizes the idea of “scaling out” an application. This means running an application on a number of relatively small servers, and adding extra servers in parallel as the business requirements grow. This is in contrast to a “scale-up” strategy, whereby customers move their applications to larger and faster machines to handle increasing levels of usage.Of course, the software application must also be capable of using multiple machines in parallel, if the full benefits of a scale-out strategy are to be realized. One example of an application that can scale out easily is the Oracle E-Business Suite 11i with Oracle Applications. As more users are added, extra servers can be added as required.The applications that comprise Oracle E-Business Suite 11i use the Oracle9i™ database for data storage. As well as scaling out the application layer, it must also be possible to scale out the database layer. Oracle9i Database is capable of scaling out through Oracle’s Real Application Clusters (RAC) technology. An Oracle RAC cluster can easily scale out if extra servers are added to the cluster. This means that extra users can be accommodated without having to move everything to larger and more powerful servers when the limits of the existing servers are reached.To support this scale-out strategy based on Dell servers and Oracle software, Dell and Oracle undertook a joint project to find out how many users could be supported on different hardware configurations. The key requirement of this project, from Dell’s point of view, was to produce data that would demonstrate to customers the value of the scale-out strategy. The project was hosted at Dell’s Application Solution Centre in Limerick, Ireland. Oracle E-Business Suite 11i Apps and Oracle9i RAC were installed on Dell™ PowerEdge™ 2650 and 6650 servers respectively, and a simulated user load was applied to Oracle11iApps. Each configuration was stressed to its maximum limit. The configuration was then “scaled out” with extra servers, stressed again to its maximum limit, and then scaled out again. This process continued for the duration of the project. See Section 5 for discussion of the workloads used in the tests.The results achieved, which are discussed at length in this white paper, will be used by Dell to illustrate how a mission-critical enterprise application such as E-Business Suite 11i Apps can run on Dell servers and storage and support thousands of users, and to demonstrate the advantages of choosing a scale-out strategy over a scale-up strategy.


In all cases the PowerEdge servers used in these tests were running Red Hat® Linux® Advanced Server 2.1 as the OS.


Section 2Executive Summary

The project was run in seven cycles, with a different configuration supporting a different number of users in each cycle. Each configuration consisted of three physical tiers or layers: an application layer; a database layer; and a shared storage layer. The application tier was made up of one or more PowerEdge 2650 servers for every cycle. The shared storage layer was hosted on a Dell™/EMC® CX600 in all cases. The database layer consisted of PowerEdge 2650 servers for the first three cycles, and PowerEdge 6650 servers for the last four cycles. Note that for the first cycle the database and application layers were hosted on one physical machine (a PowerEdge 2650). The results obtained are summarized below in Table 1.Note also that “Users” in Table 1 refers to concurrent users. For example, where the table states that 160 users are supported in Cycle 1, this refers to 160 concurrent users who were logged on and processing transactions for the entire duration of the test.

Cycle No. PowerEdge Server used in Database Layer

PowerEdge Server used in Mid-Tier Layer

DB memory Max Users 70% Max

1 1 x 2650 N/A 6 GB 160 112

2 1 x 2650 1 x 2650 6 GB 280 200

3 1 x 2650 2 x 2650 6 GB 560 400

4 1 x 6650 3 x 2650 8 GB 840 600

5 1 x 6650 5 x 2650 16 GB 1400 1000

6 2 x 6650 10 x 2650 16 GB 2800 2000

7 3 x 6650 15 x 2650 16 GB 3920 2750

Table 1: Overall Results of E-Business Suites 11i Apps Tests

In Table 1, the column “DB memory” refers to the amount of memory in the database server for a particular cycle. The application servers had 6GB of memory in all cases. Also, the “Max Users” column is the actual maximum number of users achieved in the cycle, whereas the “70% Max” column is a recommendation as to how many users a particular configuration might support in production, while still allowing some headroom for an increase in user numbers. The following discussion and graphs are in relation to the maximum user counts.


The key findings from this table are as follows: A single PowerEdge 2650 server running both E-Business Suite

11i and Oracle9i Database supported a maximum of 160 users during the test.

A single PowerEdge 2650 server running E-Business Suite 11i Apps supported up to 280 users when the database was running on another machine.

A single PowerEdge 2650 server running Oracle9i Database supported a total of two application servers with 280 users each, giving a maximum of 560 users for a configuration that uses a PowerEdge 2650 with 6GB of memory to run the database software.

By switching the database to a PowerEdge 6650 server with 8GB memory rather than a PowerEdge 2650 server, the maximum number of supported users rose to 840 (i.e., three connected app servers with 280 users each).

By increasing the memory in the PowerEdge 6650 server from 8GB to 16GB, a maximum of 1,400 users were supported (i.e., five connected app servers with 280 users each).

By adding a second PowerEdge 6650 server into a RAC cluster along with the first PowerEdge 6650 server, the maximum number of supported users doubled to 2,800. This is a scalability factor of 1.

By adding a third PowerEdge 6650 server to the RAC cluster, the maximum number of supported users increased to 3,920. This is a scalability factor of 0.80.

The results obtained in Table 1 emphatically support the scale-out strategy. The following two graphs illustrate this even more clearly. Figure 1 is a plot of user count versus the number of servers in the configuration.


Figure 1: User Count versus Number of Machines

Figure 1 clearly shows the maximum number of supported users increasing almost in a straight line as the number of servers was increased. This is exactly what we would expect from a system that is capable of scaling out.


Section 3Test Infrastructure

The following are the key components of the test infrastructure:

Load Generation HardwareBetween one and seven PowerEdge 2650 servers were used during the test to simulate the user load. Each server had two 2.8GHz Pentium® Xeon™ processors, five hard disks configured as RAID 1 and RAID 5, and 6GB of memory. These servers supported approximately 600 users each. The operating system was Windows® 2000 Advanced Server.

Application LayerBetween one and fifteen PowerEdge 2650 servers, supporting 280 users each (except for cycle 1) were used to apply the load. Each server had two 2.8GHz Pentium Xeon processors, five hard disks configured as RAID 1 and RAID 5, and 6GB of memory. The operating system was Red Hat Linux Advanced Server 2.1, with kernel level 2.4.9e25.

Database ServersCycles 1 to 3 consisted of between one and two PowerEdge 2650 servers with the same specs as the Application Layer servers. On cycles 4 to 7, we used between one and three PowerEdge 6650 servers with four 2.0GHz Pentium Xeon MP processors and five hard drive disks configured as RAID 1 and RAID 5. The PowerEdge 6650 in cycle 4 used 8GB of memory, while 16GB of memory was used in the remaining cycles.All of the servers that were running the database were installed with two QLA2340 Qlogic Host Bus Adapters (HBAs).The operating system in all cases was Red Hat Linux Advanced Server 2.1, with kernel level 2.4.9e25.

Shared Storage The shared storage was on a Dell/EMC CX600 with 2GB of cache per storage processor. The Oracle data was stored on a 70GB RAID 10 volume. The database servers were connected to the SAN through a pair of 16-port EMC fabric switches.


Networking EquipmentAll servers (load generators, application layer servers, database layer servers) were networked together using a Dell PowerConnect 5224 switch. One of the two embedded Broadcom NICs was used to connect each server to the network. The database servers had a separate private interconnect for the cluster, which was through a separate Dell PowerConnect 5212 switch.

Load Generation SoftwareMercury Interactive Loadrunner was used to simulate the required number of concurrent users for each cycle. The Loadrunner scripts were specifically created by Oracle for this project.

Application SoftwareOracle11iApps Version 11.5.8

Database SoftwareOracle9i Release 2 (9.2.0.3)

Test DataA sample database of Oracle E-Business Suite 11i application data, called the Vision database, was pre-loaded onto the Oracle9i database in advance of the test. The user scripts depended on this data in order to run correctly.


Section 4Hardware Layout

The hardware configuration is shown below in Figure 2.

Figure 2: Hardware Configuration for Oracle Tests

The shared storage layer was constant throughout the test. The load generation layer, application layer and database layer were all added to and scaled out with each succeeding test cycle.


Section 5Workload Characteristics

The results obtained in this project were required by Oracle for engineering sizing purposes. To support this requirement, Oracle generated test scripts which simulated a very heavy and realistic user workload. In this way Oracle worked to ensure that the results could be applied with confidence to real-world situations. The workload consisted of a set of scripts that simulated Oracle Applications users. These scripts were specifically developed for this project. They were intended to be as realistic as possible in terms of representing the activity of a typical Oracle Apps user.The workload covered five core modules from the Financials and Supply Chain Management (SCM) product suites:

Accounts Receivable (AR) Fixed Assets (FA) Inventory (INV) Order Entry (OE) Purchasing (PO)

The workload also included Pricing (QP) transactions that provided cross-functional testing of the Order Entry (OE) and Inventory (INV) modules.The workload mix consisted of 22 business transactions. This was made up of 16 OLTP transactions and 6 transactions that submitted concurrent requests. These are described fully in Table 2.The sample Vision database was populated with thousands of rows of seeded data, totaling about 50GB of data. This database was loaded from tape onto the Oracle9i Database.The scripts represented the activity of 40 different users. Each user executed a transaction a particular number of times to produce an overall total number of transactions. This is also explained in Table 2. The columns of this table are as follows:Base User Count: The number of Oracle Apps users running this transactionIterations Per User Per Hour: The number of times a single user executes this transactionBusiness transaction Total: The Base User Count multiplied by Iterations per user.Note that the user counts in Table 1 are always divisible by 40. In other words, as the load being applied to the system was increased, users were added to the test in groups of 40. Because each group of


40 users had the profile described in Table 2, the overall characteristic of the workload remained constant regardless of the number of users being applied. In other words, the same ratio of AR, FA, INV, OE, PO and QP transactions were being applied regardless of the total number of users.

Transaction Base User Count

Iterations per user per hour

Transaction Total

Accounts Receivable (AR)

AR Enter Customer 2 10 20

AR Enter invoice 3 10 30

AR Enter Inv Credit memo 1 11 11

AR Enter Invoice Adjustment 1 9 9

AR Enter Receipt 1 10 10

AR AR_To_GL Transfer Request 1 4 4

AR Print invoice Submittal 1 4 4

AR Print Statement Submittal 1 4 4

AR Totals 11 62 92

Fixed Assets (FA)

FA Assets Inquiry 4 10 40

FA Totals 4 10 40

Inventory (INV)

INV Create an item 4 12 48

INV View an Item 3 11 33

INV Totals 7 23 81

Order Entry (OE)

OE Insert an Order 3 14 42

OE View an Order 2 13 26

OE Totals 5 27 68

Purchase Orders (PO)

PO Create a Supplier 1 10 10

PO Create a Purchase Order 2 12 24

PO View a Purchase Order 2 10 20

PO Create a Requisition 2 9 18

PO View a Requisition 2 9 18

PO Totals 9 50 90

Pricing (QP)

QP Price List Setup 1 11 11

QP Adjust Price List 1 9 9


QP Add Items to Price List 1 10 10

QP Copy a Price List 1 10 10

QP Totals 4 40 40

Atomic Group Total 40 212 411

Table 2: Workload Details


Section 6Data Collection and Analysis

Each test cycle was conducted by applying a user load to the configuration under test, measuring the results, increasing the user load, measuring again, and continuing in this fashion until the hardware was demonstrably unable to handle the user load. In this way, the maximum number of concurrent users was established for each hardware configuration.Each run included a ramp-up phase, a settle phase, a steady-state phase, and a ramp down phase, as shown in Figure 3. Measurements were taken only during the steady-state phase.

Figure 3: Workload Characteristics

Data was gathered during the steady state phase using the Linux sar command, and also using the Oracle statspack utility. Mercury Interactive Loadrunner also gathered data during each test; in particular:

The overall average response time 90th percentile response times Total number of transactions completed Verified that the run completed with no failures


The 90th percentile response time is the time by which 90% of all transactions had completed. If, out of ten transactions, nine completed within one second, and the tenth took eight seconds, the 90th percentile response time would still be one second.At the end of each run, the data was analyzed and the workload was deemed to have passed or failed. In other words, the hardware on which the workload was running was deemed either to be able to support the workload, or not. Before a workload was deemed to have passed, it had to meet the following criteria:

Overall 90th percentile response times did not exceed 2 seconds Overall average response time was less than the 90th percentile

response time. This was to make sure that the values of the excluded 10% of transactions were not too large.

All business transactions completed successfully.


Section 7Results

A more detailed presentation of the overall results is shown below in Table 3. Table 3 includes transaction numbers and recorded response times. Note that the first row, the Single Node Reference result, is a reading based on an unstressed system, and is intended as a point of comparison with the other test cycles.

Topology Results

Cycle PowerEdge server in DB layer

PowerEdge server in App layer

Max users

TransactionsPer hour

Avg Time 90th

Percentile

N/A 1 x 2650 None 40 280 0.47 0.52

1 1 x 2650 None 160 1138 0.58 0.73

2 1 x 2650 1 x 2650 280 2024 0.50 0.63

3 1 x 2650 2 x 2650 560 3790 0.61 0.84

4 1 x 6650 3 x 2650 840 5268 0.45 0.51

5 1 x 6650 5 x 2650 1400 9778 0.47 0.56

6 2 x 6650 10 x 2650 2800 19168 0.56 0.69

7 3 x 6650 15 x 2650 3920 26910 0.66 0.83

Table 3: Overall Results including Transactions per hour and Response Times

It can be seen for all cycles that the average response times and the 90th percentile response times are comparable with the response times measured from a 40 user workload. For example, it can be seen that Cycle 7 processed almost a hundred times as many transactions as the reference workload, yet the response times were greater by a factor of just 40 percent, and were well within the acceptable parameters that defined a successful test.The following sections go into more detail on the results obtained for each of the seven test cycles. Measurements are shown in all cases for both passed and failed workloads. Remember, a workload was deemed to have failed if the 90th percentile response time exceeded two seconds, or if the average response time exceeded the 90th percentile response time.


Cycle 1: One PowerEdge 2650 Server running E-Business Suite 11i Apps and Oracle9i Database.

Table 4 shows the key performance metrics from the server for this test. Three workloads were run for this configuration: a forty-user run, a 160 user run, and a 200 user run. Based on the Mercury response time metrics, the 200 user run failed, while the 40 and 160 user runs were successful.

Table 4: Results for Cycle 1

Looking at Table 4, it is clear that memory became a bottleneck between the 160 and 200 user runs. There was no noticeable increase in the utilization of the other key subsystems.The Oracle initialization parameters used for this run are shown below in Table 5. The total System Global Area (SGA) is 1165 MB.

Parameter Value

PROCESSES 800

SESSIONS 1600

DB_BLOCK_BUFFERS 70000 (547 MB)

SHARED_POOL_SIZE 500 MB

SHARED_POOL_RESERVED_SIZE 50 MB

PGA_AGGREGATE_TARGET 1000 MB

UNDO_RETENTION 5400

Table 5: Oracle Initialization Parameters for Cycle 1


CPU Memory Paging Swap Disk

UserCount

%userCPU

%systemCPU

SwapMax

Usage (GB)

pgin/s pgout/s Pswpin/s

pswpout/s tps Blks/s Passed

40 5.17 0.44 0 14.60 89.30 0.00 0.00 12.86 141.90 Yes

160 17.57 1.67 5.14 17.80 161.00 0.62 0.04 25.38 366.15 Yes

200 14.79 5.95 6.49 111.50 127.50 24.15 0.26 13.70 210.13 No

Cycle 2: One PowerEdge 2650 Server in Apps Layer, One PowerEdge 2650 Server in Database Layer

This cycle was of particular importance because it was used to establish the maximum number of Apps users that could be supported on a single PowerEdge 2650 server. This information was vital for establishing how many app servers were required at a minimum to support a certain number of users during this test, aside from any database considerations.This cycle was split into a number of sub-cycles, and covered a number of different configurations with various numbers of application servers. Regardless of the overall number of users, performance measurements were taken for one of the app layer servers, so that we could compare these against each other for successful and failed runs.The data from Cycle 2 is shown below in Table 6.

CPU Memory Paging Swap

Users per server

%user CPU

%system CPU

Swpused pgin/s pgout/s pswpin/s pswpout/s

Pass? Notes

160 6.00 0.52 0 0.00 22.10 0.00 0.00 Yes 800 user run 1 PowerEdge 6650 server (16GB) in DB layer and 5 PowerEdge 2650 servers in app layer

200 9.08 0.88 3.97 1.90 21.60 0.11 13.42 Yes 3000 user run 3 PowerEdge 6650 servers in DB layer and 15 PowerEdge 2650 servers in app layer

240 9.19 0.74 5.08 1.40 26.00 0.16 0.00 Yes 480 user run 1 PowerEdge 2650 server in DB layer and 2 PowerEdge 2650 servers in app layer

280 10.96 0.87 6.39 32.00 25.90 2.45 14.09 Yes 1400 user run 1 PowerEdge 6650 server (16GB) in DB layer and 5 PowerEdge 2650 servers in app layer

300 9.20 1.84 6.58 79.60 40.40 18.28 41.96 No 600 user run 1 PowerEdge 2650 server in DB layer and 2 PowerEdge 2650 servers in app layer

Table 6: App server performance measurements for Cycle 2.

The 300 user run failed. It is clear once more that memory was the bottleneck, judging by the increase in swapping and paging between


the 280 user run and the 300 user run. Based on this result, 280 users per app server were taken as the basis for all subsequent cycles.


Cycle 3: Two PowerEdge 2650 Servers in Apps Layer, One PowerEdge 2650 Server in DB Layer

Having established in the previous cycle that the maximum number of users per application server was 280 during the test, the purpose of the remaining test cycles was to determine the point at which the database servers reached maximum capacity. The results taken from the database tier are shown below in Table 7.


UserCount

%userCPU

%systemCPU

SwapMaxUsage (GB)

pgin/s pgout/s pswpin/s pswpout/s tps blks/s Passed

280 13.51 1.61 1.01 38.50 185.80 0.00 0.00 26.20 416.29 Yes

480 22.08 2.60 3.09 56.20 296.60 4.94 0.24 44.34 628.06 Yes

560 36.39 17.47 3.85 139.30 354.40 25.24 104.71 53.20 755.27 Yes

600 29.50 10.51 3.83 62.00 329.00 7.48 0.18 55.43 988.41 No

7201 42.33 16.33 5.56 280.0 393.0 52.52 172.45 52.74 860.95 No


The profile is different here than in the earlier cycles, in that we saw an improvement (i.e., a reduction) in paging and swapping between the 560 user run and the 600 user run. This is because the application tier was unable to support 600 users, and the database tier was receiving less traffic from the application tier because of this.The Oracle initialization parameters for this run are shown in Table 8. Total SGA is 2,126 MB.

Parameter Value

PROCESSES 800

SESSIONS 1600





UNDO_RETENTION 7200

1 This result was produced from a 3 application tier node configuration but is included in this section to demonstrate the maximum number of application tier nodes for a PowerEdge 2650 database tier.


Table 8: Oracle parameters for Cycle 3

Cycle 4: Three PowerEdge 2650 Servers in App Layer, One PowerEdge 6650 Server (8GB) in DB Layer

Measurements taken on the database tier for this cycle are shown in Table 9.


UserCount

%userCPU

%systemCPU

SwapMaxUsage (GB)

pgin/s pgout/s pswpin/s pswpout/s tps blks/s Passed

720 10.14 1.56 3.51 38.90 395.00 0.00 0.00 60.97 809.87 Yes

840 13.88 7.76 5.54 145.00 575.50 24.69 107.81 61.40 875.49 Yes

1120 11.41 10.95 6.4 70.74 240.73 9.54 0.09 41.25 483.35 No


One interesting point here is to compare the 720 user run in cycle 3, which failed, with the 720 user run in cycle 4, which passed. Overall paging and swapping, in particular pages in and swaps in, were greatly reduced. Clearly, the extra memory had an impact. The CPU utilization also came down by a factor of four, indicating that the overall solution had much more scope to scale out by adding additional app servers if we used a PowerEdge 6650 server at the database layer rather than a PowerEdge 2650 server.We can see from this table that the run for 1,120 users failed, based on the Loadrunner success criteria. As we saw in cycle 3, the paging and swapping situation actually improved between the successful run with the highest number of users (i.e., 840) and the failed run. Again, this was because the bottleneck was at the Application Layer, and traffic was not getting through to the database server.The Oracle parameters for this run are shown below in table 10. Total SGA was 2,693 MB.

Parameter Value

PROCESSES 1200

SESSIONS 2400






UNDO_RETENTION 10800

Table 10: Oracle parameters for Cycle 4.

Cycle 5: Five PowerEdge 2650 Servers in App Layer, One PowerEdge 6650 Server (16GB) in DB Layer

The memory in the PowerEdge 6650 server was doubled to 16GB for this test. Based on the improvement we saw between cycles 3 and 4, we expected to be able to load significantly more users again with this extra memory. Measurements taken on the database tier for this cycle are shown below in Table 11.


UserCount

%userCPU

%systemCPU

SwapMaxUsage (GB)

pgin/s pgout/s pswpin/s pswpout/s Tps blks/s Passed

800 13.14 1.99 0 6.10 460.7 0.00 0.00 63.70 886.13 Yes

1120 21.18 3.09 0 41.80 712.00 0.00 0.00 111.65

1470.04 Yes

1200 21.58 2.98 0 37.90 609.00 0.00 0.00 85.56 1249.90 Yes

1400 26.25 5.05 4.63 33.60 707.00 0.00 0.00 96.6 1438.9 Yes

1680 30.69 15.67 10.00 63.30 918.00 5.35 63.62 118.77

1938.41 No


Comparing the 800 user run on cycle 5 with the 840 user run on cycle 4, we see that the extra memory had a big impact. “Pages in” diminished significantly, while there was no swapping activity whatsoever.Fourteen hundred users ran successfully, while the run failed for 1,680 users. CPU usage increased significantly between these two runs, as did paging. Furthermore, we saw swapping activity only when 1,680 users were run. The size of the swap partition was increased from 8GB to 16GB for the 1,680 user test, but it made no difference.This was the final cycle before configuring the Oracle9i RAC software. The final result for users supported on a single-node database was 1,400 users.


The Oracle parameters for this run are shown in Table 12. Total SGA was 3,212MB.

Parameter Value

PROCESSES 2500

SESSIONS 5000







Cycle 6: Ten PowerEdge 2650 Servers in App Layer, Two PowerEdge 6650 Servers (16GB) in DB Layer

For this cycle, we introduced the Oracle9i RAC software, and added a second PowerEdge 6650 server with 16GB of memory to the database layer to form a 2-node RAC cluster. The key measurements from the database layer are shown below in Table 13.

CPU Paging Disk Interconnect

UserCount

Database Node

%userCPU

%systemCPU

pgin/s pgout/s tps blks/s rxbyt/s txbyt/s Passed

560 node1 2.69 0.50 235.00 128.00 32.85 884.99 0.24M 0.23M Yes

560 node2 2.65 0.46 231.00 113.00 18.20 648.42 0.23M 0.24M Yes

1680 node1 8.92 1.60 836.00 305.00 71.15 2446.85 1.23M 1.23M Yes

1680 node2 8.92 1.55 843.00 282.00 61.94 2660.45 1.23M 1.23M Yes

2800 node1 30.61 6.35 1540.00 691.00 180.98 9769.13 4.76M 2.45M Yes

2800 node2 22.70 3.32 1124.00 540.00 109.75 3946.37 2.67M 6.75M Yes


There was no swap activity during this test, so the column was removed from the table.


In theory, adding a second node into a RAC node should have allowed us to double the number of users that can run on the system. We can see clearly from Table 13 that this is what happened. The number of users was gradually increased from 560 up to 2,800, double the number that was supported on the single-node database configuration in cycle 5, and the tests ran successfully according to the Mercury Loadrunner success criteria. Referring back to Table 3, we can see that the response times did degrade slightly from cycle 5, but the times were still well within the acceptable range of 2 seconds.

The Oracle parameters for this run are shown in Table 14. Total SGA was 3,372 MB.

Parameter Value

PROCESSES 2500

SESSIONS 5000







Cycle 7: Fifteen PowerEdge 2650 Servers in App Layer, Three PowerEdge 6650 Servers (16GB) in DB Layer

For this cycle, we introduced a third node to the RAC cluster, also a PowerEdge 6650 server with 16GB memory. The results from this cycle are shown below in Table 15.


CPU Paging Disk Interconnect

UserCount

Database Node

%userCPU

%systemCPU

Pgin/s pgout/s tps blks/s rxbyt/s txbyt/s Passed

3000 node1 32.51 6.39 1059 538 151.56 10045.55 3.05M 4.40M Yes

3000 node2 25.02 3.20 542 401 77.85 2191.40 4.59M 2.77M Yes

3000 node3 24.21 3.29 578 388 76.98 2244.67 2.95M 4.48M Yes

3360 node1 32.18 8.76 1478 622 172.05 9803.94 3.55M 4.91M Yes

3360 node2 21.64 3.42 599 458 92.86 2590.13 5.30M 3.22M Yes

3360 node3 17.36 2.93 494 382 74.80 2043.48 3.23M 6.30M Yes

3920 node1 40.38 10.73 2542 675 209.18 12823.65 5.33M 6.08M Yes

3920 node2 30.87 6.67 1052 543 125.12 3860.32 7.76M 5.41M Yes

3920 node3 29.59 6.49 1067 775 111.69 3814.56 4.45M 8.11M Yes

4000 node1 45.61 10.50 2172 703 185.36 11371.28 4.76M 7.96M No

4000 node2 33.10 5.64 891 531 115.33 3355.82 6.25M 6.55M No

4000 node3 31.12 5.42 854 505 107.01 3203.43 5.17M 7.43M No

4200 node1 43.94 14.75 1881 658 185.47 10543.41 5.42M 6.69M No

4200 node2 34.65 7.89 1221 517 124.55 4103.75 6.28M 10.33M No

4200 node3 34.11 9.16 1170 502 115.57 3833.97 4.97M 8.91M No


There was no swap activity during this test, so the column was removed from the table.We can see from Table 15 that 3,920 was the largest number of users where the 90th percentile response times were within 2 seconds. The table does not reveal any great differences in performance across the 3,920, 4,000 and 4,200 user runs. Paging and disk activity levels were comparable across all three runs, while CPU utilization was seen to increase significantly. The 4,000 and 4,200 user tests failed because not all users completed successfully, indicating that the system was unable to handle the load being applied.The Oracle parameters for this run are shown in Table 16. Total SGA was 3,372 MB.


Parameter Value

PROCESSES 2500

SESSIONS 5000






Table 16: Oracle parameters for Cycle


Section 8Conclusions

The key conclusions are as follows: The results lend great credibility to the scale-out strategy. We

saw that, once a baseline of 280 users per application server was established, we were able to support increasing multiples of this number simply by adding more servers.

Seven different configurations were tested and validated as being able to support user numbers which ranged from 160 to 3,920.

The workload used to generate these results was a realistic, real-live representation of the activity of typical Oracle11iApps users. The workload was not skewed to improve the results, which can be taken as a very reliable guide to the maximum user counts that might be achieved in production using the same underlying application.

The user counts reported for all cycles are maximum user counts. During the tests, cycles tended to fail when the user numbers were increased slightly above these maximums. Therefore, if a customer needed to support precisely 560 users, our tests indicate that the configuration tested in Cycle 3 can support this. However, this will allow very little headroom for going above this user count. Depending on the situation, Dell recommends using the “70%” column in Table 1 as the number of users supported. This will help guarantee that a particular configuration will be able to support transient increases in load, without needing to purchase extra hardware.

THIS WHITE PAPER IS FOR INFORMATIONAL PURPOSES ONLY, AND MAY CONTAIN TYPOGRAPHICAL ERRORS AND TECHNICAL INACCURACIES. THE CONTENT IS PROVIDED AS IS, WITHOUT EXPRESS OR IMPLIED WARRANTIES OF ANY KIND.

Dell, the Dell logo, PowerEdge and PowerConnect are trademarks of Dell Inc. EMC is a registered trademark of EMC Corporation. Oracle is a registered trademark, and Oracle 9i is a trademark of Oracle Corporation. Red Hat is a registered trademark of Red Hat Inc. Linux is a registered trademark of Linus Torvalds. Other trademarks and trade names may be used in this document to refer to either the entities claiming the marks and names or their products. Dell disclaims proprietary interest in the marks and names of others.

©Copyright 2004 Dell Inc. All rights reserved. Reproduction in any manner whatsoever without the express written permission of Dell Inc. is strictly forbidden. For more information, contact Dell.

Information in this document is subject to change without notice.


Date post:	20-Jul-2020
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

White Paper Template Updated August 2002€¦ · Web viewOracle11iApps Version 11.5.8. Database...

Documents