June 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2959) Export a low MALLOC_ARENA_MAX value in standalone.conf and domain.conf

by Andrig Miller (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2959?page=com.atlassian.jira.plugi... ] Andrig Miller commented on WFCORE-2959: --------------------------------------- [~dmlloyd]I don't see how it can cause memory allocation performance to drop, accept at startup of the JVM itself. The JVM doesn't call MALLOC often, and only in situations with the heap settings where the min and max are not the same value will it call MALLOC after startup. Or the case of when there is no max set for MetaSpace, that could generate calls to MALLOC during runtime, but it also will be limited. In testing 1 vs. 2, we didn't see any real difference, but if we want to do 2 to feel more comfortable that is fine by me. > Export a low MALLOC_ARENA_MAX value in standalone.conf and domain.conf > ---------------------------------------------------------------------- > > Key: WFCORE-2959 > URL: https://issues.jboss.org/browse/WFCORE-2959 > Project: WildFly Core > Issue Type: Enhancement > Components: Scripts > Reporter: Brian Stansberry > Assignee: Tomaz Cerar > > This is a task that came out of research done by [~andy.miller] on WF/EAP memory use in cloud environments. > Our launch scripts for *nix environments should set MALLOC_ARENA_MAX, e.g. > export MALLOC_ARENA_MAX=${MALLOC_ARENA_MAX:-1} > See http://info.prelert.com/blog/java-8-and-virtual-memory-on-linux for background. > The default glibc settings of allowing up to 128 malloc arenas make very little sense for a java application, since the vm asks the os for a few large memory allocations and then manages those areas itself. Leaving that default setting in place will result in a very large virtual memory size for the VM. It's just virtual, not resident, memory, so controlling this to a large extent is just a matter of having a better image for people who don't understand the distinction. But as is mentioned in the linked blog post's discussion of mlockall() and Elasticsearch, there may be some more concrete implications as well. > The initial recommendation on this was to set the value to 1, but this bears some research/discussion. For example hadoop uses 4 (https://issues.apache.org/jira/browse/HADOOP-7154), and a bit of googling of "MALLOC_ARENA_MAX java" leads to some entries mentioning using 2 or 3. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2959) Export a low MALLOC_ARENA_MAX value in standalone.conf and domain.conf

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2959?page=com.atlassian.jira.plugi... ] David Lloyd commented on WFCORE-2959: ------------------------------------- If it's too low, couldn't we end up in a situation where allocation performance drops? > Export a low MALLOC_ARENA_MAX value in standalone.conf and domain.conf > ---------------------------------------------------------------------- > > Key: WFCORE-2959 > URL: https://issues.jboss.org/browse/WFCORE-2959 > Project: WildFly Core > Issue Type: Enhancement > Components: Scripts > Reporter: Brian Stansberry > Assignee: Tomaz Cerar > > This is a task that came out of research done by [~andy.miller] on WF/EAP memory use in cloud environments. > Our launch scripts for *nix environments should set MALLOC_ARENA_MAX, e.g. > export MALLOC_ARENA_MAX=${MALLOC_ARENA_MAX:-1} > See http://info.prelert.com/blog/java-8-and-virtual-memory-on-linux for background. > The default glibc settings of allowing up to 128 malloc arenas make very little sense for a java application, since the vm asks the os for a few large memory allocations and then manages those areas itself. Leaving that default setting in place will result in a very large virtual memory size for the VM. It's just virtual, not resident, memory, so controlling this to a large extent is just a matter of having a better image for people who don't understand the distinction. But as is mentioned in the linked blog post's discussion of mlockall() and Elasticsearch, there may be some more concrete implications as well. > The initial recommendation on this was to set the value to 1, but this bears some research/discussion. For example hadoop uses 4 (https://issues.apache.org/jira/browse/HADOOP-7154), and a bit of googling of "MALLOC_ARENA_MAX java" leads to some entries mentioning using 2 or 3. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2959) Export a low MALLOC_ARENA_MAX value in standalone.conf and domain.conf

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-2959: ---------------------------------------- Summary: Export a low MALLOC_ARENA_MAX value in standalone.conf and domain.conf Key: WFCORE-2959 URL: https://issues.jboss.org/browse/WFCORE-2959 Project: WildFly Core Issue Type: Enhancement Components: Scripts Reporter: Brian Stansberry Assignee: Tomaz Cerar This is a task that came out of research done by [~andy.miller] on WF/EAP memory use in cloud environments. Our launch scripts for *nix environments should set MALLOC_ARENA_MAX, e.g. export MALLOC_ARENA_MAX=${MALLOC_ARENA_MAX:-1} See http://info.prelert.com/blog/java-8-and-virtual-memory-on-linux for background. The default glibc settings of allowing up to 128 malloc arenas make very little sense for a java application, since the vm asks the os for a few large memory allocations and then manages those areas itself. Leaving that default setting in place will result in a very large virtual memory size for the VM. It's just virtual, not resident, memory, so controlling this to a large extent is just a matter of having a better image for people who don't understand the distinction. But as is mentioned in the linked blog post's discussion of mlockall() and Elasticsearch, there may be some more concrete implications as well. The initial recommendation on this was to set the value to 1, but this bears some research/discussion. For example hadoop uses 4 (https://issues.apache.org/jira/browse/HADOOP-7154), and a bit of googling of "MALLOC_ARENA_MAX java" leads to some entries mentioning using 2 or 3. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2960) Export a low MALLOC_ARENA_MAX value in standalone.conf and domain.conf

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-2960: ---------------------------------------- Summary: Export a low MALLOC_ARENA_MAX value in standalone.conf and domain.conf Key: WFCORE-2960 URL: https://issues.jboss.org/browse/WFCORE-2960 Project: WildFly Core Issue Type: Enhancement Components: Scripts Reporter: Brian Stansberry Assignee: Tomaz Cerar This is a task that came out of research done by [~andy.miller] on WF/EAP memory use in cloud environments. Our launch scripts for *nix environments should set MALLOC_ARENA_MAX, e.g. export MALLOC_ARENA_MAX=${MALLOC_ARENA_MAX:-1} See http://info.prelert.com/blog/java-8-and-virtual-memory-on-linux for background. The default glibc settings of allowing up to 128 malloc arenas make very little sense for a java application, since the vm asks the os for a few large memory allocations and then manages those areas itself. Leaving that default setting in place will result in a very large virtual memory size for the VM. It's just virtual, not resident, memory, so controlling this to a large extent is just a matter of having a better image for people who don't understand the distinction. But as is mentioned in the linked blog post's discussion of mlockall() and Elasticsearch, there may be some more concrete implications as well. The initial recommendation on this was to set the value to 1, but this bears some research/discussion. For example hadoop uses 4 (https://issues.apache.org/jira/browse/HADOOP-7154), and a bit of googling of "MALLOC_ARENA_MAX java" leads to some entries mentioning using 2 or 3. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2895) Save memory in RuntimeCapability ServiceName creation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2895?page=com.atlassian.jira.plugi... ] Brian Stansberry reopened WFCORE-2895: -------------------------------------- I'm reopening this as I don't see any point in creating a new JIRA for the further work I'm going to do on this. > Save memory in RuntimeCapability ServiceName creation > ----------------------------------------------------- > > Key: WFCORE-2895 > URL: https://issues.jboss.org/browse/WFCORE-2895 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 3.0.0.Beta24 > > > RuntimeCapability.fromBaseCapability results in a new RuntimeCapability that creates its ServiceName by parsing the base capability's string name instead of using its existing ServiceName. This wastes memory since the strings end up being duplicated. > Also RuntimeCapability should not create a ServiceName if the cap has no serviceValueType. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8929) Race condition if timers overlap due to long running execution and short schedules if database persistence is used

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-8929?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated WFLY-8929: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1461416 Bugzilla Update: Perform > Race condition if timers overlap due to long running execution and short schedules if database persistence is used > ------------------------------------------------------------------------------------------------------------------ > > Key: WFLY-8929 > URL: https://issues.jboss.org/browse/WFLY-8929 > Project: WildFly > Issue Type: Bug > Components: EJB > Environment: Configure DB persistence for timers as file-persistence will not have a persistence check for shouldRun to lock the timer execution. > Reporter: Wolf-Dieter Fink > Assignee: Wolf-Dieter Fink > Attachments: server-extract.log, server1.log > > > If timers (here calendar timer) are running longer than scheduled, or the schedule/processing get stuck do to thread or cpu bottleneck, it is possible that the updates for persistence overlap. > The issue seems that the task(1) try to finish the timer and task(2) is about to start but see the concurrency. > The DB is updated with the 'old' next timeout, but the internal Timer instance will be updated with the next possible schedule due to a race condition between the two threads updating the object. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2958) Composite operation on periodic-rotating-file-handler fails

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2958?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-2958: --------------------------------------- The issue here is the undefining the {{formatter}} attribute then defining a {{named-formatter}}. When the {{named-formatter}} is written it attempts to remove a formatter with the same name as the handler. The initial {{undefine-attribute}} on the {{formatter}} attribute tries to edit the previous formatter which has been removed. One option would be to not have the log managers configuration API remove the handlers name from it's configuration collection until the action is executed. This may be the only real option to fix this issue. Another option may be for the OSH not to remove the formatter. This will however leave the formatter in the configuration API that's not used. We could add an additional step that would execute after the commit step which removes handler then does an additional commit. > Composite operation on periodic-rotating-file-handler fails > ----------------------------------------------------------- > > Key: WFCORE-2958 > URL: https://issues.jboss.org/browse/WFCORE-2958 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > When performing composite operation on periodic-rotating-file-handler, it fails with [1] although individual steps passes. This affects Web Console form editing. > [1] > {code} > [standalone@localhost:9990 / #] run-batch > The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): > WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed: > Step: step-1 > Operation: /subsystem=logging/periodic-rotating-file-handler=foo:undefine-attribute(name=formatter) > Failure: WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: Formatter "foo" is not found > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2958) Composite operation on periodic-rotating-file-handler fails

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2958?page=com.atlassian.jira.plugi... ] James Perkins moved JBEAP-11564 to WFCORE-2958: ----------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2958 (was: JBEAP-11564) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Logging (was: Logging) Affects Version/s: (was: 7.1.0.ER1) Affects Testing: (was: Blocks Testing) > Composite operation on periodic-rotating-file-handler fails > ----------------------------------------------------------- > > Key: WFCORE-2958 > URL: https://issues.jboss.org/browse/WFCORE-2958 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > When performing composite operation on periodic-rotating-file-handler, it fails with [1] although individual steps passes. This affects Web Console form editing. > [1] > {code} > [standalone@localhost:9990 / #] run-batch > The batch failed with the following error (you are remaining in the batch editing mode to have a chance to correct the error): > WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed: > Step: step-1 > Operation: /subsystem=logging/periodic-rotating-file-handler=foo:undefine-attribute(name=formatter) > Failure: WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: Formatter "foo" is not found > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1615) Make the KieModule Serializable

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1615?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-1615: -------------------------------- Component/s: core engine Sprint: 2017 Week 24-25 > Make the KieModule Serializable > ------------------------------- > > Key: DROOLS-1615 > URL: https://issues.jboss.org/browse/DROOLS-1615 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1615) Make the KieModule Serializable

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1615: ----------------------------------- Summary: Make the KieModule Serializable Key: DROOLS-1615 URL: https://issues.jboss.org/browse/DROOLS-1615 Project: Drools Issue Type: Enhancement Reporter: Mario Fusco Assignee: Edson Tirelli -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2017