Poursuivant la série d'articles contre quelque chose contre quelque chose, nous regardons enfin quelque chose d'utile, à savoir le serveur Minecraft. Considérez quel système d'exploitation et quel Java est encore meilleur afin d'héberger le meilleur jeu de l'humanité. À titre de comparaison, Ubuntu 18.04 LTS et Server Core 2019 ont été pris. OpenJDK a été installé sur Ubuntu, et Oracle Java et AdoptOpenJDK ont été installés sur Windows.
Comme dans tous les autres tests comparatifs, les machines virtuelles n'avaient pas de voisins; une seule VM était toujours en cours d'exécution sur l'hôte.
Les serveurs ont commencé avec des arguments:
-Xmx8G -server
Le composant Windows Defender a été supprimé sur Windows Server Core, comme dans notre image avec
Windows VDS pour 99 roubles. En comparaison, c'est ce que vous perdez lorsque vous le laissez allumé.
Pour chacune des distributions Java, les dernières versions disponibles publiquement ont été installées, à savoir:
Oracle: "1.8.0_241"
AdoptOpenJDK: "1.8.0_242"
OpenJDK: "1.8.0_232"
Tour numéro 1, la génération du monde
Dans ce test, nous générons le monde. Le générateur était Geographicraft avec Biomes'O'Plenty, Dynamic Trees, PVG, grottes worley, IC et BC installés.
Le monde n'est en aucun cas un classique et est généré sensiblement plus lentement que d'habitude.
Un monde de 2 704 morceaux a été généré:
Windows avec AdoptOpenJDK se détache de ses concurrents pendant 5 secondes.
Tour numéro 2, démarrage du serveur
La mesure s'est déroulée en trois passes pour chaque machine virtuelle. A chaque fois, chacun des serveurs a terminé le téléchargement du monde seconde par seconde par rapport au résultat précédent.
OpenJDK sous Windows et OpenJDK sous Linux affichent les mêmes résultats.
Tour numéro 3, mémoire occupée
Le processus commence à consommer plus de mémoire, plus il y a de cœurs installés. Vous trouverez ci-dessous un tableau de la mémoire occupée d'un processus serveur vide sans le monde chargé dessus.
Oracle JRE a consommé en moyenne 80 à 100 mégaoctets de plus sur un nombre pair de cœurs. Il en va de même pour AdoptOpenJDK, uniquement sur un nombre impair de cœurs.
Linux n'a pas montré une telle bizarrerie.
Tour n ° 4, 32 poulets dans une boîte 2 par 2
La scène est un calcul de la collision de 32 poules dans une boîte 2 par 2. La scène a été préparée à l'avance et le même monde a été dispersé autour des serveurs pour que tout soit honnête.
Un cœur a été installé pour ce test et le processus a été défini sur la priorité en temps réel.
L'ensemble de travail OpenJDK dans cette scène était de 40 mégaoctets de plus que ses rivaux.
La consommation moyenne du processeur chez Oracle et AdoptOpenJDK est la même, mais les ordures Oracle se collectent plus souvent et plus intensivement, ce qui conduit souvent à des rafales d'activité du processeur.
Pour extrapoler le nombre de scènes que nous pouvons traiter, augmentons simplement le taux de tick du serveur.
Dans le test à haute charge, Ubuntu c OpenJDK a rattrapé Windows c AdoptOpenJDk, et Oracle rattrape son retard.
Sous une charge plus élevée, OpenJDK sur Windows a donné de meilleurs résultats que sur Ubuntu.
Le serveur OpenJDK sur Ubuntu s'est constamment effacé et la scène s'est figée. Windows était un peu pire sur le même OpenJDK. Oracle, cependant, a géré le mieux avec le moins de blocages.
Entre autres, Oracle SE a conservé la même quantité de RAM qu'OpenJDK.
Round No. 5, 64 * 64 chunk et Dynamic trees
Cette scène contient une forêt et plusieurs dizaines de monstres. Des kilomètres d'arbres grandissent constamment et mettent à jour la position de leurs blocs.
Chaque arbre est une tuile distincte, mais a initialement un faible taux de ticks, ne cochant qu'une seule fois en 20 ticks de jeu. Vous trouverez ci-dessous un graphique de l'utilisation du processeur par tickrate de serveur.
Ubuntu + OpenJDK et Windows Server avec Oracle à bord n'ont pas pu démarrer le serveur dans les arguments discutés précédemment, ils ne sont donc pas entrés dans le calendrier.
Pour démarrer le serveur, j'ai dû changer les drapeaux en:
-Xms4g -Xmx8G -server -XX:+UseCompressedOops -XX:+AggressiveOpts
Les trois instances reposaient initialement sur 100% du processeur, mais seul Windows Server + AdoptOpenJDK n'a pas supprimé le serveur. Après la collecte des ordures, tout est revenu à l'horaire ci-dessous.
Lors du passage d'un taux de tick de 60 à 70, sur Ubuntu, le calendrier de charge du processeur a commencé à se comporter comme une onde sinusoïdale, c'est pourquoi l'utilisation moyenne du processeur a soudainement commencé à baisser en raison de la complexité croissante de la tâche. Pour cette raison, le programme a dû être arrêté là où il est maintenant.
C'est probablement la différence entre le planificateur Linux et Windows.
Conclusions:
Malgré la différence objective dans les distributions OS et JRE, il est impossible de donner une recommandation spécifique, qui est objectivement meilleure afin de garder le serveur dessus.
Dans ce cas, il vaut probablement la peine de choisir le système d'exploitation que vous connaissez le mieux.
