Method Server getting crash

[ptc-4258428]

Why I am getting the exception "RMI TCP Connection(idle)" java.lang.OutOfMemoryError: Java heap space" and for this the method server is getting crash.

For more clarification, there are 2 Application server and this is managed by a load balancer but still why maximum request is going to only one server only?

[ptc-4050265]

To begin with, what version of Windchill are you using and what environment is it running on?

[ptc-4258428]

The version is Windchill PDMLink 9.1 M60.

This is a clustered architecture. I mean to say there are replica servers, one background server and 2 application server. Background server is used for background process to run like different Queues. Application servers are used for application process like login request etc. Here we are using a hardware load-balancer.

[jessh]

The real questions with an out-of-memory error are:

1. What were you (or your users) doing at the time? Which operation(s)? With how much data?
2. How much memory was allocated to the process in question? What are the JVM settings in general?

This much should give those with experience some indication as to whether one should expect success with the memory you have allocated.

As for what's using the memory, that requires a heap dump and detailed analysis by technical folk, e.g. in the context of a customer support call. Any recent JVM should allow a heap dump to be acquired by adding -XX:+HeapDumpOnOutOfMemoryError and -XX:HeapDumpPath={path to directory or filename for heap dump} to the JVM options for the process in question (i.e. the method server in this case).

[ptc-4258428]

Answers,

1. Our users mainly perform Check-in , check-out, search operation through Pro E. The size of files varies from 100 KB to 100 MB.

2. I don't know how to get the JVM setting. If you guide then I will let you know.

[jessh]

How much memory things will take clearly depends on how many users are doing such operations at once. It also depends more on the number of objects (parts and assemblies) and number of attributes on those objects than on the file sizes.

As for getting memory allocation, look for the wt.method.maxHeap entry in wt.properties.

Beyond this I'd suggest talking to technical support.

[ptc-4258428]

I got the value of wt.method.maxHeap, it is set to 1360. But is it in KB or MB or what?

Regarding the number of user, it's around 1000 to 1500. But at a time it may be around 500 max.

[ptc-4050265]

that means you're allocating a maximum of 1.360GB to your MethodServer memory. That is next to nothing. We have both wt.method.maxHeap and wt.method.minHeap set at "5000" (5GB) to make sure we never crash.

See how much memory you have available on your server and then through the windchill shell, enter the new values for the min and max heaps in the following manner:

xconfmanager -s wt.method.maxHeap=<enter value here> -t codebase/wt.properties -p

Also, you can run WCA (Windchill Configuration Assistant) and it will set up some new settings on your server thatshould speed up your environment

[ptc-4258428]

But in my architecture we have 2 application server which are dedicated to habdle these request. Then why the requests are going to only one server only?

[ptc-4050265]

...now that's about when you definitely open up a PTC TS call on this issue. If the load balance is set up incorrectly, the tech support is the way to go.

[jessh]

The number is in MB. If you're on a 32-bit Windows system, then 1360 is about as much as you can possibly allocate (thanks to Windows fragmentation of the 32-bit address space). Recent versions of Windchill support 64-bit JVMs in which case a 64-bit JVM (and OS) should be used. Prior to that point UNIX was a better idea than Windows in that 32-bit JVMs on UNIX can be allocated much more heap.

All that said, it's still unclear what's producing your out-of-memory situation, but if it happens frequently I'd *guess* that 1360MB of memory isn't going to cut it for your use cases.

That's just a guess, of course. For more you should contact technical support.