oracle tune improvement

8/16/2019 ORacle tune improvement

1/80

Oracle WebLogic Server 11 g :Monitor and TunePerformanceActivity Guide

D61529GC20Edition 2.0

January 2011D69372


2/80


3/80

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.

Oracle WebLogic Server 11g: Monitor and Tune Performance Table of Contentsi

Table of Contents

Practices for Lesson 1 .....................................................................................................................................1-1 Overview of Practices for Lesson 1 ................................................................................................................1-2 Practice 1-1: Getting Familiar with the Lab Environment ...............................................................................1-3

Practices for Lesson 2 .....................................................................................................................................2-1

Overview of Practices for Lesson 2 ................................................................................................................2-2

Practice 2-1: Setting Up and Using The Grinder for Load Testing .................................................................2-3

Practices for Lesson 3 .....................................................................................................................................3-1 Overview of Practices for Lesson 3 ................................................................................................................3-2 Practice 3-1: Monitoring and Tuning Oracle JRockit JVM ..............................................................................3-3 Practice 3-2: Analyzing Recorded JRockit Flight Recorder Sessions ............................................................3-7

Practices for Lesson 4 .....................................................................................................................................4-1 Overview of Practices for Lesson 4 ................................................................................................................4-2 Practice 4-1: Monitoring and Tuning HotSpot JVM ........................................................................................4-3

Practices for Lesson 5 .....................................................................................................................................5-1 Overview of Practices for Lesson 5 ................................................................................................................5-2

Practice 5-1: Using Work Managers ...............................................................................................................5-3 Practices for Lesson 6 .....................................................................................................................................6-1

Overview of Practices for Lesson 6 ................................................................................................................6-2

Practices for Lesson 7 .....................................................................................................................................7-1 Practices for Lesson 7 ....................................................................................................................................7-2 Overview of Practice 7-1: Tuning JSP ............................................................................................................7-3

Practices for Lesson 8 .....................................................................................................................................8-1 Overview of Practices for Lesson 8 ................................................................................................................8-2 Practice 8-1: Monitoring and Tuning JDBC ....................................................................................................8-3

Practices for Lesson 9 .....................................................................................................................................9-1 Overview of Practices for Lesson 9 ................................................................................................................9-2 Practice 9-1: Tuning EJB ...............................................................................................................................9-3

Practices for Lesson 10 ...................................................................................................................................10-1 Overview of Practices for Lesson 10 ..............................................................................................................10-2 Practice 10-1: Tuning JMS .............................................................................................................................10-3

Practices for Lesson 11 ...................................................................................................................................11-1 Overview of Practices for Lesson 11 ..............................................................................................................11-2 Practice 11-1: Tuning Session Persistence ....................................................................................................11-3

Practices for Lesson 12 ...................................................................................................................................12-1 Overview of Practices for Lesson 12 ..............................................................................................................12-2


4/80


5/80


6/80


Practices for Lesson 1Chapter 1 - Page 2

Overview of Practices for Lesson 1

Practices OverviewLab FamiliarityThe lab uses a Linux machine. The instructor will give you the operating system usernames andpassword to be used by your team.The key tasks you perform in this practice are:

• Logging in to your machine• Locating your lab file location• Starting and stopping Oracle 11 g Database and its listener

These exercises use the following variable names to refer to commonly used locations on yourfile system:

Variable Path

Database(ORACLE_HOME)

/u01/app/oracle/Database/11.2.0/orcl

/u01/app/oracle/Middleware/11.1.1

/wlserver_10.3

/home/oracle/wls11g_tune

/labs/lab XX_YY ,where XX_YY is the current practice number (for example,lab01_01)

/u01/app/work

/domains/MedRecDomain/ptcourse/…

/u01/app/opensource/grinder-3.2


7/80



Practice 1-1: Getting Familiar with the Lab Environment1. Make sure that your machine is powered on. Log in as the oracle user with the password

provided by your instructor.2. After you have logged in to the desktop, you may want to get familiar with the desktop

interface.a. You will notice four palettes at the bottom right of your remote machine. Each of them

represents a desktop on the remote machine.b. For your convenience, you can invoke different applications to full screen on each

desktop appropriately.1) You can invoke a gnome-terminal on the first desktop by using the Terminal icon

on the desktop.2) Invoke a Web browser on the second desktop by using the icon on the menu bar.

3) Invoke a file browser in the third desktop by using Applications > System Tools >File Browser.

3. Oracle Database 11 g and Oracle WebLogic Server 11 g are already installed andconfigured in your machine. Using the File Browser, navigate through the installation andconfiguration directories.a. Using the File Browser, navigate the File System tree to the

/u01/app/oracle/Database/11.2.0/orcl folder. This folder is theORACLE_HOME folder for the database. The executables and main configurations fordatabase are in this folder.


8/80



b. Now navigate to /u01/app/oracle/Middleware/11.1.1 . This folder contains theinstalled binaries for the Oracle Fusion Middleware components.

4. Using the gnome-terminal session, perform the following steps to get familiar with thescripts that you will use in the practices.a. The wls11g_tune/bin folder contains the scripts and tools to start and stop the

database and the WebLogic server instances that you will use in the practices for thiscourse.

b. Navigate to the wls11g_tune/bin subfolder in your $HOME folder (/home/oracle) andlist the files in this folder:$> cd /home/oracle/wls11g_tune/bin$> ls

c. Execute the ps command to check whether the database is running. If it is not running,use the start_db.sh script to start the database.$> ps –ef | grep pmon

Note: If the preceding command does not return the ora_pmon_orcl row, you must startthe database using the start_db.sh script.

$> start_db.sh


9/80



Practices for Lesson 2Chapter 2


10/80




Practices OverviewThis practice was developed and tested using a machine with one CPU and 2 GB of RAM. Theresults shown and discussed may vary depending on the resources in the environment that youare using.


11/80


12/80


13/80


14/80



(agent): waiting for console signal5. Run the test case and record the performance metrics.

a. Return to The Grinder Console and access the Results tab.b. On the main toolbar, select Action > “Start processes.” Click OK if prompted to run the

agent’s default property file. (Also, if not already selected, select Action > StartCollecting on the toolbar.)

c. As the agent runs, the left pane displays the number of collected samples. You canview the statistics relating to the load test:

d. On the Results tab of The Grinder Console, locate the Successful Tests column.e. When most of the rows are within the range after about 3–5 minutes, click Stop

Collecting and, if necessary, select “Stop processes” on the task menu.f. Return to the gnome-terminal in which you initiated The Grinder agent, and verify that

the test script completed:11/5/09 2:36:04 PM (agent): finished

g. Record the following values found in the “Total row of results” table of the console:

Number ofSuccessful Tests

Number of Errors Mean ResponseTime (ms):

Mean TPS

h. Close The Grinder console (using File > Exit on the menu).6. Modify the server heap settings and perform the test again so that you can compare the

results.a. Stop the managed server by using the stop_mr1.sh script. Enter the username and

password when prompted.$> stop_mr1.sh


15/80



b. Within the same terminal, ensure that you use Sun as the JAVA_VENDOR, set thememory options, and start MedRecSvr1 using the following:$>export JAVA_VENDOR=Sun$> USER_MEM_ARGS="-Xms512m –Xmx512m –XX:MaxPermSize=256m"$> export USER_MEM_ARGS$> cd /u01/app/work/domains/MedRecDomain/bin/

$> ./startManagedWebLogic.sh MedRecSvr1 t3://localhost:7020c. Inspect the server’s output to verify that the new heap settings are in tune with the

USER_MEM_ARGS parameter.7. Repeat step 4 (Start The Grinder Console) and step 5 (Run the test case and record the

performance metrics). Re-enable data collection in The Grinder Console.a. Compare the performance (Mean Response Time and Mean TPS).

b. Stop the MedRecSvr1 and MedRecAdm servers by using the scripts.$> stop_mr1.sh$> stop_mradm.sh

This practice was developed and tested using a machine with one CPU and 4 GB of RAM. Theresults shown and discussed may vary depending on the resources in the environment that youare using.


16/80


17/80


18/80


19/80


20/80


21/80



d. On the Runtime page, click the Memory tab and note the Garbage Collection strategycurrently being used.

4. Run the stress test using The Grinder.a. Using a text editor, inspect the URL and Port values in The Grinder scripts

grinder.properties , and httpscript.py in$HOME/wls11g_tune/labs/lab03_01/grinder .

b. Set up The Grinder environment.$> source ./setEnv.sh

c. Run a stress test by invoking The Grinder by using the following command:java net.grinder.Grinder grinder.properties

Note: You are not using The Grinder Console because you are only simulating some loadon the server and not looking at the response time or throughput for now.


22/80


23/80


24/80


25/80


26/80



2) Increase the compaction ratio. (In several cases, increasing compaction will helpreduce fragmentation. The JFR shows that JRockit is compacting 128 MB eachGC. However, for this application, the allocation pattern is so mixed that this is notenough. Increasing the area would reduce the fragmentation, but for thisapplication, it would not be enough).

3) Reduce the compaction ratio. (Compaction is how JRockit can reducefragmentation on the heap. Reducing the ratio would have the effect of furtherincreasing fragmentation.)

f. Now analyze the results by using 3.JFR from the wls11g_tune/labs/JFR_RECORDINGS folder.


27/80


28/80






29/80


30/80


31/80


32/80



c. Access the Monitor tab and notice the graphs relating to CPU and memory (heap)usage.

5. Run a stress test by using The Grinder, and monitor the CPU and memory usage graphs inJava VisualVM.a. At the prompt, change the working directory to:

$HOME/wls11g_tune/labs/lab04_01/grinder $> cd $HOME/wls11g_tune/labs/lab04_01/grinder

b. Open The Grinder scripts grinder.properties , httpscript.py , andhttpscript_tests.py by using a text editor. Inspect the URL and Port values.

c. Set up The Grinder environment by using the setEnv.sh script.$> source ./setEnv.sh

d. Run a stress test by invoking The Grinder using the following command:java net.grinder.Grinder grinder.properties

Note: You are not using The Grinder Console because you are just simulating some load

on the server and not looking at the response time or throughput for now.$> java net.grinder.Grinder grinder.properties

e. You can also use Java VisualVM to visualize the CPU and memory usage. Noticethat the CPU usage is at near 100% at times, while the used heap space reaches100% most of the time. Also you may get occasional "Out of memory" errors in the PT


33/80


34/80


35/80


36/80


37/80


38/80


39/80


40/80


41/80


42/80


43/80



8. Assign the global Work Manager lowPriority to the BrowseMarketApp application.a. In the gnome-terminal window, navigate to

/home/oracle/wls11g_tune/labs/lab05-01/exercise/applications/BrowseMarketApp/WEB-INF directory.

b. Open the deployment descriptor, weblogic.xml , by using a text editor. Insert thefollowing line to reference the “ lowPriority ” Work Manager, and then save andclose the file:

lowPriority

c. In the Administration Console, click Lock & Edit in Change Center. Then navigate toptcourse > Deployments in the domain structure.

d. In Summary of Deployments, select the BrowseMarketApp check box and clickUpdate.

e. Accept the defaults and click Finish.f. Activate the changes in the Change Center.g. Open a Web browser and navigate to http://localhost:7003/BrowseMarketApp/.

Browse to make sure that the application is running.

9. Create and assign an application-level Work Manager named highPriority for theBrowseStoreApp application.a. In Admin Console Domain Structure, navigate to ptcourse > Deployments. Then click

the BrowseStoreApp link in the table.b. Navigate to Configuration > Workload and notice that there are no application-scoped

work managers.c. Click Lock & Edit in the Change Center. Then click New in the Application Scoped

Work Managers table.d. In the Create a New Work Manager Component wizard, enter highPriority as the

name and click Finish.

e. The Save Deployment Plan Assistant appears. In the Path field, enter/home/oracle/wls11g_tune/labs/lab05_01/exercise/applications/HP_Plan.xml . Then click OK. You will receive a message indicating deployment plan hasbeen created.

f. Now you can assign the previously created highFairShare class to highPriority work manager. Click highPriority link in Application Scoped Work Managers.

g. In the Settings for highPriority, select highFairShare as the Request Class. Alsoselect maxThreads as the Maximum Threads Constraint. Then click Save. A


44/80


45/80


46/80


47/80


48/80


49/80


50/80


51/80


52/80



b. Edit weblogic.xml with a text editor and disable page check seconds by changingthe value to -1 as shown. Save and close the file.

-1

c. Using the Administration Console, update the application.d. Open a Web browser and navigate to

http://localhost:7003/StockWatcherzApp/ .Browse to make sure that the application is running.

8. Run the stress test using The Grinder.a. Repeat step 3, but this time, run stressTest twice. This eliminates some initialization

from the results. Record the second run results in the “Performance statistics: page

check disabled” table.b. Review and compare the results collected in all the Performance statistics tables.


53/80


54/80


55/80


56/80


57/80



d. Click Connection Pool. Verify that the initial capacity is 5 and the maximum capacity is15 .

3. Run the stress test by using The Grinder.a. In the gnome-terminal, navigate to the ~/wls11g_tune/labs/lab08_01/grinder

folder and set up the environment variables for The Grinder.$> cd ~/wls11g_tune/labs/lab08_01/grinder$> source ./setEnv.sh

b. Run the stress test by using the following command:$> java net.grinder.Grinder grinder.properties

c. Watch the agent window while the threads start running. When The Grinder agent hasfinished running all threads, the DS_Test_Logs folder containing the files of stresstest is created in the /u01/app/work folder.

d. Open the out_.log file from the newly created directory and scroll down torecord the following results in the Performance statistics table (Connections in Pool:Initial = 5 and Maximum = 15).1) Mean Test Time (ms)

2) Total tests successfully executed3) Errors (if any)

4. Change the connection pool’s Initial and Maximum Capacity.a. Access the Administration Console for Medrec domain

(http://localhost:7020/console ).b. In the Change Center, click Lock & Edit. In Domain Structure, navigate to

MedRecDomain> Services >JDBC > Data Sources.c. Click MedRecGlobalDataSourceXA.d. Click Connection Pool. Change the number of physical connections in the pool to:

Parameter Value

Initial Capacity 15

Maximum Capacity 15

e. Click Save. Then click Activate Changes in the Change Center.5. Run the stress test again by using The Grinder, and record the new results in the

Performance statistics table (Connections in Pool: Initial = 15 and Maximum = 15).a. Stop MedRec Server 1 by using the stop_mr1.sh script or by keying CTRL + C in

the MedRec Server 1 window.$> stop_mr1.sh

b. Start MedRec Server 1 by using the start_mr1.sh script.$> start_mr1.sh

c. Repeat step 3 and record the new results in the Performance statistics table(Connections in Pool: Initial = 15 and Maximum = 15).

6. Change the statement cache size to 10 and enable Pinned-to-Thread .a. In Domain Structure, navigate to MedRecDomain > Services >JDBC > Data Sources.b. Click MedRecGlobalDataSourceXA.c. Click Connection Pool. Change the number of physical connections in the pool back to:


58/80



Property Value

Initial Capacity 5

Maximum Capacity 15

d. Verify the Statement Cache parameters:

Parameter Value

Statement Cache Type LRU

Size 10

e. Click Save.f. Click Advanced to change advanced parameters, and select the Pinned-to-Thread

check box.Note: The Pinned-to-Thread option can improve performance by enabling executethreads to keep a pooled database connection even after the application closes thelogical connection.

g. Click Save.

7. Run the stress test again by using The Grinder, and record the new results in thePerformance statistics table (Statement Cache: Type = LRU, Size = 10 and Pinned-to-Thread, enabled).a. Stop MedRec Server1 by using the stop_mr1.sh script.

$> stop_mr1.sh

b. Start MedRec Server1 by using the start_mr1.sh script.$> start_mr1.sh

c. Repeat step 3 (to run the stress test) and record the new results in the Performancestatistics table (Statement Cache: Type = LRU, Size = 10 and Pinned-to-Thread,enabled).

8. Increase the statement cache size to 35 and run the stress test again by using The Grinder.Record the new results in the performance statistics table (Statement Cache: Type=LRU,Size = 35 and Pinned-to-Thread, enabled).a. Using step 6 as a guide, change the statement cache size to 35 .b. Repeat step 3 and record the new results in the Performance statistics table

(Statement Cache: Type = LRU, Size = 35 and Pinned-to-Thread, enabled).c. Review and compare the results collected in all the Performance statistics tables.


59/80


60/80


61/80



Practice 9-1: Tuning EJBIn this practice, you change the size of the initial-beans-in-free-pool to improve theinitial response time of the stateless session EJBs.

OverviewYou are provided with a sample enterprise application involving a Web application that invokes

a stateless session and an EJB to get a quote. Initial benchmarking revealed that the applicationis performing slowly.Stateless session beans provide nonconversational services. They do not maintain state onbehalf of clients and are synchronous. They are maintained in memory by the EJB container. Acontainer can pool stateless session EJBs that different clients can reuse. You can improveperformance by tuning the size of the stateless session EJB pool.

User credentials

Username Password

weblogic Welcome1

Domain configuration

Type Name Address Port

Admin Server adminserver localhost 7001

Managed Server mainserver localhost 7003

Performance statistics: Initial Beans in Free Pool = 1

Metric Mean Test Time (ms) Successful Tests Errors

InsuranceApp

Performance statistics: Initial Beans in Free Pool = 15 (or any custom value)


InsuranceApp

1. Set up the practice domain ( ptcourse ) and deploy the practice application.a. Launch the gnome-terminal and run the following command:

mainserverPort: 7003

adminserverPort: 7001

Domain: ptcourse

InsuranceApp InsuranceEJB


62/80



$> source set_course_env.sh

b. Change the working directory to ~/ wls11g_tune/labs/lab09_01 and execute thesetup command:$ cd ~/wls11g_tune/labs/lab09_01$> ant setup_ptdomain

2. Start the Administration Server, and mainserver in ptcourse . Then deployInsuranceApp applications.a. Start the Administration and Managed servers in the ptcourse domain.

$> start_ptadm.sh$> start_ptmain.sh

b. Navigate to exercise/WLSTScripts subfolder and deploy the InsuranceApp application.$> cd exercise/WLSTScripts$> java weblogic.WLST deploy.py

c. Verify and test the application by opening a Web browser and navigating to

http://localhost:7003/EJBClient 3. Verify the configuration for the “Initial Beans in the Pool” count.

a. Open a Web browser and navigate to http://localhost:7001/console . Log inas weblogic /Welcome1 .

b. In Domain Structure, navigate to ptcourse > Deployments. In the deployments table,click InsuranceApp.

c. In Modules and Components, click Insurance.d. Click the Monitoring tab and verify that the value for the Pooled Beans Current Count =

1.4. Run a stress test by using The Grinder.

a. In the gnome-terminal, navigate to the ~/wls11g_tune/labs/lab09_01/grinder folder and set up the environment variables for The Grinder.$> cd ~/wls11g_tune/labs/lab09_01/grinder$> source ./setEnv.sh

b. Run the stress test by using the following command:$> java net.grinder.Grinder grinder.properties

c. Watch the agent window while the threads start running. When The Grinder agent hasfinished running all threads, the EJB_Results folder containing the files of the stresstest is created in the /u01/app/work folder.

d. Open the out_.log file from the newly created directory and scroll down to

record the following results in the Performance statistics table.1) Mean Test Time (ms)2) Total tests successfully executed3) Errors (if any)

5. Redeploy the InsuranceApp application with a deployment plan that sets the initial-beans-in-free-pool to 15 .


63/80


64/80


65/80





66/80


67/80



Practice 10-1: Tuning JMSIn this practice, you:

• Understand the various disk write policies for writing to a file store• Tune the file persistence store for persisting JMS messages

Overview Addressing the performance of a messaging system in a very generic manner on the WebLogicServer is very difficult. Moreover, the JMS framework itself is optimized on a self-tuningWebLogic Server. However, it is possible to see the cost differentials of using various options,thus setting a level of expectation for the general behavior of JMS. Because you cannot test allpossible combinations, you limit yourself to a subset of options by using a simple messagingapplication.Persisting messages on the server will improve reliability, but at the cost of performance. Inseveral real-world scenarios, reliability takes precedence.The WebLogic Server has seen a lot of improvement in the disk write capabilities. This, inparticular, improves JMS persistence by using a file store.There are three disk write policies available:

• Cache Flush• Direct Write• Disabled

This practice explores the cost differentials of using these three policies.

User credentials

Username Password

weblogic Welcome1

Domain configuration

Type Name Address Port

Admin Server adminserver localhost 7001

Managed Server mainserver localhost 7003

mainserverPort: 7003

adminserverPort: 7001

Domain: ptcourse

MessagingApp

File Store:

Cache Flush

Direct Write

Disabled


68/80



JMS resources

Type Name Target

JMS Server PTJMSServer mainserver

JMS Module PTJMSModule mainserver

JMS ConnectionFactory PTConnectionFactory jms.PTConnectionFactoryJMS Queue PTQueue jms.PTQueue

File Store FileStore_CacheFlush N/A

File Store FileStore_DirectWrite N/A

File Store FileStore_Disabled N/A

Performance statistics

Metric Mean Test Time (ms) Successful

Tests

Errors

MessagingAppFileStore_CacheFlush

Metric Mean Test Time (ms) SuccessfulTests

Errors

MessagingAppFileStore_DirectWrite

Metric Mean Test Time (ms) SuccessfulTests

Errors

MessagingAppFileStore_Disabled



b. Change the working directory to ~/wls11g_tune/labs/lab10_01 and execute thesetup command:$ cd ~/wls11g_tune/labs/lab10_01$> ant setup_ptdomain

2. Start the Administration Server, and mainserver in ptcourse . Then deploy theMessagingApp application.a. Start the Administration and Managed servers in the ptcourse domain.

$> start_ptadm.sh$> start_ptmain.sh

b. Create the necessary JMS resources and deploy the MessagingApp application.


69/80


70/80



a. Repeat step 5 and record the new results in the Performance statistics table(Persistent store: FileStore_DirectWrite).

8. Change the persistent store type to FileStore_Disabled.a. Repeat step 4, this time changing the persistent store type to FileStore_Disabled.

9. Run the stress test again using The Grinder.a. Repeat step 5 and record the new results in the Performance statistics table

(Persistent store: FileStore_Disabled).b. Review and compare the results collected in all the Performance statistics tables.


71/80





72/80






73/80


74/80



Cluster storecluster 239.192.0.0 7001

Managed Serversin cluster

serverA localhost 7005

serverB localhost 7007

serverC localhost 7009

Managed Server proxyserver localhost 7011

Performance statistics: File persistent store


ShoppingCartApp

Performance statistics: In-memory persistent store


InsuranceApp



b. Change the working directory to ~/wls11g_tune/labs/lab11_01 and execute thesetup command:$ cd ~/wls11g_tune/labs/lab11_01$> ant setup_ptdomain

2. Start the Administration Server. Set up the managed servers ServerA , ServerB ,ServerC , and proxyserver . Then create the cluster and deploy the ShoppingCartAppapplication to the cluster and proxyApp to proxyserver .a. In the gnome-terminal, navigate to the …/lab11_01/exercise/WLSTScripts

folder.$ cd ~/wls11g_tune/labs/lab11_01/exercise/WLSTScripts

b. Start the administration server.$> start_ptadm.sh

c. Create managed servers by using the create_server.py WLST script.$> java weblogic.WLST create_server.py

d. Configure the cluster by using the cluster_creation.py WLST script.$> java weblogic.WLST cluster_creation.py

e. To enable easy startup of all the managed servers, copy boot.properties from the Administration Server configuration location to individual managed servers. You canrun the copy_boot.sh shell script.$> ./copy_boot.sh


75/80


76/80


77/80



Then, right-click the process and select Kill Process to terminate the Java process.


78/80


79/80





80/80


Practices OverviewThere is no practice for Lesson 12.

oracle tune improvement

Documents