Vorteile/Nachteile der 64-Bit-JVM auf einem 64-Bit-Linux-Server?

Question

Wir führen die 32-Bit-Java-5-JVM von Sun auf 64-Bit-Linux-2.6-Servern aus, aber anscheinend ist dadurch der maximale Speicher pro Prozess auf 2 GB begrenzt. Es wurde daher vorgeschlagen, auf die 64-Bit-JVMs aufzurüsten, um diese Beschränkung aufzuheben. Derzeit betreiben wir mehrere JVMs (Tomcat-Instanzen) auf einem Server, um unter der 2-GB-Grenze zu bleiben, aber wir würden sie gerne konsolidieren, um die Bereitstellung zu vereinfachen.

Wenn Sie dies getan haben, können Sie bitte Ihre Erfahrungen teilen? Setzen Sie 64-Bit-JVMs in der Produktion ein? Würden Sie empfehlen, bei Java 5 zu bleiben, oder wäre es in Ordnung, sowohl auf Java 6 y 64 Bits gleichzeitig? Müssen wir mit Leistungsproblemen rechnen, entweder besser oder schlechter? Gibt es bestimmte Bereiche, auf die wir unsere Regressionstests konzentrieren sollten?

Danke für jeden Tipp!

Answer 1

In der Kepler Science Operations Center haben wir etwa 50 Rechner mit je 32-64G. Die JVMs haben in der Regel einen Heap von 7-20G. Wir verwenden Java 6. Das Betriebssystem hat einen Linux 2.6 Kernel.

Als wir auf 64bit migrierten, erwartete ich, dass es einige Probleme mit der 64-bit JVM geben würde, aber das war nicht der Fall. Zustände außerhalb des Speichers sind schwieriger zu debuggen, da die Heap-Dumps so viel größer sind. Die Java Service Wrapper mussten einige Änderungen vorgenommen werden, um größere Heapgrößen zu unterstützen.

Es gibt einige Seiten im Internet, die behaupten, dass GC nicht gut über 2G hinaus skaliert, aber ich habe keine Probleme gesehen. Schließlich arbeiten wir eher mit durchsatzintensiven als mit interaktiven Berechnungen. Ich habe mir die Latenzunterschiede noch nie angesehen; ich vermute, dass die GC-Latenz im schlimmsten Fall bei größeren Heaps länger sein wird.

Answer 2

Wir verwenden eine 64-Bit-JVM mit Heaps von etwa 40 GB. In unserer Anwendung werden viele Daten zwischengespeichert, was zu einer großen "alten" Generation führt. Die Standardeinstellungen für die Garbage Collection haben nicht gut funktioniert und mussten in der Produktion mühsam angepasst werden. Lektion: Stellen Sie sicher, dass Sie über eine angemessene Infrastruktur für Lasttests verfügen, bevor Sie eine solche Skalierung vornehmen. Nachdem wir die Fehler behoben hatten, war die GC-Leistung jedoch großartig.

Answer 3

Ich kann die Erfahrung von Sean bestätigen. Wir betreiben reines Java, rechenintensive Webservices (hausgemachte Jetty-Integration, mit heutzutage mehr als 1k Servlet-Threads und >6Gb geladener Daten im Speicher), und alle unsere Anwendungen skalierten sehr gut auf eine 64-Bit-JVM, als wir vor 2 Jahren migrierten. Ich würde empfehlen, die neueste Sun JVM zu verwenden, da der GC-Overhead in den letzten paar Versionen erheblich verbessert wurde. Ich hatte auch keine Probleme mit dem Wrapper von Tanukisoftware.

Answer 4

Jeder JNI-Code, den Sie geschrieben haben und der davon ausgeht, dass er in 32 Bit ausgeführt wird, muss erneut getestet werden. Für Probleme, die bei der Portierung von C-Code von 32 auf 64 Bit auftreten können, siehe diesen Link. Er ist nicht JNI-spezifisch, gilt aber trotzdem. http://www.ibm.com/developerworks/library/l-port64.html

Answer 5

Nach der Migration auf JDK6 64bits von JDK5 32bits (Windows Server), haben wir ein Leck im "perm gen space" Speicherblock. Nachdem wir mit den JDK-Parametern gespielt hatten, war das Problem behoben. Hoffentlich haben Sie mehr Glück als wir.