Wenn wir die Artikelserie gegen etwas gegen etwas fortsetzen, schauen wir uns endlich etwas Nützliches an, nämlich den Minecraft-Server. Überlegen Sie, welches Betriebssystem und welches Java noch besser ist, um das beste Spiel der Menschheit zu hosten. Zum Vergleich wurden Ubuntu 18.04 LTS und Server Core 2019 verwendet. OpenJDK wurde unter Ubuntu installiert, und Oracle Java und AdoptOpenJDK wurden unter Windows installiert.
Wie in allen anderen Vergleichstests hatten virtuelle Maschinen keine Nachbarn, es wurde immer nur eine VM auf dem Host ausgeführt.
Server haben mit Argumenten begonnen:
-Xmx8G -server
Die Windows Defender-Komponente wurde auf Windows Server Core entfernt, wie in unserem Image mit
Windows VDS für 99 Rubel. Im Vergleich dazu verlieren Sie dies, wenn Sie es eingeschaltet lassen.
Für jede der Java-Distributionen wurden die neuesten öffentlich verfügbaren Versionen installiert, nämlich:
Oracle: "1.8.0_241"
AdoptOpenJDK: "1.8.0_242"
OpenJDK: "1.8.0_232"
Runde Nummer 1, die Generation der Welt
In diesem Test erzeugen wir die Welt. Der Generator war Geographicraft mit Biomes'O'Plenty, Dynamic Trees, PVG, Worley Caves, IC und BC.
Die Welt ist keineswegs ein Klassiker und wird spürbar langsamer als sonst erzeugt.
Eine Welt von 2.704 Stücken wurde erzeugt:
Windows mit AdoptOpenJDK hebt sich für 5 Sekunden von der Konkurrenz ab.
Runde 2, Serverstart
Die Messung erfolgte in drei Durchgängen für jede virtuelle Maschine. Jedes Mal hat jeder der Server den Download der Welt in Sekundenschnelle im Vergleich zum vorherigen Ergebnis abgeschlossen.
OpenJDK unter Windows und OpenJDK unter Linux zeigen die gleichen Ergebnisse.
Runde 3, belegter Speicher
Der Prozess beginnt, je mehr Speicher verbraucht wird, desto mehr Kerne sind darauf installiert. Unten sehen Sie eine Tabelle des belegten Speichers eines leeren Serverprozesses ohne die darauf geladene Welt.
Oracle JRE verbrauchte durchschnittlich 80-100 Megabyte mehr auf einer geraden Anzahl von Kernen. Das gleiche gilt für AdoptOpenJDK, nur für eine ungerade Anzahl von Kernen.
Linux zeigte keine solche Verrücktheit.
Runde Nr. 4, 32 Hühnchen in einer 2 x 2 Schachtel
Die Szene ist eine Berechnung der Kollision von 32 Hennen in einer 2 mal 2 Box. Die Szene wurde im Voraus vorbereitet und die gleiche Welt wurde auf die Server verteilt, so dass alles ehrlich war.
Für diesen Test wurde ein Core installiert und der Prozess auf Echtzeitpriorität gesetzt.
Das OpenJDK-Arbeitspaket in dieser Szene war 40 Megabyte größer als die Konkurrenz.
Der durchschnittliche Prozessorverbrauch bei Oracle und AdoptOpenJDK ist derselbe, aber Oracle-Garbage wird häufiger und intensiver gesammelt, was häufig zu Prozessorausbrüchen führt.
Um zu extrapolieren, wie viele solcher Szenen wir verarbeiten können, erhöhen wir einfach die Server-Tick-Rate.
Im Hochlasttest hat Ubuntu c OpenJDK Windows c AdoptOpenJDk eingeholt, und Oracle holt auf.
Unter einer höheren Last lieferte OpenJDK unter Windows bessere Ergebnisse als unter Ubuntu.
Der OpenJDK-Server unter Ubuntu wurde ständig gelöscht und die Szene fror ein. Windows war auf demselben OpenJDK etwas schlechter. Oracle hat jedoch am besten mit der geringsten Anzahl von Einfrierungen umgegangen.
Oracle SE hielt sich unter anderem im gleichen RAM-Bereich wie OpenJDK.
Runde Nr. 5, 64 * 64 Chunk- und Dynamic-Bäume
Diese Szene enthält einen Wald und mehrere Dutzend Mobs. Kilometerlange Bäume wachsen ständig und aktualisieren die Position ihrer Blöcke.
Jeder Baum ist ein separates Plättchen, hat jedoch anfangs eine niedrige Tick-Rate und tickt nur einmal in 20 Spiel-Ticks. Unten sehen Sie eine Grafik der Prozessorauslastung pro Server-Tickrate.
Ubuntu + OpenJDK und Windows Server mit Oracle an Bord konnten den Server in den zuvor diskutierten Argumenten nicht starten, so dass sie nicht in den Zeitplan kamen.
Um den Server zu starten, musste ich die Flags ändern auf:
-Xms4g -Xmx8G -server -XX:+UseCompressedOops -XX:+AggressiveOpts
Alle drei Instanzen waren anfänglich zu 100% auf dem Prozessor installiert, aber nur Windows Server + AdoptOpenJDK hat den Server nicht gelöscht. Nach der Müllabfuhr kehrte alles zum unten angegebenen Zeitplan zurück.
Beim Umschalten von einer Taktrate von 60 auf 70 unter Ubuntu begann sich der CPU-Ladeplan wie eine Sinuswelle zu verhalten, weshalb die durchschnittliche CPU-Auslastung aufgrund der zunehmenden Komplexität der Aufgabe plötzlich zu sinken begann. Aus diesem Grund musste der Zeitplan dort angehalten werden, wo er jetzt ist.
Dies ist wahrscheinlich der Unterschied zwischen dem Linux-Scheduler und Windows.
Schlussfolgerungen:
Trotz des objektiven Unterschieds bei den Betriebssystem- und JRE-Distributionen ist es unmöglich, eine bestimmte Empfehlung abzugeben, die objektiv besser ist, um den Server auf dem Laufenden zu halten.
In diesem Fall lohnt es sich wahrscheinlich, das Betriebssystem auszuwählen, mit dem Sie besser vertraut sind.
