0

I have a multithreaded Java program. I am dealing with certain perfomance problems.

I have improved everything. Hardware + Software. Now I think that it's time to move to proper Operating System.

I was wondering, what OS is the fastest for Java Virtual machine?

I am using Sun Java6. Do you think that Sun Solaris would be the best choice for Java applications? Or FreeBSD? or CentOS (I am using it currently)?

Thanks

2
  • 2
    Posting more information, such as top results during high load times, as well as the current hardware configuration and software you are using will help people give you better suggestions.
    – gekkz
    Jan 31, 2010 at 19:59
  • What is your bottleneck? You can't optimise anything if you don't know that.
    – Tobu
    Jan 31, 2010 at 20:47

5 Answers 5

0

JVM Performance does vary from platform to platform. Its has been a while since I evaluate jvm performance on various platforms, but when I last did few years ago, on JDK1.4, solaris was best. That time JVM in linux was still new and there were threading support issues. Things have changed a lot in JVM implementations.

Ofcourse there is no easy way to judge this, you have to choose ideal hardware platform and install Soaris, Linux etc on same machine and run some tests to evaluate it. JIT Implementation to support target CPU will also makes a difference.

Look into various extended JVM options supported by each platform, you will get a fair idea on how much optimization you may be able to do.

Also consider other JVMs such as JRockit or IBM JVM.

2

You will find very little(if any) improvement by switching the OS you are using, unless you're running some really old version right now, and even then it might not get you the performance gain you're looking for.

My guess is you're still limited by the hardware you're currently running, or perhaps your Java application is the main issue, and might be worth looking into before throwing more hardware at the problem.

1

Surprisingly Windows is the fastest platform for Java as it is the developers native platform, Solaris ending up on the worst side. On Linux you get to choose from Sun, IBM, OpenJDK, and BEA for your convenience.

The real answer is what is going to be the easiest and cost effective platform to manage, which is probably CentOS or Ubuntu Server.

2
  • 1
    Can you back up your windows comment with some actual benchmark facts and figures? May 6, 2010 at 8:50
  • spec.org/jbb2005/results/jbb2005.html I think Sun had published something ages ago on the topic, but probably before IBM released their faster JRE.
    – Steve-o
    May 6, 2010 at 9:34
0

There's almost nothing between different distros for their ability to execute Java applications.

However. You should choose an OS with support for modern hardware and chipsets (ie, a relatively new kernel), and a stable release schedule. CentOS is good, 5.4 being the latest release, supports some good new features, like native FUSE support.

I'd probably choose Ubuntu, regular releases every 6 months, a 3 year LTS release coming up in April, very new kernels and good patch releases, and good support for sun-java6.

Choose your OS for hardware performance and compatibility, support, and security offerings.

0

Of course you should performance-test this in your non-production hardware environment if you want a proper answer.

You should consider the support costs of having a multi-OS production environment, and factor them in to any COGS (Cost of goods sold) consideration when calculating how much performance benefit you get.

My guess is that any benefit you get is "not enough" to outweigh the additional cost of supporting multiple OSs in production. Talk to your operations team to find out.

Your efforts may be better spent trying to improve performance on the OSs that your Operations team already support in production. You can do tweaks to the OS as well as switching VM parameters and of course, fixing your code to make it more efficient :). You can also consider different hardware options. We've found that different kinds of CPU behave very differently on our workloads, which are not at all like those that typical benchmarks test.

You must log in to answer this question.