I'm setting up production server Windows 2008 64bit with 8gb ram and 4core xeon cpu. It will have some oracle services and Glassfish. I wonder if it's worth to install 64 bit jvm or stay with 32 bit?
We will run e-commerce application and preapre for 100 users/day. We also use jpa caching.
Would 64bit jvm be faster?
The HotSpot FAQ seems to imply that it would be slower if anything:
The performance difference comparing an application running on a 64-bit platform versus a 32-bit platform on SPARC is on the order of 10-20% degradation when you move to a 64-bit VM. On AMD64 and EM64T platforms this difference ranges from 0-15% depending on the amount of pointer accessing your application performs.
If your want to go with 32-bit then it makes sense especially if your plan is to setup 4 or 5 32-bit Glassfish servers as a cluster on the same system, each with a max of 1.25GB of RAM or so. Otherwise, you could run one 64-bit Glassfish server and it would theoretically be able to use up all 8GB of ram if your code needed it.
So, you could start with one Glassfish JVM, and as users come online, increasing load, you could add addtional JVMs to your cluster and also a NGINX/Tomcat server to load balance.
Related
Something wierd seems to be going on... I have an application on tomcat that used to be on a physical windows server 2008 standard 32-bit which I p2v'd with vmware converter over as a VM. I'm upgrading the server to windows server 2008 r2 64bit and instead of doing an inplace, I'm just building another one up and doing parallel side by side, and its a fresh VM from the start, no p2v stuff....
The strange part is I was able to set a max memory in the tomcat9w.exe configuration tool to about 1600 Megabytes and that was the hitting of the wall on that setup (the original physical one that I p2v'd to a VM), I can set less ram, but I cannot set it more than 1600 otherwise when I try to start the tomcat service in services.msc it will just crap outs.
So my thinking was since I have to stay on 32-bit of tomcat and 32-bit of Java JVM anyhow (long story...) that it might be better to put it in a 64-bit OS (server 2008r2) rather than the standard 32bit of server 2008. Long story short, from a fresh VM, on this box I'm only able to set a max total ram in tomcatw as around 1000 m (1GB) and if I set anymore it will not start, as in I cannot get tomcat service to start... so the wall is around 1GB...
As a test, I installed the tomcat (zip extract, not using msi or exe installer) to my own client workstation laptop running the latest windows 10 1809 etc and once again I hit the 1GB wall and cannot even get it to go up to 1.6GB, even though I have like 16GB ram on my laptop machine...
I have googled this for a long time and apparently it has to do with the way the operating system itself (in this case windows, be it windows server 2008 std, 2008 r2, or win10 etc) handles per process memory limitations and thread memory allocations that by default only allow around 1.5 to 2 g of ram per process and that this is what is constraining the tomcat apache jvm and not the programs itself....
But if this is indeed an OS difference, I checked on my original 32bit server2008 std, the one that I did P2V, and it didn't have anything special set in the boot.ini or any bcdedit parameters that allow it to see more ram per process nor anything like a /3GB flag etc etc
The only other thing I can think of is that maybe there is a difference between a VM and a physical raw bare metal box in how it allocates ram, and that I can get more contigous memory that tomcat/jvm requires when running on a 32bit OS on a physical box as opposed to and compared to a 64bit OS in a VM?
Why is it I can get the exact same version of Tomcat (bit by bit the same) to handle up to 1600m in 32bit version of server 2008 but on server 2008r2 64bit or even server 2016 64bit I can only get tomcat to do up to around 1GB total max? They are both using the same Java version jvm etc etc etc
See https://www.oracle.com/technetwork/java/hotspotfaq-138619.html#gc_heap_32bit:
Why can't I get a larger heap with the 32-bit JVM?
The maximum theoretical heap limit for the 32-bit JVM is 4G. Due to various additional constraints such as available swap, kernel address space usage, memory fragmentation, and VM overhead, in practice the limit can be much lower. On most modern 32-bit Windows systems the maximum heap size will range from 1.4G to 1.6G. On 32-bit Solaris kernels the address space is limited to 2G. On 64-bit operating systems running the 32-bit VM, the max heap size can be higher, approaching 4G on many Solaris systems.
As of Java SE 6, the Windows /3GB boot.ini feature is not supported.
If your application requires a very large heap you should use a 64-bit VM on a version of the operating system that supports 64-bit applications. See Java SE Supported System Configurations for details.
Raspberry Pi3 Raspberry Pi3 Odroid C2 Odroid XU4
1,20 GHz 1,20 GHz 1,5 GHz 2,0 GHz
Debian 32 Bit SuSE 64 Bit Ubuntu 64 Bit Ubuntu 32 Bit
Start Apache Tomcat 04:30,00 00:29,06 00:27,45 04:08,39
1. page (1. request) 00:50,00 00:03,91 00:03,66 00:24,75
1. page (2. request) 00:03,30 00:00,79 00:00,77 00:02,39
I'm working on an IoT kind of project and needed to test if some web frontend implemented in Java using Tomcat as web server is "fast enough" on our possible hardware. We need to choose between Raspberry Pi3, Odroid C2 and Odroid XU4. Pi3 and C2 both have a 64 Bit CPU with slightly different performance according to their specs, XU4 has a 32 Bit CPU only and should be faster as the other two in theory as well. The important thing is that Pi3 is by default running a 32 Bit OS even if it has a 64 Bit CPU, the XU4 is running 32 Bit as well, but the C2 is running a 64 Bit OS incl. 64 Bit Java etc.
Comparing all those devices in default settings we found that the C2 was significantly faster than the other both. It was 4+ minutes vs. ~30 seconds for a restart of Tomcat with some test application of ours. Additionally, tools like htop showed that most of the runtime all cores of the C2 were used, whereas Pi3 and XU4 were mostly only able to put one core under load. That great performance difference was the same after Tomcat has loaded and we were able to browse through our test app: It was ~1,5 seconds vs. 4 to 5,5 seconds for just browsing some page with some CSS/JS.
While the default OS for the Pi3 is 32 Bit only, we were able to successfully install a special 64 Bit SuSE distribution. And guess what happened? The performance was much closer now to what we saw on the C2 already, almost the same for many tests, even though the Pi3 is clocked at only 1,2 vs. 1,5 GHz of the C2. Especially interesting was that now all cores of the Pi3 were under load most of the time as well, so overall behaviour was very much like the C2 now.
So by only switching to 64 Bit OS, Java etc. we saw that dramatically improvement in performance. Everything else was the same, same test app, Tomcat etc., nothing overclocked, no other storage or else. How can that be? What is responsible for that dramatic improvement?
With a 64 Bit OS we see that all cores of the devices are more under load compared to 32 Bit. But why should the Linux kernel scheduler care about if it's running on 32 or 64 Bit this much?
And if it doesn't and the difference comes from Java, why/how that? Shouldn't a 32 Bit and 64 Bit JVM perform almost identically in such a simple test? Shouldn't both especially put almost the same load on cores and not behave that different? The architecture of the OS shouldn't have any effect on how many threads are used inside the JVM, that is mostly under control of Tomcat and our test app and therefore didn't change. According to what I've read about performance of 32 vs. 64 Bit Java, the difference should be negligible in my use case. Additionally, other users with a better performance of a 64 Bit JVM don't seem to have a factor of 4 to 5 like I'm seeing and the differences on CPU load of individual cores aren't explained as well.
Our test is not I/O bound, we don't allocate much memory or work with many threads or such, it's almost strictly CPU, only compiling Java classes and publishing HTML, CSS and JS. But we see very different load on the cores depending on 32/64 Bit and very different performance results.
One of my colleagues said he read somewhere that Java is internally working with 64 Bit values only and that therefore on a 32 Bit CPU/OS more cycles are needed to process the same thing. I guess his source doesn't mean really everything, but only references/pointers to memory like for objects. But I can't believe that a 32 Bit JVM is internally really using 64 Bit pointers for no reason, especially if even optimizations like compressed oops exist. But might be an explanation, so any ideas on that?
If it's of any interest, the packages on the 32 Bit OS all had "armhf" as architecture, compared to "arm64" on the 64 Bit ones. I thought that might have influence on how Java was built, maybe really using 64 Bit pointers for some weird reason?
Java was OpenJDK 8 always, same architecture like OS and as current as the package manager of the OS provides. Pi3 with SuSE had 1.8_144, UB provided 1.8_131 for both 32 Bit and 64 Bit installations, all were server VMs. Additionally, the Linux Kernel was different e.g. Pi3 with SuSE vs. C2 and XU 4 with UB: Pi3 had some current 4.x, C2 some old 3.14 and XU 4 some current 4.9 as well.
So, any ideas on where the difference comes from? Thanks!
You've told you installed OpenJDK 8 from the standard package.
There has never been an optimized build of OpenJDK 8 for ARM 32 (at least on Debian and Ubuntu). The default package is built from "Zero" port which does not even have a JIT compiler.
root#localhost:~# java -server -version
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-1~bpo8+1-b11)
OpenJDK Zero VM (build 25.131-b11, interpreted mode)
^^^^^^^ ^^^^^^^^^^^^^^^^
Try to install Oracle JDK manually from Java SE downloads page.
It has an optimized HotSpot JVM inside. And it indeed works much faster.
root#localhost:~# /usr/java/jdk1.8.0_131/bin/java -server -version
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) Server VM (build 25.131-b11, mixed mode)
^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^
On the contrast, Aarch64 port of HotSpot JVM has been a part of OpenJDK for a long time. So, on a 64-bit OS the default OpenJDK package comes with HotSpot JVM that includes an optimizing JIT compiler.
Years ago, I tried 64-bit JDK but it was really buggy.
How stable would you say it is now? Would you recommend it? Should I install 64-bit JDK + eclipse or stick to 32-bit? Also, are there any advantages of 64-bit over 32-bit other than bypassing the 4 GB memory limit?
Only begin to bother with that if you want to build an application that will use a lot of memory (namely, a heap larger than 2GB).
Allow me to quote Red Hat:
The real advantage of the 64-bit JVM is that heap sizes much larger than 2GB can be used. Large page memory with the 64-bit JVM give further optimizations. The following graph shows the results running from 4GB heap sizes, in two gigabyte increments, up to 20GB heap.
That, in a pretty graph:
See, no big difference.
See more (more graphs, yay!) in: Java Virtual Machine Tuning
I think the answer can be found pretty simple.
Answer the question: "Do I need more than 4GB of RAM?".
A 64 bit JVM is as stable as a 32 bit JVM. There are no differences. In fact a Java Application running in a 64 bit JVM will consume more RAM compared to a 32 bit JVM. All internal datastructures will need more RAM.
My eclipse is running in a 64bit JVM.
Are you going to deploy to a 32 or a 64 bit environment? If you're affinitized to an environment in production then your development environment should use the same environment type.
If you're platform agnostic, go with x64 and don't even think about it. The platform is mature and stable. It gives you tremendous room to scale up as you can just add memory and make your heaps bigger.
Nobody wants to tell a CEO, "Sorry, we chose x86 and can't scale up like we hoped. It's a month long project project to retest and replatform everything for x64."
The only differences between 32-bit and 64-bit builds of any program are the sizes of machine words, the amount of addressable memory, and the Operating System ABI in use. With Java, the language specification means that the differences in machine word size and OS ABI should not matter at all unless you're using native code as well. (Native code must be built to be the same as the word-size of the JVM that will load it; you can't mix 32-bit and 64-bit builds in the same process without very exotic coding indeed, and you shouldn't be doing that with Java about.)
The 64-bitter uses 64-bit pointers. If you have 4GB+ RAM, and are running Java programs that keep 4GB+ of data structures in memory, the 64-bitter will accommodate that. The big fat pointers can point to any byte in a 4GB+ memory space.
But if your programs use less memory, and you run the 64-bit JVM, pointers in will still occupy 64 bits (8 bytes) each. This will cause data structures to be bigger, which will eat up memory unnecessarily.
I just compiled a MQTT client in both the 32-bit JDK (jdk-8u281-windows-i586) and the 64-bit JDK (jdk-8u281-windows-x64). The class files produced had matching MD5 checksums.
FYI, it's perfectly safe to have multiple JDKs on your system. But if the version you use is important, you should be comfortable with setting your system path and JAVA_HOME to ensure the correct version is used.
I want to download Bea JRockIt 5 because the JRE doesn’t seem to be able to allocate VM more than 1.6 GB.
please i not find the link for download the JRockIT jre
I use machine 32 bits windows7 and ram 3GB.
Thanks in advance
The bottom line is that the limit you are seeing is not actually a JVM imposed limit. So changing to JRockit is not going to help.
Most 32-bit Windows operating systems limit the virtual memory for a user application (such as a JVM) to 2Gb. However, there is a boot switch for Windows Server 2003 that enables applications up to 3Gb ... on hardware that supports PAE : http://msdn.microsoft.com/en-us/windows/hardware/gg487508.aspx.
Your alternatives are:
If you are running Windows Server 2003 - do what the link says.
Switch to 32 bit Linux or 32 bit Solaris. Both allow more than 2Gb for user applications.
Switch to a 64 bit operating system.
I don't know why a simple Google search didn't suffice, but this is clearly available on OTN.
As far as allocation of memory for the JVM is concerned, it is unlikely that you will be able to get any amount more than 2GB. See this related question and the most voted answer.
I have a request to install a Linux server (preferably Ubuntu 64bit server),
and Java (64 bit) on the following machine:
Intel Core2Quad Q8200 - 2.33 GHz
8gb DDR2 ram
2x 320GB SATA HDD in soft RAID1 mirror (mirror)
The problem is how to configure system and Java because I need JVM to use more than 4gb of memory.
It cannot be distributed on many virtual machines. There is data more than 4GB large
and it has to be in memory because HDD is slow and performance is critical.
This is a configuration and performance question and I am interested in comments if anyone has experience?
thank you very much for helping me on this...
A 64 bit JVM should have no problem at all with giant heaps, certainly much larger than your available RAM. Just increase the heap size when you start the JVM, for example:
java -Xmx6g
You used to have to specify the 64bit flag (with -d64), but I don't think this is necessary any more.
32bit JVMs can manage something like 3GB of heap.
skaffman's answer which provides the required flag for allocating 6GB of memory is correct. If the 'g' does not do the trick you might want to try 6000m (check the link below for details on flags/platform)
For other options you can find useful information on all available options for the Java HotSpot VM here.
http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp
(Behavioral and performance options are available. Platform specific links also available on this page)
JVM (especially 64bit) does not hesitate taking all the memory, and 4Gb is not a problem. Just install 64-bit Ubuntu and default-jre package will also be 64 bit.
Also take special care about how your data is stored in memory. Again, 64-bit JDK is very hungry for memory due to higher overhead for pointers etc. so if you distribute these 4Gb in small chunks in some data structure, 8Gb will not be enough.
If you install a 64-bit Ubuntu, I believe that
sudo apt-get install sun-java6-jdk
gives you a 64-bit Java.
EDIT: The 64 bit Java can give you as much memory as you need with the appropriate switches. The limit is with the 32-bit JVM's which cannot go over 2-4 Gb depending on operating system.