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

Klaus Erber (JIRA) issues at jboss.org
Thu Oct 19 10:31:02 EDT 2017


     [ https://issues.jboss.org/browse/WFLY-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Klaus Erber updated WFLY-9456:
------------------------------
    Description: 
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.




  was:
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.






> 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
>         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)


More information about the jboss-jira mailing list