Vorteile/Nachteile beim Ausführen von 64-Bit-JVM auf 64-Bit-Linux-Server?

Question

Wir betreiben die 32-Bit Sun Java 5 JVM auf 64-Bit-Linux 2.6-Servern, aber das begrenzt unseren maximalen Speicher pro Prozess auf 2 GB. Daher wurde vorgeschlagen, auf die 64-Bit-JVMs zu aktualisieren, um die Einschränkung zu entfernen. Derzeit führen wir mehrere JVMs (Tomcat-Instanzen) auf einem Server aus, um unter der 2-GB-Grenze zu bleiben. Wir möchten sie jedoch im Interesse einer vereinfachten Bereitstellung konsolidieren.

Wenn Sie dies getan haben, können Sie bitte Ihre Erfahrungen teilen? Führen Sie 64-Bit-JVMs in Produktion aus? Würdest du empfehlen, bei Java 5 zu bleiben, oder wäre es in Ordnung, gleichzeitig auf Java 6 und 64 Bits zu wechseln? Sollten wir Leistungsprobleme erwarten, entweder besser oder schlechter? Gibt es bestimmte Bereiche, auf die wir unsere Regressionstests konzentrieren sollten?

Danke für irgendwelche Tipps!

Answer 1

Im Science Operations Center Kepler haben wir etwa 50 Maschinen mit jeweils 32-64G. Die JVM-Heaps sind typischerweise 7-20G. Wir verwenden Java 6. Das Betriebssystem hat Linux 2.6 Kernel.

Als wir auf 64bit migrierten, erwartete ich, dass es einige Probleme mit dem Ausführen der 64-Bit-JVM geben würde Aber wirklich gab es nicht. Nicht genügend Arbeitsspeicherbedingungen sind schwieriger zu debuggen, da die Heapspeicherauszüge so viel größer sind. Die Java Service Wrapper benötigt einige Änderungen, um größere Heap-Größen zu unterstützen.

Es gibt einige Seiten im Internet, die behaupten, dass GC nicht gut über 2G skaliert, aber ich habe keine Probleme gesehen. Schließlich machen wir ein durchsatzintensives, eher interaktives Intensivrechnen. Ich habe mich nie mit Latenzunterschieden beschäftigt; Meine Schätzung ist Worst Case GC Latenz wird länger mit den größeren Heap-Größen sein.

Answer 2

Wir verwenden eine 64-Bit-JVM mit Höhen von etwa 40   Gb. In unserer Anwendung werden viele Daten zwischengespeichert, was zu einer großen "alten" Generation führt. Die standardmäßigen Speicherbereinigungseinstellungen funktionierten nicht gut und erforderten einige mühsame Optimierungen in der Produktion. Lektion: Stellen Sie sicher, dass Sie über eine entsprechende Infrastruktur für die Belastungstests verfügen, bevor Sie auf diese Weise skalieren. Nachdem wir die Kniffe herausgefunden hatten, war die GC-Leistung großartig.

Answer 3

Ich kann Seans Erfahrung bestätigen. Wir betreiben Pure-Java, rechenintensive Web-Services (hausgemachte Jetty-Integration, heutzutage mehr als 1k Servlet-Threads und> 6Gb geladene Daten im Speicher), und alle unsere Anwendungen skalierten sehr gut zu einer 64-Bit-JVM, wenn wir vor 2 Jahren migriert. Ich würde empfehlen, die neueste Sun JVM zu verwenden, da in den letzten Releases eine wesentliche Verbesserung des GC-Overheads erzielt wurde. Ich hatte auch kein Problem mit dem Wrapper von Tanukisoftware.

Answer 4

Jeder JNI-Code, den Sie geschrieben haben und der davon ausgeht, dass er in 32 Bits läuft, muss erneut getestet werden. Bei Problemen, die bei der Portierung von c-Code von 32 auf 64 Bit auftreten können, siehe diesen Link. Es ist nicht JNI-spezifisch, gilt aber immer noch. http://www.ibm.com/developerworks/library/l-port64.html

Answer 5

Wenn Sie numactl --show verwenden, können Sie die Größe der Speicherbänke in Ihrem Server sehen. Ich habe festgestellt, dass der GC nicht gut skaliert, wenn mehr als eine Speicherbank verwendet wird. Dies ist mehr eine Hardware als ein Software-Problem IMHO, aber es kann Ihre GC-Zeiten alle gleich.

Answer 6

Nach der Migration zu JDK6 64Bits von JDK5 32Bits (Windows Server), haben wir Leck im "Perm gen Raum" Speicherblock. Nach dem Abspielen mit JDK-Parametern wurde es aufgelöst. Hoffe, du wirst mehr Glück haben, als wir sind.