cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

We are happy to announce the new Windchill Customization board! Learn more.

Java.exe not decreasing 10.2 m030 cps09

BrianToussaint
19-Tanzanite

Java.exe not decreasing 10.2 m030 cps09

Last week I updated my test server from 10.2 m020 csp08 to 10.2 m030 cps09.  After starting Windchill, the java.exe processes are staying constant in Memory size.  They are not releasing memory like they had been.  Is this something new or something broken?

6 REPLIES 6
TomU
23-Emerald IV
(To:BrianToussaint)

How are you testing this?  Heavily loading the server, watching the RAM balloon, then seeing if it drops back down???

BrianToussaint
19-Tanzanite
(To:TomU)

First I compared it to the numbers before upgrade and the production server which is still on m020.  In m020 the java processes would hang out at ~500,000-600,000 K.  I can see the memory increase when someone does something and then watch it drop a little after it goes idle.  In m030 the java processes increase to ~1,500,000 K when they are started and they just stay there.  There is no load on the system.  If I do a simple search, I see the CPU and memory increase on a java process but it just stays where ever it stops.

TomU
23-Emerald IV
(To:BrianToussaint)

I'm refreshing my test server as I write this.  I will do a little testing with CPS08 and then reapply CPS09.  I'll let you know what I find.

Memory allocation isn't controlled by Windchill, it's controlled by the JVM. A change to Windchill shouldn't affect the memory allocation behavior, though a change to Java or your JVM parameters could. The only way Windchill would affect this is if that memory is filled with active Windchill objects, and if Windchill is idle that should not be the case. You can check how much of the allocated memory is being actively used by looking at the GC log for your Method Server.

Though, the behavior you're seeing now is pretty normal. While the JVM can release previously allocated memory back to the OS, there are many reasons why it won't.

  • The JVM will not reduce its memory allocation below its -Xms size
  • The JVM will not reduce its memory allocation unless the amount of free space in the heap is greater then the value of -XX:MinHeapFreeRatio (default of 70%)
  • The JVM will only reduce its memory collection during a full GC.
  • The JVM will never reduce its memory allocation if you are using the Parallel or CMS GC collector

The last point is a common reason that prevents Java from reducing its memory size. Any system with multiple CPU cores should be using either the Parallel or CMS collector. And unless you're using a 32-bit OS, Java should default to the Parallel collector.

There is also no problem with Java not reducing its memory size. Both increasing and decreasing its memory allocation require Java to undergo full GC, which will pause the processing of Windchill threads for a short period of time. From a performance standpoint, its better to keep this memory allocated, because if Windchill required that memory at one point, it will likely need it again in the future. And if you're just looking for the amount of memory currently used by Windchill, then the GC logs will give you a much more accurate picture than the OS can.

KD
4-Participant
4-Participant
(To:BrianToussaint)

You can check the value of maxHeap and minHeap in wt.properties

Update.  Over the New Year break I upgraded my production server and it is not having the same issues.  The only thing different was that I did not run Microsoft updates on the production server.

Top Tags