Continuando con la serie de art铆culos contra algo contra algo, finalmente miramos algo 煤til, a saber, el servidor de Minecraft. Considere qu茅 sistema operativo y qu茅 Java es a煤n mejor para albergar el mejor juego de la humanidad. Para la comparaci贸n, se tomaron Ubuntu 18.04 LTS y Server Core 2019. OpenJDK se instal贸 en Ubuntu, y Oracle Java y AdoptOpenJDK se instalaron en Windows.
Como en todas las otras pruebas comparativas, las m谩quinas virtuales no ten铆an vecinos; solo una VM siempre se estaba ejecutando en el host.
Los servidores comenzaron con argumentos:
-Xmx8G -server
El componente de Windows Defender se elimin贸 en Windows Server Core, como en nuestra imagen con
Windows VDS por 99 rublos. En comparaci贸n, esto es lo que pierde cuando lo deja encendido.
Para cada una de las distribuciones de Java, se instalaron las 煤ltimas versiones disponibles p煤blicamente, a saber:
Oracle: "1.8.0_241"
AdoptOpenJDK: "1.8.0_242"
OpenJDK: "1.8.0_232"
Ronda n煤mero 1, la generaci贸n del mundo
En esta prueba, generamos el mundo. El generador fue Geographicraft con Biomes'O'Plenty, Dynamic Trees, PVG, worley caves, IC y BC instalados.
El mundo no es en absoluto un cl谩sico y se genera notablemente m谩s lento de lo habitual.
Se gener贸 un mundo de 2,704 trozos:
Windows con AdoptOpenJDK se separa de sus competidores durante 5 segundos.
Ronda n煤mero 2, inicio del servidor
La medici贸n se realiz贸 en tres pasadas para cada m谩quina virtual. Cada vez, cada uno de los servidores complet贸 la descarga del mundo segundo por segundo en comparaci贸n con el resultado anterior.
OpenJDK en Windows y OpenJDK en Linux muestran los mismos resultados.
Ronda n煤mero 3, memoria ocupada
El proceso comienza a consumir m谩s memoria, m谩s n煤cleos est谩n instalados en 茅l. A continuaci贸n se muestra una tabla de la memoria ocupada de un proceso de servidor vac铆o sin el mundo cargado en 茅l.
Oracle JRE consumi贸 un promedio de 80-100 megabytes m谩s en un n煤mero par de n煤cleos. Lo mismo ocurre con AdoptOpenJDK, solo en un n煤mero impar de n煤cleos.
Linux no mostr贸 tanta rareza.
Ronda No. 4, 32 pollos en una caja de 2 por 2
La escena es un c谩lculo de la colisi贸n de 32 gallinas en una caja de 2 por 2. La escena se prepar贸 de antemano y el mismo mundo se dispers贸 por los servidores para que todo fuera honesto.
Se instal贸 un n煤cleo para esta prueba, y el proceso se estableci贸 en prioridad en tiempo real.
El conjunto de trabajo OpenJDK en esta escena fue 40 megabytes m谩s que sus rivales.
El consumo promedio de procesador para Oracle y AdoptOpenJDK es el mismo, pero la basura de Oracle se recolecta con mayor frecuencia y m谩s intensidad, lo que a menudo conduce a explosiones de actividad del procesador.
Para extrapolar cu谩ntas escenas de este tipo podemos procesar, aumentemos la tasa de tics del servidor.
En la prueba de alta carga, Ubuntu c OpenJDK se puso al d铆a con Windows c AdoptOpenJDk, y Oracle se est谩 poniendo al d铆a.
Bajo una carga mayor, OpenJDK en Windows dio mejores resultados que en Ubuntu.
El servidor OpenJDK en Ubuntu se borr贸 constantemente y la escena se congel贸. Windows fue un poco peor en el mismo OpenJDK. Oracle, sin embargo, manej贸 lo mejor con la menor cantidad de congelaciones.
Entre otros, Oracle SE mantuvo la misma cantidad de RAM que OpenJDK.
Ronda No. 5, trozo 64 * 64 y 谩rboles din谩micos
Esta escena contiene un bosque y varias docenas de mobs. Kil贸metros de 谩rboles crecen constantemente y actualizan la posici贸n de sus bloques.
Cada 谩rbol es un mosaico separado, pero inicialmente tiene una baja tasa de tics, marcando solo 1 vez en 20 ticks de juego. A continuaci贸n se muestra un gr谩fico de la utilizaci贸n del procesador por tickrate del servidor.
Ubuntu + OpenJDK y Windows Server con Oracle a bordo no pudieron iniciar el servidor en los argumentos discutidos anteriormente, por lo que no entraron en el programa.
Para iniciar el servidor, tuve que cambiar las banderas a:
-Xms4g -Xmx8G -server -XX:+UseCompressedOops -XX:+AggressiveOpts
Las tres instancias inicialmente descansaban en el 100% del procesador, pero solo Windows Server + AdoptOpenJDK no solt贸 el servidor. Despu茅s de la recolecci贸n de basura, todo volvi贸 al horario a continuaci贸n.
Al cambiar de una tasa de tics de 60 a 70, en Ubuntu, el programa de carga de la CPU comenz贸 a comportarse como una onda sinusoidal, por lo que la utilizaci贸n promedio de la CPU de repente comenz贸 a caer debido a la creciente complejidad de la tarea. Debido a esto, el horario tuvo que detenerse donde est谩 ahora.
Esta es probablemente la diferencia entre el planificador de Linux y Windows.
Conclusiones:
A pesar de la diferencia objetiva en las distribuciones de OS y JRE, es imposible dar una recomendaci贸n espec铆fica, que es objetivamente mejor para mantener el servidor en 茅l.
En este caso, probablemente valga la pena elegir el sistema operativo con el que est谩 m谩s familiarizado.
