[jboss-jira] [JBoss JIRA] (WFLY-9456) High non heap memory consumption

[Klaus Erber (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13481539#comment-13481539 ] 

Klaus Erber commented on WFLY-9456:
-----------------------------------

no problem, here are the test results with WF11Final.

The problem is solved. As you mentioned, there was a issue in the CentOS OpenJDK package. The is no problem with the new version 1.8.0.151 with memory consumption in WF11.

I expect that the problem would be solved in docker, with the next image build (https://hub.docker.com/r/jboss/base-jdk/).

{panel:title=OpenJDK (1.8.0_144) ~818 MB}

java -version
openjdk version "1.8.0_144"
OpenJDK Runtime Environment (build 1.8.0_144-b01)
OpenJDK 64-Bit Server VM (build 25.144-b01, mixed mode)

yum info java-1.8.0-openjdk
Installed Packages
Name        : java-1.8.0-openjdk
Arch        : x86_64
Epoch       : 1
Version     : 1.8.0.144
Release     : 0.b01.el7_4
Size        : 501 k
Repo        : installed
>From repo   : updates
Summary     : OpenJDK Runtime Environment
URL         : http://openjdk.java.net/
License     : ASL 1.1 and ASL 2.0 and GPL+ and GPLv2 and GPLv2 with exceptions and LGPL+ and LGPLv2 and MPLv1.0 and MPLv1.1 and Public Domain and W3C
Description : The OpenJDK runtime environment.


ke4       1277 20.6 22.5 2869556 818348 pts/0  Sl+  07:41   0:08 java -D[Standalone] -server -Xms64m -Xmx512m
{panel}

{panel:title=OracleJDK (1.8.0_151) ~198 MB}
java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)

ke4       1464 43.4  5.4 2186124 197836 pts/0  Sl+  07:44   0:09 java -D[Standalone] -server -Xms64m -Xmx512m
{panel}

after yum update

{panel:title=OpenJDK (1.8.0_151) ~200 MB}
openjdk version "1.8.0_151"
OpenJDK Runtime Environment (build 1.8.0_151-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)

yum info java-1.8.0-openjdk
Installed Packages
Name        : java-1.8.0-openjdk
Arch        : x86_64
Epoch       : 1
Version     : 1.8.0.151
Release     : 1.b12.el7_4
Size        : 501 k
Repo        : installed
>From repo   : updates
Summary     : OpenJDK Runtime Environment
URL         : http://openjdk.java.net/
License     : ASL 1.1 and ASL 2.0 and GPL+ and GPLv2 and GPLv2 with exceptions and LGPL+ and LGPLv2 and MPLv1.0 and MPLv1.1 and Public Domain and W3C
Description : The OpenJDK runtime environment.

ke4      12419 38.5  5.5 2208108 199904 pts/0  Sl+  08:22   0:07 java -D[Standalone] -server -Xms64m -Xmx512m
{panel}


> High non heap memory consumption
> --------------------------------
>
>                 Key: WFLY-9456
>                 URL: https://issues.jboss.org/browse/WFLY-9456
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading
>    Affects Versions: 11.0.0.CR1, 11.0.0.Final
>         Environment: CentOS 7 on Google compute engine VM
> openjdk version "1.8.0_144"
> OpenJDK Runtime Environment (build 1.8.0_144-b01)
> OpenJDK 64-Bit Server VM (build 25.144-b01, mixed mode)
>            Reporter: Klaus Erber
>            Assignee: David Lloyd
>         Attachments: wf10-nmt.txt, wf11-nmt.txt
>
>
> After a clean install of WF11CR1 without any configuration changes and startup with standalone.sh we see a high memory usage on the system side (about 800 MB).
> Wenn we do the same with WF10Final we see a memory usage of about 210 MB.
> Her are the output auf ps aux:
> wf11
> ke4       1652 14.0 22.1 2863404 *801620* pts/3  Sl+  14:01   0:07 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m 
> wf10
> ke4       1836 42.1  5.7 2687744 *209204* pts/2  Sl+  14:02   0:06 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
> The result is, that we can only start 3 instances of wildfly 11 on a 3.75 GB VM. The 4th instance crashes the system. In our real scenario (Wildfly instances in docker containers hosting the REST interface for our application) we see about 1 GB memory consumption per backend node.
> The heap and other memory pools not seems to be the reason for this behaviour - see the attached native memory tracking results.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)