Large Number of JVM's

[sjosborne]

I have developed an application that communicates with a message switch, via MQ, and writes data to several disperate systems (such as Oracle).

For each interactive session that is running the app a JVM is created, taking about 70Mb of Memory. Is it save to have about 40 of these running in memory at any one time or is this a rather large number to be running?

I think our system has about 14 Gb of Memory.

Thanks,
Stu

[vernond]

Re: Large Number of JVM's

How come a new JVM for each interactive session? Wouldn't it be a little less RAM costly to just instantiate a new instance, all running on one JVM? Or is that what you mean?

Describe your app a bit. If you're running with event handlers etc you shouldn't have such a huge RAM footprint.

[BenThurley]

Re: Large Number of JVM's

Each job that calls a Java program has to load a JVM. If you are running the Java interactively then that will be your interactive session job. A JVM can only be started once per job so if you want to pick up changed classes or use a different classpath then you must use a new job.

To reduce the number of jobs loading up JVM's you could set up a data queue with a bunch of batch jobs reading the queue and running the Java program. It depends whether your Java relies on running interactively. I.E. does it write out messages to the shell?

[MichaelCatalani]

Re: Large Number of JVM's

For each interactive session that is running the app a JVM is created, taking about 70Mb of Memory. Is it save to have about 40 of these running in memory at any one time or is this a rather large number to be running?

I think our system has about 14 Gb of Memory.

How were you able to determine that each job is utilizing a separate 70MB for each JVM?

[BenThurley]

Re: Large Number of JVM's

You might be able to approximate memory usage with a little program like this.

public class Performance
{
  public static void main(String[] args)
  {
    Runtime runtime = Runtime.getRuntime();  
   
    long maxMemory = runtime.maxMemory();  
    long allocatedMemory = runtime.totalMemory();  
    long freeMemory = runtime.freeMemory();  
   
    System.out.println("free memory: " + freeMemory / 1024);  
    System.out.println("allocated memory: " + allocatedMemory / 1024);  
    System.out.println("max memory: " + maxMemory /1024);  
    System.out.println("total free memory: " + (freeMemory + (maxMemory - allocatedMemory)) / 1024);  
  }
} 

http://blog.codebeach.com/2008/02/determine-available-memory-in-java.html

[sjosborne]

Re: Large Number of JVM's

How come a new JVM for each interactive session? Wouldn't it be a little less RAM costly to just instantiate a new instance, all running on one JVM? Or is that what you mean?

Describe your app a bit. If you're running with event handlers etc you shouldn't have such a huge RAM footprint.

Thanks for the reply Vernond,

Basically, my app makes card payment requests, securing funds from a customers credit/debit card. The card information is keyed onto the 5250 emulator. Once the user presses a function key the payments is requested byt sending an XML Message to a remote System that in turn sends a message to an external company to allocate the funds. Once allocated, a message is returned to the user informing them of a decline or authorisation of payment. At the point of getting this data back, we then invoke a stored procedure on another system to write the details to the oracle database which passes the data to our banking systems.

Our MQ Software is Java so we make the request by calling a single instance of a java class which makes the request and listens for a repsonse. The oracle stored procedure is perfomed using JDBC.

My concern is that I have a large number of JVM's and don't want to get performance issues on the system.

Cheers,
Stu

[sjosborne]

Re: Large Number of JVM's

Each job that calls a Java program has to load a JVM. If you are running the Java interactively then that will be your interactive session job. A JVM can only be started once per job so if you want to pick up changed classes or use a different classpath then you must use a new job.

To reduce the number of jobs loading up JVM's you could set up a data queue with a bunch of batch jobs reading the queue and running the Java program. It depends whether your Java relies on running interactively. I.E. does it write out messages to the shell?

Thanks Ben,

I'm aware that it creates one JVM per job - that's the concern I have as I think that this may be RAM intensive and am concerened that this approach may cause performance issues on the system.

I was toying with the idea of using a data queue with a number of batch jobs but was also concerened about reponse times for the user.

Does all of the JVM exist in RAM or does some of it reside in auxillary storage - meaning that it is only loaded to memory if/when a Java Class is called?

Unfortunately, I'm not a Java whizz, hence these fairly simple questions!

Thanks,
Stu

[sjosborne]

Re: Large Number of JVM's

How were you able to determine that each job is utilizing a separate 70MB for each JVM?

Hi Michael,

I used the calculations supplied by IBM which is to add the JIT and JVM values together, divide by 2 and add the heap.

I used the DMPJVM command to get these values.

Is there a better way to do this?

Also, is there a way I can see how much actual RAM has been used up on the iSeries?

Thanks,
Stu

[vernond]

Re: Large Number of JVM's

Eish (pronounced Aysh - South African word meaning Oops, Shucks, Gee Whizz, @#%@#%@#%@#% or all of the above). It can be tricky to maintain state whilst awaiting interplanetary messages like that.

We had a similar type of application and eventually settled on cutting user state when the transaction was submitted. The payment reply messages (when they got back to us) updated a user things-to-do file (using MQ triggers) from which the users continued their processes.

We found that there were just too many variables involved with maintaining state for the full duration of the messaging process.

[sjosborne]

Re: Large Number of JVM's

Eish (pronounced Aysh - South African word meaning Oops, Shucks, Gee Whizz, @#%@#%@#%@#% or all of the above). It can be tricky to maintain state whilst awaiting interplanetary messages like that.

We had a similar type of application and eventually settled on cutting user state when the transaction was submitted. The payment reply messages (when they got back to us) updated a user things-to-do file (using MQ triggers) from which the users continued their processes.

We found that there were just too many variables involved with maintaining state for the full duration of the messaging process.

Well ours is pretty good - our reponse times are in the region of 3 seconds to perform the full end to end function. My only concern is that when we go to Performance Testing that our design is not good in terms of memory usage. Therefore, I've gone down the road of creating a server type job, using data queues to allow the client (green screen) to talk to the Server job that runs a JVM. I've submitted 6 of these to batch and response times are still good (maybe a fraction slower than running the whole thing in an interactive session) - load balancing is performed automatically and creating a server program was a piece of cake!

[vernond]

Re: Large Number of JVM's

Cool, that's sounding a lot better overall!

I'm well impressed by the 3 second turnaround on the messaging. Our 3rd party lot were taking between 5 seconds and a few minutes to get back to us.