[JBoss JIRA] (WFLY-5955) Include -XX:MetaspaceSize in our default vm settings
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-5955?page=com.atlassian.jira.plugin.... ]
Brian Stansberry moved WFCORE-1279 to WFLY-5955:
------------------------------------------------
Project: WildFly (was: WildFly Core)
Key: WFLY-5955 (was: WFCORE-1279)
Component/s: Server
(was: Server)
Fix Version/s: 10.0.0.Final
(was: 3.0.0.Alpha1)
(was: 2.0.6.Final)
> Include -XX:MetaspaceSize in our default vm settings
> ----------------------------------------------------
>
> Key: WFLY-5955
> URL: https://issues.jboss.org/browse/WFLY-5955
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 10.0.0.Final
>
>
> JDK 8 no longer has a perm gen, but it does have a "Metaspace" area of native memory where it stores some of the types of data previously stored in perm gen, class metadata in particular.
> The default size of this is, I believe 21MB on a 64 bit VM. Full WildFly uses over 50MB, excluding apps. The VM will increase the size once it gets over a certain percentage full, but it will do a full, stop-the-world GC before increasing. This means full WildFly has two full GCs as part of boot.
> The -XX:MetaspaceSize JVM option allows the minimum size to be set. Using a reasonable value for this will help avoid unnecessary full GCs.
> I'm not sure the best value to use. A minimum of 80MB was enough to avoid a full GC during a boot of standalone-full-ha.xml. But then any sort of deployments will trigger a full GC. OTOH, our host.xml jvm elements have historically included a -XX:PermSize setting of 256M, so that's another possible value. Perm Gen and Metaspace aren't completely equivalent (e.g. before JDK 7 perm gen included stuff like interned strings, which are now in the heap.)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1150) Include -XX:MetaspaceSize in our default vm settings
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1150?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1150:
----------------------------------------
Assignee: Brian Stansberry
> Include -XX:MetaspaceSize in our default vm settings
> ----------------------------------------------------
>
> Key: WFCORE-1150
> URL: https://issues.jboss.org/browse/WFCORE-1150
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.6.Final, 3.0.0.Alpha1
>
>
> JDK 8 no longer has a perm gen, but it does have a "Metaspace" area of native memory where it stores some of the types of data previously stored in perm gen, class metadata in particular.
> The default size of this is, I believe 21MB on a 64 bit VM. Full WildFly uses over 50MB, excluding apps. The VM will increase the size once it gets over a certain percentage full, but it will do a full, stop-the-world GC before increasing. This means full WildFly has two full GCs as part of boot.
> The -XX:MetaspaceSize JVM option allows the minimum size to be set. Using a reasonable value for this will help avoid unnecessary full GCs.
> I'm not sure the best value to use. A minimum of 80MB was enough to avoid a full GC during a boot of standalone-full-ha.xml. But then any sort of deployments will trigger a full GC. OTOH, our host.xml jvm elements have historically included a -XX:PermSize setting of 256M, so that's another possible value. Perm Gen and Metaspace aren't completely equivalent (e.g. before JDK 7 perm gen included stuff like interned strings, which are now in the heap.)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1279) Include -XX:MetaspaceSize in our default vm settings
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1279:
----------------------------------------
Summary: Include -XX:MetaspaceSize in our default vm settings
Key: WFCORE-1279
URL: https://issues.jboss.org/browse/WFCORE-1279
Project: WildFly Core
Issue Type: Enhancement
Components: Server
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 2.0.6.Final, 3.0.0.Alpha1
JDK 8 no longer has a perm gen, but it does have a "Metaspace" area of native memory where it stores some of the types of data previously stored in perm gen, class metadata in particular.
The default size of this is, I believe 21MB on a 64 bit VM. Full WildFly uses over 50MB, excluding apps. The VM will increase the size once it gets over a certain percentage full, but it will do a full, stop-the-world GC before increasing. This means full WildFly has two full GCs as part of boot.
The -XX:MetaspaceSize JVM option allows the minimum size to be set. Using a reasonable value for this will help avoid unnecessary full GCs.
I'm not sure the best value to use. A minimum of 80MB was enough to avoid a full GC during a boot of standalone-full-ha.xml. But then any sort of deployments will trigger a full GC. OTOH, our host.xml jvm elements have historically included a -XX:PermSize setting of 256M, so that's another possible value. Perm Gen and Metaspace aren't completely equivalent (e.g. before JDK 7 perm gen included stuff like interned strings, which are now in the heap.)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1279) Include -XX:MetaspaceSize in our default vm settings
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1279?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1279:
-------------------------------------
Issue Type: Bug (was: Enhancement)
> Include -XX:MetaspaceSize in our default vm settings
> ----------------------------------------------------
>
> Key: WFCORE-1279
> URL: https://issues.jboss.org/browse/WFCORE-1279
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.6.Final, 3.0.0.Alpha1
>
>
> JDK 8 no longer has a perm gen, but it does have a "Metaspace" area of native memory where it stores some of the types of data previously stored in perm gen, class metadata in particular.
> The default size of this is, I believe 21MB on a 64 bit VM. Full WildFly uses over 50MB, excluding apps. The VM will increase the size once it gets over a certain percentage full, but it will do a full, stop-the-world GC before increasing. This means full WildFly has two full GCs as part of boot.
> The -XX:MetaspaceSize JVM option allows the minimum size to be set. Using a reasonable value for this will help avoid unnecessary full GCs.
> I'm not sure the best value to use. A minimum of 80MB was enough to avoid a full GC during a boot of standalone-full-ha.xml. But then any sort of deployments will trigger a full GC. OTOH, our host.xml jvm elements have historically included a -XX:PermSize setting of 256M, so that's another possible value. Perm Gen and Metaspace aren't completely equivalent (e.g. before JDK 7 perm gen included stuff like interned strings, which are now in the heap.)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1150) Include -XX:MetaspaceSize in our default vm settings
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1150?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1150:
-------------------------------------
Issue Type: Bug (was: Enhancement)
> Include -XX:MetaspaceSize in our default vm settings
> ----------------------------------------------------
>
> Key: WFCORE-1150
> URL: https://issues.jboss.org/browse/WFCORE-1150
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.6.Final, 3.0.0.Alpha1
>
>
> JDK 8 no longer has a perm gen, but it does have a "Metaspace" area of native memory where it stores some of the types of data previously stored in perm gen, class metadata in particular.
> The default size of this is, I believe 21MB on a 64 bit VM. Full WildFly uses over 50MB, excluding apps. The VM will increase the size once it gets over a certain percentage full, but it will do a full, stop-the-world GC before increasing. This means full WildFly has two full GCs as part of boot.
> The -XX:MetaspaceSize JVM option allows the minimum size to be set. Using a reasonable value for this will help avoid unnecessary full GCs.
> I'm not sure the best value to use. A minimum of 80MB was enough to avoid a full GC during a boot of standalone-full-ha.xml. But then any sort of deployments will trigger a full GC. OTOH, our host.xml jvm elements have historically included a -XX:PermSize setting of 256M, so that's another possible value. Perm Gen and Metaspace aren't completely equivalent (e.g. before JDK 7 perm gen included stuff like interned strings, which are now in the heap.)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1150) Include -XX:MetaspaceSize in our default vm settings
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1150?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1150:
------------------------------------------
In a discussion with Andy Miller, he recommended we use the same values that we previously used for PermSize/MaxPermSize.
> Include -XX:MetaspaceSize in our default vm settings
> ----------------------------------------------------
>
> Key: WFCORE-1150
> URL: https://issues.jboss.org/browse/WFCORE-1150
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Server
> Reporter: Brian Stansberry
> Fix For: 2.0.6.Final, 3.0.0.Alpha1
>
>
> JDK 8 no longer has a perm gen, but it does have a "Metaspace" area of native memory where it stores some of the types of data previously stored in perm gen, class metadata in particular.
> The default size of this is, I believe 21MB on a 64 bit VM. Full WildFly uses over 50MB, excluding apps. The VM will increase the size once it gets over a certain percentage full, but it will do a full, stop-the-world GC before increasing. This means full WildFly has two full GCs as part of boot.
> The -XX:MetaspaceSize JVM option allows the minimum size to be set. Using a reasonable value for this will help avoid unnecessary full GCs.
> I'm not sure the best value to use. A minimum of 80MB was enough to avoid a full GC during a boot of standalone-full-ha.xml. But then any sort of deployments will trigger a full GC. OTOH, our host.xml jvm elements have historically included a -XX:PermSize setting of 256M, so that's another possible value. Perm Gen and Metaspace aren't completely equivalent (e.g. before JDK 7 perm gen included stuff like interned strings, which are now in the heap.)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1150) Include -XX:MetaspaceSize in our default vm settings
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1150?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1150:
-------------------------------------
Fix Version/s: 2.0.6.Final
> Include -XX:MetaspaceSize in our default vm settings
> ----------------------------------------------------
>
> Key: WFCORE-1150
> URL: https://issues.jboss.org/browse/WFCORE-1150
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Server
> Reporter: Brian Stansberry
> Fix For: 2.0.6.Final, 3.0.0.Alpha1
>
>
> JDK 8 no longer has a perm gen, but it does have a "Metaspace" area of native memory where it stores some of the types of data previously stored in perm gen, class metadata in particular.
> The default size of this is, I believe 21MB on a 64 bit VM. Full WildFly uses over 50MB, excluding apps. The VM will increase the size once it gets over a certain percentage full, but it will do a full, stop-the-world GC before increasing. This means full WildFly has two full GCs as part of boot.
> The -XX:MetaspaceSize JVM option allows the minimum size to be set. Using a reasonable value for this will help avoid unnecessary full GCs.
> I'm not sure the best value to use. A minimum of 80MB was enough to avoid a full GC during a boot of standalone-full-ha.xml. But then any sort of deployments will trigger a full GC. OTOH, our host.xml jvm elements have historically included a -XX:PermSize setting of 256M, so that's another possible value. Perm Gen and Metaspace aren't completely equivalent (e.g. before JDK 7 perm gen included stuff like interned strings, which are now in the heap.)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1278) Capability resolution complaints on admin-only slave HCs not connected to the master
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1278:
----------------------------------------
Summary: Capability resolution complaints on admin-only slave HCs not connected to the master
Key: WFCORE-1278
URL: https://issues.jboss.org/browse/WFCORE-1278
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.0.5.Final
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 3.0.0.Alpha1
If you start a slave HC in admin-only with no master to connect to, boot is fine but then any modifications made to the config result in capability resolution ERROR messages in the host-controller.log
Starting a slave HC in admin-only with no master to connect to is meant to work, allowing you to use CLI to manipulate the slave's host config:
{code}
bin/domain.sh --host-config=host-slave.xml --admin-only -Djboss.domain.master.address=127.0.0.1
{code}
The boot is fine:
{code}
[Host Controller] 11:06:10,639 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.Final-SNAPSHOT (WildFly Core 2.0.5.Final) (Host Controller) started in 1152ms - Started 41 of 42 services (12 services are lazy, passive or on-demand)
{code}
However, subsequent changes made via management tools (e.g. CLI) succeed but result in ERROR logging by the HC:
{code}
[domain@127.0.0.1:9999 /] /host=localhost/system-property=foo:add(value=bar)
{
"outcome" => "success",
"result" => undefined,
"server-groups" => undefined
}
{code}
The HC's log:
{code}
[Host Controller] 11:07:37,744 ERROR [org.jboss.as.controller] (management-handler-thread - 4) WFLYCTL0369: Required capabilities are not available:
[Host Controller] org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
[Host Controller] org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
{code}
The boot works without logging because of the enhancement Stuart added such that capability reference failures won't fail an admin-only boot, thus letting the user use admin-only to fix the config. But then with subsequent changes, the user gets ERRORs notifying them of the unfixed references.
But in this case, the references will never be available, so long as there is no connection to a master to provide the domain-wide config.
This is a general case that needs to be accounted for in the capability resolution logic.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1260) Capability resolution complaints on admin-only slave HCs not connected to the master
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1260?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1260:
------------------------------------------
The CapabilityRegistry.resolveCapabilities already has logic for ignoring unresolved capabilities like this, via its "hostXmlOnly" param. So the solution to this is to ensure that this param has the correct value in these situations where the HC is admin only with no available domain model.
> Capability resolution complaints on admin-only slave HCs not connected to the master
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-1260
> URL: https://issues.jboss.org/browse/WFCORE-1260
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.5.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> If you start a slave HC in admin-only with no master to connect to, boot is fine but then any modifications made to the config result in capability resolution ERROR messages in the host-controller.log
> Starting a slave HC in admin-only with no master to connect to is meant to work, allowing you to use CLI to manipulate the slave's host config:
> {code}
> bin/domain.sh --host-config=host-slave.xml --admin-only -Djboss.domain.master.address=127.0.0.1
> {code}
> The boot is fine:
> {code}
> [Host Controller] 11:06:10,639 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.Final-SNAPSHOT (WildFly Core 2.0.5.Final) (Host Controller) started in 1152ms - Started 41 of 42 services (12 services are lazy, passive or on-demand)
> {code}
> However, subsequent changes made via management tools (e.g. CLI) succeed but result in ERROR logging by the HC:
> {code}
> [domain@127.0.0.1:9999 /] /host=localhost/system-property=foo:add(value=bar)
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => undefined
> }
> {code}
> The HC's log:
> {code}
> [Host Controller] 11:07:37,744 ERROR [org.jboss.as.controller] (management-handler-thread - 4) WFLYCTL0369: Required capabilities are not available:
> [Host Controller] org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> [Host Controller] org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> {code}
> The boot works without logging because of the enhancement Stuart added such that capability reference failures won't fail an admin-only boot, thus letting the user use admin-only to fix the config. But then with subsequent changes, the user gets ERRORs notifying them of the unfixed references.
> But in this case, the references will never be available, so long as there is no connection to a master to provide the domain-wide config.
> This is a general case that needs to be accounted for in the capability resolution logic.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months