7.14.6 Checks and measures when the automatic release processing of the Explicit memory block takes a long time

This subsection describes the checks and measures when the automatic release processing of the Explicit memory block takes a long time.

The automatic release processing of the Explicit memory block occurs concurrently with the GC, and the processing of the J2EE server stops during the automatic release processing. Therefore, if the automatic release processing takes a long time, problems might occur in the system.

If an Explicit memory block with a large size (called large block hereafter) is generated, the automatic release processing takes a long time. A large block might be generated when objects that are not collected by Full GC, such as objects used the entire time an application runs, are allocated to the Explicit heap. Therefore, you must prevent the generation of a large block by allocating the objects that must not be allocated to the Explicit heap, to the Java heap. For details on the event in which a large block is generated and the automatic release processing takes time, see 7.10.2 Mechanism of reducing time required for automatic release processing, and Appendix B.1 Effect on the automatic release processing of the Explicit memory block in the uCosminexus Application Server Expansion Guide.

From the content of the thread dump, you can check whether a large block is being generated.

If a large block is generated, follow the below procedure to specify settings to allocate the objects responsible for the large block to the Java heap.

Action

Applying the functionality for controlling the transfer of objects to the Explicit memory block
Applying the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality
Identifying the objects responsible for a large block and preventing the transfer of those objects to the Explicit heap
Re-tuning the Java heap area and Explicit heap area

This subsection describes how to check whether a large block is being generated and the action to be taken.

Organization of this subsection

(1) Checking whether a large block is being generated
(2) Applying the functionality for controlling the transfer of objects to the Explicit memory block
(3) Applying the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality
(4) Identifying the objects responsible for a large block and preventing the transfer of the objects to the Explicit heap
(5) Re-tuning the Java heap area and Explicit heap area

(1) Checking whether a large block is being generated

Execute the eheapprof command to check the Explicit heap information output to the thread dump.

An example of output is as follows:

 "NULL" eid=1(0x1000000000123456)/B, total 112K, used 55K, garbage 0K (49.2% used/total, 0.0% garbage/used, 0 blocks) Enable
 "NULL" eid=2(0x1000000000223456)/A, total 153744K, used 144766K, garbage 0K (94.2% used/total, 0.0% garbage/used, 0 blocks) Enable
 "ReferenceExplicitMemory-2" eid=3(0x1000000000323456)/R, total 112K, used 55K, garbage 0K (49.3% used/total, 0.0% garbage/used, 0 blocks) Enable

Note:: NULL in the name of the Explicit memory block indicates that the automatic release processing was implemented once, for this Explicit memory block.

The highlighted and bolded parts labeled total indicate the memory size allocated to the Explicit heap.

In this example, the memory size described in total for each Explicit memory block indicates that the Explicit memory block eid=2 is 153,744 KB, and is extremely large compared to the 112-KB Explicit memory blocks eid=1 and eid=3. This indicates that a large block has been generated and that this block is the Explicit memory block eid=2.

To Page Top

(2) Applying the functionality for controlling the transfer of objects to the Explicit memory block

Check the transition in the usage status of the Explicit heap using the event log of the Explicit Memory Management functionality. For details on how to check the transition in the usage status of the Explicit heap, see 7.14.2 Investigating the transition of usage status.

An example of output is as follows:

[ENS]<Thu Oct 21 14:55:50 2007>[EH: 12672K->172032K(172032K/196608K)][E/F/D: 200/0/0][cause:Full GC][CF: 0]
[ENS]<Thu Oct 21 14:55:50 2007>[EH: 172032K->172032K(172032K/196608K), 0.1124626 secs][E/F/D: 200/0/0]\
[DefNew::Eden: 0K->0K(243600K)][DefNew::Survivor: 0K->0K(17400K)][Tenured: 103400K->103400K(556800K)]\
[target:584K/0K/584K][cause:Migrate]

The highlighted and bolded parts beginning with EH: indicate the usage status of the Explicit heap.

In this example, as shown by the part starting with cause:, the first line is log data output when Full GC occurred, and the line immediately after is log data output during automatic release processing, the processing by which the Explicit memory block is automatically released. This indicates that the automatic release processing occurred immediately after the Full GC. The part beginning with EH: in the log on the first line indicates that the used size of the Explicit heap before the Full GC occurred is 12,672 KB, the used size after the Full GC occurs is 172,032 KB, and that the used size of the Explicit heap has increased considerably. Note that if such an event (great increase in the used size of the Explicit heap) does not occur, proceed to step (3).

As shown by this example, if the used size of the Explicit heap has increased considerably after Full GC, apply the functionality for controlling the transfer of objects to the Explicit memory block by specifying 1 in the -XX:ExplicitMemoryFullGCPolicy option. This functionality prevents objects from being transferred to the Explicit memory block based on reference relationships when Full GC occurs. For details on the functionality for controlling the transfer of objects to the Explicit memory block, see 7.10 Reducing time required for automatic release processing of Explicit memory blocks in the uCosminexus Application Server Expansion Guide.

Proceed to step (5) if you can prevent the generation of a large block by applying this functionality, or proceed to step (3) if a large block is still being generated.

To Page Top

(3) Applying the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality

If the following events occur, specify the -XX:+ExplicitMemoryUseExcludeClass option to apply the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality.

A considerable increase in the Explicit heap was not observed in the usage status after Full GC implemented immediately before automatic release processing
A large block is being generated even after applying the functionality for controlling the transfer of objects to the Explicit memory block (step (2) is implemented)

If you apply the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality, the objects of a specific class are no longer transferred to the Explicit heap. The objects of a specific class indicate the objects of the classes coded in the exclusion configuration file for the Explicit Memory Management functionality provided with the system (sysexmemexcludeclass.cfg). For details on the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality, see 7.10 Reducing time required for automatic release processing of Explicit memory blocks in the uCosminexus Application Server Expansion Guide.

Proceed to step (5) if you can prevent the generation of a large block by applying this functionality, or proceed to step (4) if a large block is still being generated.

To Page Top

(4) Identifying the objects responsible for a large block and preventing the transfer of the objects to the Explicit heap

If a large block is being generated even after applying the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality in step (3), the large block might be generated by the transfer of the following objects to the Explicit heap. From among these objects, the objects that continue to survive are not called back with the automatic release processing of the Explicit memory block.

Objects of the classes created by the user in the Java application
Objects created automatically by the framework being used

Therefore, the Explicit Memory Management functionality is not effective even if the objects that are not called back within a fixed period are allocated to the Explicit heap, so allocating the objects to the Java heap (Tenured area) is more appropriate. From among the objects, identify the objects responsible for a large block, and make sure these objects do not move to the Explicit heap.

To identify the objects responsible for a large block, check the object release ratio. The object release ratio is the percentage of objects released with the automatic release processing of the Explicit memory block. Execute the eheapprof command by specifying the -freeratio option to output the object release ratio in the Explicit heap information output in the thread dump.

An example of output is as follows:

  "NULL" eid=1(0x1000000000123456)/B, total 112K, used 55K, garbage 0K (49.2% used/total, 0.0% garbage/used, 0 blocks) Enable
    deployed objects
    ________________Size__Instances__FreeRatio__Class________________
                   49256         10         0 [B
                    3680          4        20 package1.session.StandardManager
                   52936         14 total
 
 
  "NULL" eid=2(0x1000000000223456)/A, total 153744K, used 144766K, garbage 0K (94.2% used/total, 0.0% garbage/used, 0 blocks) Enable
    deployed objects
    ________________Size__Instances__FreeRatio__Class________________
                77862918     433523        10 [C
                52622946     441714        10 java.lang.String
                12838192      39462        35 [B
                    3680          4        20 package1.session.StandardManager
                     104          4         0 framework.ut.impl.performList
               143327840     914707 total
 
  "ReferenceExplicitMemory-2" eid=3(0x1000000000323456)/R, total 112K, used 55K, garbage 0K (49.3% used/total, 0.0% garbage/used, 0 blocks) Enable
    deployed objects
    ________________Size__Instances__FreeRatio__Class________________
                   49256          4         - [B
                    3416         10         - package3.ajp.RequestHandler
                      64          2         - java.lang.StringBuffer
                      64          1         - java.net.SocketInputStream
                      48          1         - [I
                      24          1         - [C
                   52872         19 total

#1: NULL in the name of the Explicit memory block indicates that the automatic release processing was implemented once for this Explicit memory block.
#2: [B in the class name indicates the array type of the Byte class, [C indicates the array type of the Char class, and [I indicates the array type of the Integer class.

The highlighted and bolded parts labeled total indicate the memory size allocated to the Explicit heap. The parts labeled FreeRatio indicate information about the ratio of released objects.

In this example, there are three Explicit memory blocks, eid=1, eid=2, and eid=3. The object release ratio indicated in FreeRatio of each Explicit memory block shows that the object release ratio of the Explicit memory block eid=3 is "-", and that the automatic release processing has not been executed.

First, see the memory size indicated in total for each Explicit memory block. The Explicit memory block eid=2 is 153,744 KB, and is extremely large compared to the 112-KB Explicit memory blocks eid=1 and eid=3. This indicates that the Explicit memory block eid=2 is a large block.

Next, see the object release ratio and the Explicit memory block size for each class of the objects in the large block (eid=2). In this example, there are five objects and the classes of these objects also include the classes provided in Java SE ([B, [C, and java.lang.String). In many cases, the classes provided in Java SE are transferred to the Explicit memory block referenced from the objects responsible for the large block. Therefore, if you specify settings so that the objects responsible for the large block are not transferred to the Explicit memory block, you can also prevent the transfer of the objects of the classes provided in Java SE. Also, if you set the classes provided in Java SE as the target of the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality, the extent of impact is wide and also results in restrictions on the objects allocated to an ideal Explicit memory block. Therefore, do not set the classes provided in Java SE as the target of the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality (however, excluding the cases in which all the objects of the classes provided in Java SE might be allocated to the Java heap).

The classes other than those provided with Java SE include package1.session.StandardManager and framework.ut.impl.performList. The object of package1.session.StandardManager is also used in the Explicit memory block eid=1, but eid=1 is not a large block. This indicates that the objects of this class are not responsible for the large block. From this, you can identify that the object of framework.ut.impl.performList is responsible for the large block.

After identifying the object responsible for the large block, code the class of that object in the configuration file used with the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality. For details on how to specify the code in the configuration file, see 7.13.3 Controlling application target of the Explicit Memory Management functionality by using a configuration file in the uCosminexus Application Server Expansion Guide.

To Page Top

(5) Re-tuning the Java heap area and Explicit heap area

If you apply the object transfer control functionality and the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality, the allocated area of the object changes and the memory size of the Java heap and Explicit heap also increases and decreases. Therefore, see the methods described at the following locations, and then re-tune the memory size for each area:

To Page Top