Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Memory allocation behaviour with Java 1.8 in Tomcat 6 and Tomcat 8

Related question: Garbage collector usage when upgrade from Java 6 + Tomcat 6 to Java 8 + Tomcat 8

I have a set of webapps, compiled with Java 8. If I run them in Tomcat 8, I get a lot of minor GC collections with a random memory allocation. In Tomcat 6 memory allocation is more linear and stable (idle in both cases, no traffic).

Eden Space Tomcat 8:

enter image description here

enter image description here

Eden Space Tomcat 6:

enter image description here

enter image description here

Do you know why that happens?

EDIT 1:

These are the data from production environment with jdk 1.8 and Tomcat 8. CPU is really high almost always due to GC cycles. Any comments about that?

enter image description here enter image description here

EDIT 2:

This is a heapdump analisis (1.8GB dump):

enter image description here

like image 809
Fran Montero Avatar asked Sep 04 '15 07:09

Fran Montero


2 Answers

This is eden space, not the tenured space. So, that alone is good news.

But that step of memory appears to be tomcat8 allocating something right away after a young GC. Could it be some 'balloon' technique? (allocating a large weakly referenced buffer to 'deflate' rapidly to ensure some room in case of memory pressure). It may hide in NIO connectors too, as in the 'oomParachute' parameter (1 MB by default, but is it per httpprocessor thread? If you had 200 min threads, that would match the 200 MB seen).

I will only suggest that you can drill into the changelog to find new thing or changes that you might think they implemented wastefully like such balloon mechanism.

ALSO: you should run the tomcat6 in your jdk8 to see if it is really tomcat8 at fault. The eden space could be made larger, just in case the G1GC is so aggressive that it feels obligated to GC when a mere 200MB is used.

like image 137
user2023577 Avatar answered Nov 14 '22 10:11

user2023577


Thank you all guys for your time. In the end, the problem is a bug in tomcat 8.0_23. Using Javosize, i saw a thread consuming almost all CPU time:

enter image description here

Looking on the internet i found this Tomcat AJP Bug

In adittion, i've tested tomcat 8.0_32 and that Poller thread does not even exist so problem solved.

Regards

like image 1
Fran Montero Avatar answered Nov 14 '22 10:11

Fran Montero