[Discuss] Some Java questions

[Eugene Gorelik]

Number of CPUs used by the app depends on the thread control in the app
itself or in the application container where this app is deployed.

Amount of used memory heap depends on the number of objects which are
loaded to the memory. Garbage collection process is regulated by JVM and I
don't think it is possible to manually set GC interval.
Therefore it is difficult to predict exactly when GC happens and to prevent
JVM from memory clean-up.
As always, you can experiment with putting load to the app and see how it
behaves.

if you think that problem is related to memory leak, then take a java heap
dump and analyze it using tool like IBM heap analyzer:
http://www-01.ibm.com/support/docview.wss?uid=swg21190608

Working closely with developer of the app should help a lot.


On Thu, Oct 25, 2012 at 1:37 PM, Jerry Feldman <gaf.linux at gmail.com> wrote:

> Thanks Eugene,
> I've passed the paper over to the guy who is working the issue. One thing
> we are seeing is that the app is only using 2 vCPUs. We just need to see
> how well we can map the configuration parameters we have to the specific
> Java flags. We have limited control over our guest OS via vSphere, but we
> have requested the VMs for this task to be 64GB/4 CPU which should be
> sufficient.
>
> On Thu, Oct 25, 2012 at 12:38 PM, Eugene Gorelik
> <eugene.gorelik at gmail.com>wrote:
>
> > Hi Jerry,
> >
> > JVM performance is a large topic for discussion.
> >
> > To begin with I'd recommend to read VMWare Best practices paper on how to
> > run Java within virtual machines:
> >
> >
> http://www.vmware.com/files/pdf/techpaper/Enterprise-Java-Applications-on-VMware-Best-Practices-Guide.pdf
> >
> > Based on my experience with running Java within virtual machines there
> are
> > few basic rules
> >
> >
> > 1) Memory allocation within VMs is expensive therefore:
> >
> > -  In VSphere set VM memory reservation.
> > -  set  java heap min memory = java heap max memory      -Xmx = -Xms
> > -  set permament size = max permament size   - XX:PermSize =
> > -XX:MaxPermSize
> >       As a rule of tumb I typically set PermSize to 30% of the Java heap
> > size, but it depends on your app
> >
> > 2) use concurrent mark sweep garbrage collector  -XX:+UseConcMarkSweepGC
> > (Note: this parameter depends on you app. pattern, but it
> > was usually helpful for me)
> >
> > 3) I'd not recommend to allocate large java heaps (generally > 4GB) for
> > Sun (Oracle) JVMs
> >     I saw increased GC pauses with larger heaps.
> >
> >     It is better to scale-out by adding few more JVMs rather than than
> > scale-up by increasing JVM heap
> >
> > 4) Definitely get more familiar with the apps which run on JVM and use
> > cool Visual monitoring tools for your JVM like VisualGC
> >
> > Best,
> > Eugene.
> >
> >
> >
> > On Thu, Oct 25, 2012 at 9:35 AM, Jerry Feldman <gaf.linux at gmail.com
> >wrote:
> >
> >> We have an important client-related Java issue. We are trying to
> reproduce
> >> a client's problem, but they are using a very large host (96GB/8CPU) and
> >> we
> >> just were able to upgrade a VM to 4CPUs and 64GB for this project. I
> would
> >> like to know if there are any good run-time tuning parameters that my
> >> coworker can set to use more of the memory. (We are using Java SE
> >> 1.6.0_14-b08). We are using the released version of our Java code. In
> this
> >> case, the issue for the customer is not performance, but we need better
> >> performance to give us some time to reproduce the problem. Currently
> >> through vSphere I see the VM only using about 12GB. I want the JVM to be
> >> able to use as much memory as it needs for the heap.
> >>
> >> --
> >> --
> >> Jerry Feldman <gaf.linux at gmail.com>
> >> Boston Linux and Unix
> >> PGP key id:3BC1EB90
> >> Key fingerprint: 49E2 C52A FC5A A31F 8D66 C0AF 7CEA 30FC 3BC1 EB90
> >> _______________________________________________
> >> Discuss mailing list
> >> Discuss at blu.org
> >> http://lists.blu.org/mailman/listinfo/discuss
> >>
> >
> >
>
>
> --
> --
> Jerry Feldman <gaf.linux at gmail.com>
> Boston Linux and Unix
> PGP key id:3BC1EB90
> Key fingerprint: 49E2 C52A FC5A A31F 8D66 C0AF 7CEA 30FC 3BC1 EB90
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>