How To Determine java heap size From GC Logs

Below Figure shows the fields that identify an application’s live data size. It is wise to compute an average of the Java heap occupancy and garbage collection duration of several full garbage collections for your live data size calculation. The more data you collect, the better the estimate for a Java heap size Using the live data size information, an informed decision can be made on an initial Java heap size to use along with an estimate of the worst case latency due to full garbage collections.

As a general rule, the initial and maximum Java heap size command line options, -Xms and -Xmx, should be set to a value between three and four times larger than the live data size of the old generation space. In the full garbage collection data shown in Figure.the old generation space occupancy after the full garbage collection is 295111K, or about 295 megabytes. Hence, the live data size is about 295 megabytes.

Garbage collection log after full GC event

Therefore, the suggested initial and maximum Java heap size to specify for this application should be a value between 885 and 1180 megabytes, that is, -Xms1180m -Xmx1180m for four times the live data size. In Figure starting point.the Java heap size in use is 1048570K, about 1048 megabytes. This Java heap size is at the upper end of the recommendation.

Also as a general rule, the initial and maximum permanent generation size, -XX:PermSize and -XX:MaxPermSize, should be 1.2x to 1.5x larger than the live data size of the permanent generation space. In the example full garbage collection shown in above figure, the permanent generation space occupancy after the full garbage collection is 32390K, or about 32 megabytes. Hence, the suggested initial and maximum permanent generation space size to specify for this application should be between 38 megabytes and 48 megabytes, that is, -XX:PermSize=48m -XX:MaxPermSize=48m, for 1.5 times the permanent generation live data size. In above figure, the permanent generation space size in use is 65536K, about 65 megabytes.

Although this is above the recommended size of 38 to 48 megabytes, 17 additional megabytes in the context of a 1 gigabyte Java heap space is not worth worrying about.

As an additional general rule, the young generation space should be 1 to 1.5 times the old generation space live data size. In the example full garbage collection shown in above figure, the live data size is about 295 megabytes. As a result, the suggested young generation size should be between 295 and 442 megabytes. In above figure, the young generation space size is 358400K, about 358 megabytes. 358 megabytes is within the recommended size. If the initial and maximum Java heap size is 3x to 4x the live data size and the young generation space is 1x to 1.5x the live data size, the size of the old generation space should be between 2x to 3x the live data size.

The combined Java command line applying these general sizing rules based on the garbage collection data in above figure is

$ java -Xms1180m -Xmx1180m -Xmn295m -XX:PermSize=48m -XX:MaxPermSize=48m

Guidelines for Calculating Java Heap Sizing

Guidelines for Calculating Java Heap Sizing

 

 

 

 

Leave a Reply

  1. I used jmap to analyse heap. It seems to me that some part of heap is used although not occupied by objects.
    When I create a new object memory is allocated from this part of used heap. Used does not change when I allocate memory up to a certain limit. Garbage collection helps to reclaim the memory.

    Heap Usage:
    New Generation (Eden + 1 Survivor Space):
    capacity = 5046272 (4.8125MB)
    used = 287936 (0.27459716796875MB)
    free = 4758336 (4.53790283203125MB)
    5.705915178571429% used

    is the same whether I allocate an array of integers or not.

    public class HelloMem {

    public static void main(String[] args) throws Exception {

    // int[] intArray = new int[1000];

    char q = (char) System.in.read();
    }
    }