Abend S0C4 when running hprof cpu profiler

M. Willemse · Post by **M. Willemse** » Wed Jun 01, 2005 5:36 am

I'm running JZOS 1.1.1 with Java SDK 1.3.1 20021114a under z/OS 1.5.

We have a big performance problem, the batch java application reads messages from DB2 and writes them to a MQSeries Queue using JDBC and JMS. Running under z/OS (JZOS) we have a thruput of 1.5 messages per second (using local connectors); under Linux x86 we have a thruput of 26 messages per second (using network connectors). This does not make much sense to me.

I tried to run the application by adding
"-Xrunhprof:cpu=samples,file=log.txt,depth=4 -Djava.compiler=NONE" in the IBM_JAVA_OPTIONS variable to analyze where the bottleneck is.

It does work when there are no messages to process, it abends S0C4 rsn 10 when there are even few messages to process (I assume it depends on the amount of data stored by the cpu profiler trace).

I tried to play with REGION, _CEE_RUNOPTS, and other parameters, but I always get the same result; it abends ONLY by activating hprof.

It may turn out that this is a problem of the Java Profiler Interface instead of a problem of JZOS, but because I was already in the forum to search for the problem I thought I would post it here anyway...

Post by **coz** » Wed Jun 01, 2005 5:59 am

Without looking at this in detail, what you describe sounds like a memory problem. The version of jzos that you are running is fairly old, but it does have the region reporting feature - setting the log level to '+I', will report this to the log. I'd start there to make sure you are getting what you think.

Post by **dovetail** » Wed Jun 01, 2005 8:26 am

If the JZOS storage report looks like you are getting the region sizes that you expect, you might also try turning on the following LE options:

// EXEC EXJZOSVM,
// LOGLVL='+I',
// LEPARM='RPTOPTS(ON),RPTSTG(ON)'

This will print out all of the LE options in effect, and a storage report that shows LE storage usage. If you are still having a problem, email a copy of the joblog from this job to dev@jzos.com and we'll take a look.

Guest · Post by **Guest** » Thu Jun 02, 2005 9:59 am

I've had mixed results with the profiler both with it operation and the results. I think the IBM support is iffy on it. You may need to go to 1.4.2 java level.

M. Willemse · Post by **M. Willemse** » Fri Jun 03, 2005 10:22 am

It's actually a problem on the JVM version I was using. I traced down the problem to be some sort of unhandled overflow in a counter (

) .

I now used FProfiler and found out that the performance problem was neither in db2 nor in mq but it was a programming fault (axis being initialized for every message).

Many thanks to Steave and Kirk for their help.

Marco