Question

Assyst JVM out of memory / general memory usage after upgrade to 11.6.1

  • 11 May 2023
  • 5 replies
  • 183 views
philipploewen
Rank
Badge +1

We are using 7 Windows Servers with assyst Server installed behind an F5 load balancer for a maximum of 200 concurrend assystWEB and 30 concurrent assystNET users.
We also have another server running assystServer, IPaaS and Search Server. This one is not used by normal users.

Since upgrading to Assyst 11.6.1 last Friday we’ve been experiencing some “java.lang.OutOfMemoryError: GC overhead limit exceeded” on the 7 servers behind the load balancer which leads to the JVM restarting and all sessions on that server being killed.
This doesn’t happen on all the servers and is irregular.

We had all the JVMs for assyst Server configured to 6GB of memory as recommended by IFS on the Wiki. We decided to up the limit to 8GB which seems to be working for now but our JVM monitoring shows spikes to nearly 8GB which if reached would probably make it restart again. According to the wiki page from before we should need 50MB per user but we have way higher memory usage.

Has anyone be experiencing similar increased memory usage on 11.6.x?

How many assystWEB users are you able to get per server? How many assystNET users? What does your memory usage look like?

 
 

 

 

5 replies

C
Rank
Userlevel 3
Badge +12

Hello Philipp,
 

Could you log this with our support team in the normal manner so they can investigate this further for you.

How to contact the IFS assyst Support? | IFS Community


Kind Regards,

Caroline

morevalueit
Rank
Userlevel 1
Badge +1

Could is be, that the Release is per default deployed with “isDebugMode = true”?

Because the js-files are loaded from “/scripts/...” and not from “/scripts_release/...”
I have the same behavior in assyst v1.6.0 and 11.6.1.

In Version 11.5.* the js-Files are loaded from “/scripts_release/...”

morevalueit
Rank
Userlevel 1
Badge +1

This hack worked for me:


Insert the following Line in the File "assystEnterprise\standalone\deployments\assystEAR.ear\assystWEB.war\application.jsp" at the position, where the debug will be activated (between Lines 108-113):

            <c:set var="isDebugMode" value="false" />

That it looks like the following:
        <c:if test="${(assystDebugJs=='true' || param.assystDebugJs=='true') && param.assystDebugJs != 'false'}" var="isDebugMode">

            <%-- Store a session scoped var to override any application scoped one, so that all new windows in this session will

                 follow the same debug rules --%>

            <c:set var="isDebugMode" value="false" />

            <c:set var="assystDebugJs" value="true" scope="session"/>

            <c:set var="basePath" value="scripts"/>

        </c:if>

 

This is/was the original-content:

        <c:if test="${(assystDebugJs=='true' || param.assystDebugJs=='true') && param.assystDebugJs != 'false'}" var="isDebugMode">

            <%-- Store a session scoped var to override any application scoped one, so that all new windows in this session will

                 follow the same debug rules --%>

            <c:set var="assystDebugJs" value="true" scope="session"/>

            <c:set var="basePath" value="scripts"/>

        </c:if>
 

 

morevalueit
Rank
Userlevel 1
Badge +1

Additional Info:
The debug-parameters in the wrapper_standalone.conf is not working:
wrapper.java.additional.17=-Dassyst.debug.js=false

C
Rank
Userlevel 3
Badge +12

Hi All,

Karsten, thank you for your input.

I confirm that an incident has been logged with the support in order to investigate JVM out of memory the JVM out of memory as it might not be related to the debug mode you reported.
Regarding this , see the following article on our Knowledge section - 

 

Kind Regards,

Caroline

Reply


Terms & ConditionsCookie settings