IS freezing

1

Hello everybody,

I just start my job on a wm project and and I have to face a critical issue :

In my configuration SAP send a batch of idocs to WM EAI.
I encouter a problem : at several time there is a problem of communication between Is and Broker. (IS doesn’t success in communicating with BS).
Then IS is freezing and can’t be accessed by a telnet.

I’m force to stop and restart the IS that causes a lost of idocs and interrupts the service.
(During the freeze CPU is at 25 percent.)

What can be the cause of the problem? The servers configuration (lack of CPU, memory…), a problem with a component, an corrupted idoc ?

thanks for your help.

Every advice is wellcomed!!

2

What versions of IS and Broker are you using? If using a version of IS < 6.0, what are you using to connect Broker and IS?

What is in the server and error logs at the time of the “freeze”? How much memory is allocated to IS in the JVM startup parameters?

How many IDocs are in the “batch” that is received prior to the freeze? How large are these docs?

If you run IS with verbose garbage collection, what is happening to the heap size and GC when the freeze occurs?

Mark

3

How many cpu’s do you have? If 4, then 25% cpu usage means, than one thread is using whole CPU (ex. trying to do GC).

You may also try to use jvmstat from Sun, esp. visualgc to investigate, if it is memory problem.

4

Yes, I have 4 CPU.
Can you explain me what a GC is please?

5

GC is garbage collection. The java virtual machine manages memory in a “heap”. Garbage collection is the process of reclaiming memory allocated to objects that are no longer needed (garbage).

There are many threads here on wMUsers related to managing java GC. Search for “verboseGC” and “System.gc()”. Those threads have links to information available on Sun’s website that describes Java GC in great detail.

You should probably find someone in your organization that understands java and JVM tuning to help you with this issue, at least until you are able to track down the root cause.

Mark