Network Deployment (Distributed operating systems), v8.0 > Tune performance > Tune the application serving environment > Tune the JVM


Tune the IBM virtual machine for Java

An application server is a Java based server and requires a Java virtual machine (JVM) environment to run and support the enterprise applications that run on it. As part of configuring your application server, you can configure the Java SE Runtime Environment to tune performance and system resource usage. This topic applies to IBM virtual machines for Java.

New feature: Beginning in WAS v8.0 you can configure the server to use the High Performance Extensible Logging (HPEL) log and trace infrastructure instead of using SystemOut.log , SystemErr.log, trace.log, and activity.log files or native z/OS logging facilities. If you are using HPEL, you can access all of your log and trace information using the LogViewer command-line tool from your server profile bin directory. See the information about using HPEL to troubleshoot applications for more information on using HPEL.New feature:

Each JVM vendor provides detailed information on performance and tuning for their JVM. Use the information provided in this topic in conjunction with the information provided with the JVM that is running on the system.

A Java SE Runtime Environment provides the environment for running enterprise applications and application servers. Therefore the Java configuration plays a significant role in determining performance and system resource consumption for an application server and the applications that run on it.

The IBM virtual machine for Java v6.0 includes the latest in Java EE specifications, and provides performance and stability improvements over previous versions of Java.

Even though JVM tuning is dependent on the JVM provider you use, there are some general tuning concepts that apply to all JVMs. These general concepts include:

The following steps provide specific instructions on how to perform the following types of tuning for each JVM. The steps do not have to be performed in any specific order.


Procedure

  1. Optimize the startup and runtime performance.

    In some environments, such as a development environment, it is more important to optimize the startup performance of the application server rather than the runtime performance. In other environments, it is more important to optimize the runtime performance. By default, IBM virtual machines for Java are optimized for runtime performance, while HotSpot-based JVMs are optimized for startup performance.

    The Java Just-in-Time (JIT) compiler impacts whether startup or runtime performance is optimized. The initial optimization level that the compiler uses influences the length of time that is required to compile a class method, and the length of time that is required to start the server. For faster startups, reduce the initial optimization level that the compiler uses. However if you reduce the initial optimization level, the runtime performance of the applications might decrease because the class methods are now compiled at a lower optimization level.

    • -Xquickstart

      This setting influences how the IBM virtual machine for Java uses a lower optimization level for class method compiles. A lower optimization level provides for faster server startups, but lowers runtime performance. If this parameter is not specified, the IBM virtual machine for Java defaults to starting with a high initial optimization level for compiles, which results in faster runtime performance, but slower server starts.

      You can set this property on the Java virtual machine panel using the admin console. For details, read the information about Java virtual machine settings.

      Default High initial compiler optimization level
      Recommended High initial compiler optimization level
      Usage Specify -Xquickstart improves server startup time.

  2. Verify the classpath as part of the Java configuration.

    In the General Properties section of the Configuration Tab, enter the classpath in the text box of the Classpath option. Make sure that the classpath points to only the classes you need. If possible, the classes that are referenced most frequently should be located near the front of the path.

    Sometimes poor performance is caused by a missing class. The class loader looks in its tables of already loaded classes and if the class is not found to be already loaded it will search for it. This search process can cause a high amount of I/O activity to the HFS volumes.

    To determine if this is the problem you can collect CTRACE records from the file system. Once you determine which class is not being found you can repair the problem by providing the class or by removing the need for it.

  3. Configure the heap size.

    The Java heap parameters influence the behavior of garbage collection. Increasing the heap size supports more object creation. Because a large heap takes longer to fill, the application runs longer before a garbage collection occurs. However, a larger heap also takes longer to compact and causes garbage collection to take longer.

    The JVM uses defined thresholds to manage the storage that it is allocated. When the thresholds are reached, the garbage collector is invoked to free up unused storage. Therefore, garbage collection can cause significant degradation of Java performance. Before changing the initial and maximum heap sizes, you should consider the following information:

    • In the majority of cases you should set the maximum JVM heap size to a value that is higher than the initial JVM heap size. This setting allows for the JVM to operate efficiently during normal, steady state periods within the confines of the initial heap. This setting also allows the JVM to operate effectively during periods of high transaction volume because the JVM can expand the heap up to the value specified for the maximum JVM heap size. In some rare cases, where absolute optimal performance is required, you might want to specify the same value for both the initial and maximum heap size. This setting eliminates some overhead that occurs when the JVM expands or contracts the size of the JVM heap. Before changing any of the JVM heap sizes, verify that the JVM storage allocation is large enough to accommodate the new heap size.
    • Do not make the size of the initial heap so large that while it initially improves performance by delaying garbage collection, when garbage collection does occur, the collection process affects response time because the process has to run longer.

    To use the admin console to configure the heap size:

    1. In the admin console...

      Servers > Server Types > WebSphere application servers > server_name

    2. In the Server Infrastructure section, click Java and process management > Process definition > Java virtual machine.

    3. Specify a new value in either the Initial heap size or the Maximum heap size field.

      We can also specify values for both fields if adjust both settings.

      For performance analysis, the initial and maximum heap sizes should be equal.

      The Initial heap size setting specifies, in megabytes, the amount of storage that is allocated for the JVM heap when the JVM starts. The Maximum heap size setting specifies, in megabytes, the maximum amount of storage that can be allocated to the JVM heap. Both of these settings have a significant effect on performance.

      If you are tuning a production system where you do not know the working set size of the enterprise applications that are running on that system, an appropriate starting value for the initial heap size is 25 percent of the maximum heap size. The JVM then tries to adapt the size of the heap to the working set size of the application.

      The following illustration represents three CPU profiles, each running a fixed workload with varying Java heap settings. In the middle profile, the initial and maximum heap sizes are set to 128 MB. Four garbage collections occur. The total time in garbage collection is about 15 percent of the total run. When the heap parameters are doubled to 256 MB, as in the top profile, the length of the work time increases between garbage collections. Only three garbage collections occur, but the length of each garbage collection is also increased. In the third profile, the heap size is reduced to 64 MB and exhibits the opposite effect. With a smaller heap size, both the time between garbage collections and the time for each garbage collection are shorter. For all three configurations, the total time in garbage collection is approximately 15 percent. This example illustrates an important concept about the Java heap and its relationship to object utilization. A cost for garbage collection always exists when running enterprise applications.



      Run a series of tests that vary the Java heap settings. For example, run experiments with 128 MB, 192 MB, 256 MB, and 320 MB. During each experiment, monitor the total memory usage. If you expand the heap too aggressively, paging can occur.

      Use the vmstat command or the Windows Performance Monitor to check for paging. If paging occurs, reduce the size of the heap or add more memory to the system.

      When all the runs are finished, compare the following statistics:

      • Number of garbage collection calls
      • Average duration of a single garbage collection call
      • Ratio between the length of a single garbage collection call and the average time between calls

      If the application is not over utilizing objects and has no memory leaks, the state of steady memory utilization is reached. Garbage collection also occurs less frequently and for short duration.

      If the heap free space settles at 85 percent or more, consider decreasing the maximum heap size values because the application server and the application are under-utilizing the memory allocated for heap.

    4. Click Apply.

    5. Click Save to save changes to the master configuration.

    6. Stop and restart the application server.

    We can also use the following command-line parameters to adjust these settings. These parameters apply to all supported JVMs and are used to adjust the minimum and maximum heap size for each application server or application server instance.

    • -Xms

      This parameter controls the initial size of the Java heap. Tuning this parameter reduces the overhead of garbage collection, which improves server response time and throughput. For some applications, the default setting for this option might be too low, which causes a high number of minor garbage collections.

      Default 50 MB
      Recommended Workload specific, but higher than the default.
      Usage Specify -Xms256m sets the initial heap size to 256 MB.

    • -Xmx

      This parameter controls the maximum size of the Java heap. Increasing this parameter increases the memory available to the application server, and reduces the frequency of garbage collection. Increasing this setting can improve server response time and throughput. However, increasing this setting also increases the duration of a garbage collection when it does occur. This setting should never be increased above the system memory available for the application server instance. Increasing the setting above the available system memory can cause system paging and a significant decrease in performance.

      Default By default, the JVM dynamically calculates the Java heap size based on the available memory in the system.
      Recommended Workload specific, but higher than the default value, depending on the amount of available physical memory.
      Usage Specify -Xmx512m sets the maximum heap size to 512 MB.
      Specify a value for the -Xmx parameter to reduce possible out-of-memory issues.

    • -Xlp

      Use this parameter with the IBM virtual machine for Java to allocate the heap when using large pages, such as 16 MB pages. Before specifying this parameter, verify that your operating system is configured to support large pages. Using large pages can reduce the CPU overhead needed to keep track of heap memory, and might also allow the creation of a larger heap.

      Default
      64 KB if you are using Java 6 SR 7 or higher

      4 KB if you are using Java 6 SR 6 or lower

      		 

    • –Xlp64k

      This parameter can be used to allocate the heap using medium size pages, such as 64 KB. Using this virtual memory page size for the memory that an application requires can improve the performance and throughput of the application because of hardware efficiencies that are associated with a larger page size.

      i5/OS and AIX provide rich support around 64 KB pages because 64 KB pages are intended to be general purpose pages. 64 KB pages are easy to enable, and applications might receive performance benefits when 64 KB pages are used. Starting with Java 6 SR 7, the Java heap is allocated with 64K pages by default. For Java 6 SR 6 or earlier, 4K pages is the default setting, This setting can be changed without changing the operating system configuration. However, IBM recommends that you run the application servers in a separate storage pool if you use of 64KB pages.

      If you are using Java 6 SR 6 or earlier, to support a 64 KB page size, in the administrative console, click Servers > Application servers > server_name

      > Process definition > Environment entries > New, and then specify LDR_CNTRL in the Name field and DATAPSIZE=64K@TEXTPSIZE=64K@STACKPSIZE=64K in the Value field.

      Recommended Use 64 KB page size whenever possible.

      POWER5+ systems, and AIX 5L v5.3 with the 5300-04 Recommended Maintenance Package support a 64 KB page size when they are running the 64-bit kernel.

    • –Xlp4k

      This parameter can be used to allocate the heap using 4 KB pages. Using this virtual memory page size for the memory that an application requires, instead of 64 KB, might negatively impact performance and throughput of the application because of hardware inefficiencies that are associated with a smaller page size.

      Starting with Java 6 SR 7, the Java heap is allocated with 64K pages by default. For Java 6 SR 6 or earlier, 4K pages is the default setting, This setting can be changed without changing the operating system configuration. However, IBM recommends that you run the application servers in a separate storage pool if you use of 64KB pages.

      If you are using Java 6 SR 7 or higher, to support a 4 KB page size, in the admin console, click Servers > Application servers > server_name

      > Process definition > Environment entries > New, and then specify LDR_CNTRL in the Name field and DATAPSIZE=4K@TEXTPSIZE=4K@STACKPSIZE=4K in the Value field.

      Recommended Use -Xlp64k instead of -Xlp4k whenever possible.

  4. Tune Java memory.

    Enterprise applications written in the Java language involve complex object relationships and use large numbers of objects. Although, the Java language automatically manages memory associated with object life cycles, understanding the application usage patterns for objects is important. In particular, verify that the following conditions exist:

    • The application is not over utilizing objects
    • The application is not leaking objects
    • The Java heap parameters are set properly to handle a given object usage pattern

    1. Check for over-utilization of objects.

      We can review the counters for the JVM run time, that are included in Tivoli Performance Viewer reports, to determine if an application is overusing objects. You have to specify the -XrunpmiJvmtiProfiler command-line option, as well as the JVM module maximum level, to enable the Java virtual machine profiler interface, JVMTI, counters.

      The optimal result for the average time between garbage collections is at least five to six times the average duration of a single garbage collection. If you do not achieve this number, the application is spending more than 15 percent of its time in garbage collection.

      If the information indicates a garbage collection bottleneck, there are two ways to clear the bottleneck. The most cost-effective way to optimize the application is to implement object caches and pools. Use a Java profiler to determine which objects to target. If you can not optimize the application, try adding memory, processors and clones. Additional memory allows each clone to maintain a reasonable heap size. Additional processors allow the clones to run in parallel.

    2. Test for memory leaks.

      Memory leaks in the Java language are a dangerous contributor to garbage collection bottlenecks. Memory leaks are more damaging than memory overuse, because a memory leak ultimately leads to system instability. Over time, garbage collection occurs more frequently until the heap is exhausted and the Java code fails with a fatal out-of-memory exception. Memory leaks occur when an unused object has references that are never freed. Memory leaks most commonly occur in collection classes, such as Hashtable because the table always has a reference to the object, even after real references are deleted.

      High workload often causes applications to crash immediately after deployment in the production environment. If an application has memory leaks, a high workload can accelerate the magnification of the leakage and cause memory allocation failures to occur.

      The goal of memory leak testing is to magnify numbers. Memory leaks are measured in terms of the amount of bytes or kilobytes that cannot be garbage collected. The delicate task is to differentiate these amounts between expected sizes of useful and unusable memory. This task is achieved more easily if the numbers are magnified, resulting in larger gaps and easier identification of inconsistencies. The following list provides insight on how to interpret the results of your memory leak testing:

      • Long-running test

        Memory leak problems can manifest only after a period of time, therefore, memory leaks are found easily during long-running tests. Short running tests might provide invalid indications of where the memory leaks are occurring. It is sometimes difficult to know when a memory leak is occurring in the Java language, especially when memory usage has seemingly increased either abruptly or monotonically in a given period of time. The reason it is hard to detect a memory leak is that these kinds of increases can be valid or might be the intention of the developer. We can learn how to differentiate the delayed use of objects from completely unused objects by running applications for a longer period of time. Long-running application testing gives you higher confidence for whether the delayed use of objects is actually occurring.

      • Repetitive test

        In many cases, memory leak problems occur by successive repetitions of the same test case. The goal of memory leak testing is to establish a big gap between unusable memory and used memory in terms of their relative sizes. By repeating the same scenario over and over again, the gap is multiplied in a very progressive way. This testing helps if the number of leaks caused by the execution of a test case is so minimal that it is hardly noticeable in one run.

        We can use repetitive tests at the system level or module level. The advantage with modular testing is better control. When a module is designed to keep the private module without creating external side effects such as memory usage, testing for memory leaks is easier. First, the memory usage before running the module is recorded. Then, a fixed set of test cases are run repeatedly. At the end of the test run, the current memory usage is recorded and checked for significant changes. Remember, garbage collection must be suggested when recording the actual memory usage by inserting System.gc() in the module where you want garbage collection to occur, or using a profiling tool, to force the event to occur.

      • Concurrency test

        Some memory leak problems can occur only when there are several threads running in the application. Unfortunately, synchronization points are very susceptible to memory leaks because of the added complication in the program logic. Careless programming can lead to kept or not-released references. The incident of memory leaks is often facilitated or accelerated by increased concurrency in the system. The most common way to increase concurrency is to increase the number of clients in the test driver.

        Consider the following points when choosing which test cases to use for memory leak testing:

        • A good test case exercises areas of the application where objects are created. Most of the time, knowledge of the application is required. A description of the scenario can suggest creation of data spaces, such as adding a new record, creating an HTTP session, performing a transaction and searching a record.
        • Look at areas where collections of objects are used. Typically, memory leaks are composed of objects within the same class. Also, collection classes such as Vector and Hashtable are common places where references to objects are implicitly stored by calling corresponding insertion methods. For example, the get method of a Hashtable object does not remove its reference to the retrieved object.

      We can use the Tivoli Performance Viewer to help find memory leaks.

      For optimal results, repeat experiments with increasing duration, such as 1,000, 2,000, and 4,000 page requests. The Tivoli Performance Viewer graph of used memory should have a jagged shape. Each drop on the graph corresponds to a garbage collection. There is a memory leak if one of the following conditions is appears in the graph:

      • The amount of memory used immediately after each garbage collection increases significantly. When this condition occurs, the jagged pattern looks more like a staircase.
      • The jagged pattern has an irregular shape.
      • The gap between the number of objects allocated and the number of objects freed increases over time.

      Heap consumption that indicates a possible leak during periods when the application server is consistently near 100 percent CPU utilization, but disappears when the workload becomes lighter or near-idle, is an indication of heap fragmentation. Heap fragmentation can occur when the JVM can free sufficient objects to satisfy memory allocation requests during garbage collection cycles, but the JVM does not have the time to compact small free memory areas in the heap to larger contiguous spaces.

      Another form of heap fragmentation occurs when objects that are less than 512 bytes are freed. The objects are freed, but the storage is not recovered, resulting in memory fragmentation until a heap compaction occurs.

      Heap fragmentation can be reduced by forcing compactions to occur. However, there is a performance penalty for forcing compactions. Use the Java -X command to see the list of memory options.

  5. Tune garbage collection

    Examine Java garbage collection gives insight to how the application is utilizing memory. Garbage collection is a Java strength. By taking the burden of memory management away from the application writer, Java applications are more robust than applications written in languages that do not provide garbage collection. This robustness applies as long as the application is not abusing objects. Garbage collection typically consumes from 5 to 20 percent of total run time of a properly functioning application. If not managed, garbage collection is one of the biggest bottlenecks for an application.

    Monitor garbage collection while a fixed workload is running, provides you with insight as to whether the application is over using objects. Garbage collection can even detect the presence of memory leaks.

    We can use JVM settings to configure the type and behavior of garbage collection. When the JVM cannot allocate an object from the current heap because of lack of contiguous space, the garbage collector is invoked to reclaim memory from Java objects that are no longer being used. Each JVM vendor provides unique garbage collector policies and tuning parameters.

    We can use the Verbose garbage collection setting in the admin console to enable garbage collection monitoring. The output from this setting includes class garbage collection statistics. The format of the generated report is not standardized between different JVMs or release levels.

    To adjust your JVM garbage collection settings:

    1. In the admin console...

      Servers > Server Types > WebSphere application servers > server_name

    2. In the Server Infrastructure section, click Java and process management > Process definition > Java virtual machine

    3. Enter the –X option to change in the Generic JVM arguments field.

    4. Click Apply.

    5. Click Save to save changes to the master configuration.

    6. Stop and restart the application server.

    The following list describes the –X options for the different JVM garbage collectors.

    The IBM virtual machine for Java garbage collector.

    A complete guide to the IBM implementation of the Java garbage collector is provided in the IBM Developer Kit and Runtime Environment, Java2 Technology Edition, v5.0 Diagnostics Guide. This document is available on the developerWorks website.

    Use the Java -X option to view a list of memory options.

    • -Xgcpolicy

      The IBM virtual machine for Java provides four policies for garbage collection. Each policy provides unique benefits.

      For transitioning users: While each policy provides unique benefits, for WAS V8, gencon is the default garbage collection policy. Previous versions of the application server specify that optthruput is the default garbage collection policy.trns

      • gencon is the default policy. This policy works with the generational garbage collector. The generational scheme attempts to achieve high throughput along with reduced garbage collection pause times.

        To accomplish this goal, the heap is split into new and old segments. Long lived objects are promoted to the old space while short-lived objects are garbage collected quickly in the new space. The gencon policy provides significant benefits for many applications. However, it is not suited for all applications, and is typically more difficult to tune.

      • optthruput provides high throughput but with longer garbage collection pause times. During a garbage collection, all application threads are stopped for mark, sweep and compaction, when compaction is needed. The gencon policy is sufficient for most applications.
      • optavgpause is the policy that reduces garbage collection pause time by performing the mark and sweep phases of garbage collection while an application is running. This policy causes a small performance impact to overall throughput.
      • subpool is a policy that increases performance on multiprocessor systems, that commonly use more then 8 processors. This policy is only available on IBM System i System p and System z processors. The subpool policy is similar to the gencon policy except that the heap is divided into subpools that provide improved scalability for object allocation.

      Default gencon
      Recommended gencon
      Usage Specify Xgcpolicy:gencon sets the garbage collection policy to gencon.

      Setting gcpolicy to gencon disables concurrent mark. You should get optimal throughput results when you use the gencon policy unless you are experiencing erratic application response times, which is an indication that you might have pause time problems

      Set gcpolicy to optavgpause enables concurrent mark with its default values. This setting alleviates erratic application response times that normal garbage collection causes. However, this option might decrease overall throughput.

    • -Xnoclassgc

      By default, the JVM unloads a class from memory whenever there are no live instances of that class left. The overhead of loading and unloading the same class multiple times, can decrease performance. You can use the -Xnoclassgc argument to disable class garbage collection. However, the performance impact of class garbage collection is typically minimal, and turning off class garbage collection in a Java EE based system, with its heavy use of application class loaders, might effectively create a memory leak of class data, and cause the JVM to throw an Out-of-Memory Exception.

      If you use this option, whenever you redeploy an application, you should always restart the application server to clear the classes and static data from the pervious version of the application.

      Default Class garbage collection is enabled.
      Recommended Do not disable class garbage collection.
      Usage Specify Xnoclassgc to disable class garbage collection.

  6. Enable class sharing in a cache.

    The share classes option of the IBM implementation of the Java 2 Runtime Environment (J2RE) v1.5.0 lets you share classes in a cache. Sharing classes in a cache can improve startup time and reduce memory footprint. Processes, such as application servers, node agents, and dmgrs, can use the share classes option.

    Avoid trouble: The IBM implementation of J2RE Version 1.5.0 is currently not supported on:

    • Solaris
    • HP-UX

    If you use this option, you should clear the cache when the process is not in use.

    To clear the cache, either call the WAS_HOME/bin/clearClassCache.bat/sh utility or stop the process and then restart the process.

    If disable the share classes option for a process, specify the generic JVM argument -Xshareclasses:none for that process:

    1. In the admin console...

      Servers > Server Types > WebSphere application servers > server_name

    2. In the Server Infrastructure section, click Java and process management > Process definition > Java virtual machine

    3. Enter -Xshareclasses:none in the Generic JVM arguments field.

    4. Click OK.

    5. Click Save to save changes to the master configuration.

    6. Stop and restart the application server.

    Default The Share classes in a cache option are enabled.
    Recommended Leave the share classes in a cache option enabled.
    Usage Specify -Xshareclasses:none disables the share classes in a cache option.

  7. Enable compressed references on 64-bit environments.

    We can enable compressed references on 64-bit environments, such as AIX 64, Linux PPC 64, zLinux 64, and Microsoft Windows AMD64, Linux AMD64.

    The compressed references option of the IBM implementation of the 64-bit Java SE Runtime Environment (JRE) v6.0 lets you limit all of the memory references to 32-bit size. Typically, the 64-bit JVMs use more heap space than the 32-bit JVMs because they use 64-bit wide memory references to address memory. The heap that is addressable by the 64-bit reference is orders of magnitude larger than the 32-bit heap, but in the real world, a heap that requires all 64-bits for addressing is typically not required. Compressing the references reduces the size of the addresses and makes more efficient use of the heap. Compressing these references also improves the processor cache and bus utilization, thereby improving performance.

    The compressed references feature is not supported on:

    • HP-UX 64-bit JVM
    • iSeries Classic 64-bit JVM

    The product automatically enables pointer compression on the supported platforms by default if the heap size (controlled by the -Xmx parameter) is set under a certain heap size (around 25 GB depending on platform), else it will default to non-compressed references. The user can override these defaults by using the command line options below.

    The following command-line options control compressed references feature:

    -Xcompressedrefs

    This command-line option enables the compressed references feature. When the JVM is launched with this command line option it would use 32-bit wide memory references to address the heap. This feature can be used up to a certain heap size (around 29GB depending on the platform), controlled by -Xmx parameter.

    -Xnocompressedrefs

    This command-line options explicitly disable the compressed references feature. When the JVM is launches with this command line option it will use full 64-bit wide memory references to address the heap. This option can be used by the user to override the default enablement of pointer compression, if needed.

  8. Tune the configuration update process for a large cell configuration.

    In a large cell configuration, you might need to determine whether configuration update performance or consistency checking is more important. The dmgr maintains a master configuration repository for the entire cell. By default, when the configuration changes, the product compares the configuration in the workspace with the master repository to maintain workspace consistency. However, the consistency verification process can cause an increase in the amount of time to save a configuration change or to deploy a large number of applications. The following factors influence how much time is required:

    • The more application servers or clusters that are defined in a cell, the longer it takes to save a configuration change.
    • The more applications that are deployed in a cell, the longer it takes to save a configuration change.

    If the amount of time required to change a configuration change is unsatisfactory, you can add the config_consistency_check custom property to your JVM settings and set the value of this property to false.

    1. In the admin console, click System administration > Deployment manager.

    2. Under Server Infrastructure, select Java and Process Management, and then click Process Definition.

    3. Under Additional Properties, click Java Virtual Machine > Custom Properties > New.

    4. Enter config_consistency_check in the Name field and false in the Value field.

    5. Click OK and then save these changes to the master configuration.

    6. Restart the server.

    The config_consistency_check custom property affects the dmgr process only. It does not affect other processes including the node agent and application server processes. The consistency check is not performed on these processes. However, within the SystemOut.log files for these processes, you might see a note that the consistency check is disabled. For these non-dmgr processes, you can ignore this message.

    If you are using the wsadmin command wsadmin -conntype none in local mode, set the config_consistency_check property to false before issuing this command.


What to do next

Continue to gather and analyze data as you make tuning changes until you are satisfied with how the JVM is performing.
Tune operating systems
Enable the Java virtual machine profiler data
Tune the application serving environment


Related

New feature: managesdk command
Java virtual machine settings

+

Search Tips   |   Advanced Search