Download PDF (1.3 MB) - IBM Redbooks

More documents

Recommendations

Info

Increasing the maximum size of the Java heap might not always solve this type of problem because the problem might be memory overuse. Conversely, if response times are too long because of GC pause times, decrease the heap size. If both problems are observed, an analysis of the application heap usage is required. 4.16.3 Setting the heap size when running multiple JVMs on one system Each running Java program has a heap associated with it. If you have a configuration where more than one Java program is running on a single physical system, setting the heap sizes appropriately is of particular importance. Setting the heap size is also important for 32-bit systems, where the total amount of addressable memory is limited. An example of one such configuration is when the Integration Designer is on the same physical system as a Business Process Manager server using a 32-bit JVM. Each of these applications is a separate Java program that has its own Java heap. If the sum of all of the virtual memory usage (including both Java heaps and all other virtual memory allocations) exceeds the size of addressable physical memory, the Java heaps are subject to paging. Such paging causes total system performance to degrade significantly. To minimize the possibility of total system degradation, use the following guidelines: ► First, collect a verbosegc trace for each running JVM. ► ► ► Based on the verbosegc trace output, set the initial heap size to a relatively low value. For example, assume that the verbosegc trace output shows that the heap size grows quickly to 256 MB, and then grows more slowly to 400 MB and stabilizes at that point. Based on this change, set the initial heap size to 256 MB (-Xms256m). Also based on the verbosegc trace output, set the maximum heap size appropriately. Be careful not to set this value too low, or out-of-memory errors occur. The maximum heap size must be large enough to allow for peak throughput. Using the same example, a maximum heap size of 768 MB might be appropriate (-Xmx768m). Correct sizing of maximum heap gives the Java heap room to expand beyond its current size of 400 MB, if required. The Java heap grows only if required (for example, if a period of peak activity drives a higher throughput rate), so setting the maximum heap size higher than current requirements is generally a good policy. Be careful not to set the heap sizes too low, or garbage collections will occur frequently, which might reduce throughput. Again, a verbosegc trace assists in determining garbage collection frequency. You must ensure that the heap sizes are large enough that garbage collections do not occur too often. At the same time, you must still ensure that the heap sizes are not cumulatively so large as to cause the heap to page to the file system. This balancing act is depends on configuration. 4.16.4 Reducing or increasing heap size if OutOfMemory errors occur The java.lang.OutOfMemory exception is used by the JVM in various circumstances, so that finding the source of the exception is difficult. There is no conclusive mechanism for telling the difference between these potential error sources, but a good start is to collect a trace using verbosegc. If the problem is a lack of memory in the heap, you can easily see this condition in the output. For more information about verbosegc output, see 4.16.1, “Monitoring garbage collection” on page 92. Many garbage collections that produce little free heap space generally occur preceding this exception. If this lack of free heap space is the problem, increase the size of the heap. If there is enough free memory when the java.lang.OutOfMemory exception occurs, the next item to check is the finalizer count from the verbosegc (only the IBM JVM provides this information). If this count appears high, a subtle effect might be occurring whereby resources 94 IBM Business Process Manager V8.0 Performance Tuning and Best Practices
outside the heap are held by objects within the heap and being cleaned by finalizers. Reducing the size of the heap can alleviate this situation by increasing the frequency with which finalizers are run. In addition, examine your application to determine whether the finalizers can be avoided or minimized. Out-of-memory errors can also occur for issues unrelated to JVM heap usage, such as running out of certain system resources. Examples of this problem include insufficient file handles or thread stack sizes that are too small. In some cases, you can tune the configuration to avoid running out of native heap. Try reducing the stack size for threads (the -Xss parameter). Deeply nested methods might force a thread stack overflow if there is insufficient stack size. Also, if you are using a 64-bit IBM JVM, use the -Xgc:preferredHeapBase parameter to avoid native out-of-memory issues because of exhaustion of memory addresses below 4 GB (for example, classes and threads are allocated in this region). You can use the -Xgc:preferredHeapBase option to move the Java heap outside of the lower 4 GB address space. See the IBM JVM information center for a more detailed description of the solution: http://ibm.co/10CGjeT For middleware products, if you are using an in-process version of the JDBC driver, it is possible to find an out-of-process driver that can have a significant effect on the native memory requirements. For example, you can use type 4 JDBC drivers (DB2 Net drivers or Oracle's Thin drivers), or you can switch IBM MQSeries® from Bindings mode to Client mode. See documentation for DB2, Oracle, and MQSeries for more details. 4.17 Tuning for WebSphere InterChange Server migrated workloads The following tuning suggestions are unique to workloads that are migrated by using the WebSphere InterChange Server migration wizard in the Integration Designer. In addition to these suggestions, see the other Business Process Manager server tuning suggestions detailed in this document: ► ► ► For JMS-based messaging used to communicate with older WebSphere Business Integration adapters or custom adapters, use non-persistent queues when possible. For JMS-based messaging used to communicate with older WebSphere Business Integration adapters or custom adapters, use WebSphere MQ-based queues, if available. By default, the adapters use the WebSphere MQ APIs to connect to the service integration bus destinations through MQ Link. MQ Link is a protocol translation layer that converts messages to and from MQ-based clients. By switching to WebSphere MQ-based queues, MQLink translation costs are eliminated and performance is improved. Turn off server logs for verbose workloads. Some workloads emit log entries for every transaction, causing constant disk writes and reducing overall throughput. Turning off server logs might reduce the throughput degradation for such workloads. Chapter 4. Performance tuning and configuration 95
Page 1:
IBM ® WebSphere ® Front cover IBM
Page 4 and 5:
Note: Before using this information
Page 6 and 7:
3.1.8 Preventing WSDL validation fr
Page 8 and 9:
4.15.4 Sizing log files appropriate
Page 10 and 11:
Trademarks IBM, the IBM logo, and i
Page 12 and 13:
Now you can become a published auth
Page 14 and 15:
1.1 Products covered in this public
Page 16 and 17:
4 IBM Business Process Manager V8.0
Page 18 and 19:
2.1 Top tuning and deployment guide
Page 20 and 21:
Two individuals with the following
Page 22 and 23:
Turn off auto-tracking in business
Page 24 and 25:
Avoid use of anonymous derived type
Page 26 and 27:
► ► Independent Disks (RAID) ad
Page 28 and 29:
that can process 10 requests per se
Page 30 and 31:
2.4.2 Use a high-performing browser
Page 32 and 33:
Batched inputs: Sending large objec
Page 34 and 35:
2.7 Business Monitor This section d
Page 36 and 37:
3.1 Process Designer development be
Page 38 and 39:
3.1.5 Use sequential system lane ac
Page 40 and 41:
3.2 Integration Designer best pract
Page 42 and 43:
3.2.4 Business object parsing mode
Page 44 and 45:
Applications benefiting from lazy p
Page 46 and 47:
Business object instance validator
Page 48 and 49:
3.2.6 Business Process Execution La
Page 50 and 51:
Client systems that follow a page-f
Page 52 and 53:
3.2.10 Invocation style considerati
Page 54 and 55:
If a number of services in a FanOut
Page 56 and 57: Aggregation blocks (FanOut and FanI
Page 58 and 59: ► ► ► - The generated BPEL fl
Page 60 and 61: 4.1 Performance tuning methodology
Page 62 and 63: This information is useful for obta
Page 64 and 65: ► ► ► ► Messaging and messa
Page 66 and 67: If you click Generational Concurren
Page 68 and 69: 4.3.7 Messaging engine properties T
Page 70 and 71: ► ► Ensure that database statis
Page 72 and 73: 4.5.8 Define Authentication Alias w
Page 74 and 75: 4.6 Process Center tuning Because a
Page 76 and 77: peak throughput, so if an adapter i
Page 78 and 79: esources (for example, a DB2 databa
Page 80 and 81: Use the following steps to place al
Page 82 and 83: 4.7.5 Clustered topology tuning One
Page 84 and 85: To check the Business Space target
Page 86 and 87: In addition, you can customize the
Page 88 and 89: 4.9.2 Disabling event distribution
Page 90 and 91: This processing and reporting mode
Page 92 and 93: 4.13 General database tuning This s
Page 94 and 95: 4.14 DB2-specific database tuning P
Page 96 and 97: Increasing the primary log file siz
Page 98 and 99: When running clustered applications
Page 100 and 101: Using materialized query tables Whe
Page 102 and 103: 4.15.8 Special considerations for l
Page 104 and 105: 4.16.1 Monitoring garbage collectio
Page 108 and 109: 96 IBM Business Process Manager V8.
Page 110 and 111: 5.1 Business Process Manager server
Page 112 and 113: Tuning variations Microflow: Number
Page 114 and 115: DB2 database server in three-tiered
Page 116 and 117: ► Set the Maximum Connections pro
Page 118 and 119: 106 IBM Business Process Manager V8
Page 120: ► ► ► ► ► Understanding a
show all

Download PDF (1.3 MB) - IBM Redbooks

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?