Continuando a série de artigos contra algo contra algo, finalmente olhamos para algo útil, a saber, o servidor Minecraft. Considere qual sistema operacional e qual Java ainda é melhor para hospedar o melhor jogo da humanidade. Para comparação, foram utilizados o Ubuntu 18.04 LTS e o Server Core 2019. O OpenJDK foi instalado no Ubuntu e o Oracle Java e o AdoptOpenJDK foram instalados no Windows.
Como em todos os outros testes comparativos, as máquinas virtuais não tinham vizinhos; apenas uma VM estava sempre em execução no host.
Servidores iniciados com argumentos:
-Xmx8G -server
O componente Windows Defender foi removido no Windows Server Core, como em nossa imagem com o
Windows VDS por 99 rublos. Em comparação, é isso que você perde quando o deixa ligado.
Para cada uma das distribuições Java, foram instaladas as últimas versões publicamente disponíveis, a saber:
Oracle: "1.8.0_241"
AdoptOpenJDK: "1.8.0_242"
OpenJDK: "1.8.0_232"
Rodada número 1, a geração do mundo
Neste teste, geramos o mundo. O gerador foi Geographicraft com Biomes'O'Plenty, Árvores Dinâmicas, PVG, cavernas worley, IC e BC instalados.
O mundo não é de forma alguma um clássico e é gerado visivelmente mais lento que o normal.
Um mundo de 2.704 pedaços foi gerado:
O Windows com AdoptOpenJDK se afasta dos seus concorrentes por 5 segundos.
Rodada número 2, início do servidor
A medição ocorreu em três passagens para cada máquina virtual. Cada vez, cada um dos servidores concluía o download do mundo segundo por segundo em comparação com o resultado anterior.
O OpenJDK no Windows e o OpenJDK no Linux mostram os mesmos resultados.
Rodada número 3, memória ocupada
O processo começa a consumir mais memória, mais núcleos são instalados nele. Abaixo está uma tabela da memória ocupada de um processo de servidor vazio sem o mundo carregado nela.
O Oracle JRE consumiu uma média de 80 a 100 megabytes a mais em um número par de núcleos. O mesmo vale para AdoptOpenJDK, apenas em um número ímpar de núcleos.
O Linux não mostrou tanta estranheza.
Rodada No. 4, 32 frango em uma caixa 2 por 2
A cena é um cálculo da colisão de 32 galinhas em uma caixa de 2 por 2. A cena foi preparada com antecedência e o mesmo mundo foi espalhado pelos servidores para que tudo fosse honesto.
Um núcleo foi instalado para este teste e o processo foi definido como prioridade em tempo real.
O conjunto de trabalho do OpenJDK nessa cena foi 40 megabytes a mais do que seus rivais.
O consumo médio do processador para Oracle e AdoptOpenJDK é o mesmo, mas o lixo Oracle é coletado com mais frequência e intensidade, o que geralmente leva a explosões de atividade do processador.
Para extrapolar quantas cenas podemos processar, vamos apenas aumentar a taxa de ticks do servidor.
No teste de alta carga, o Ubuntu c OpenJDK alcançou o Windows c AdoptOpenJDk e a Oracle está atualizando.
Sob uma carga maior, o OpenJDK no Windows deu melhores resultados do que no Ubuntu.
O servidor OpenJDK no Ubuntu era constantemente apagado e a cena congelava. O Windows estava um pouco pior no mesmo OpenJDK. A Oracle, no entanto, lidou com o melhor com o menor número de congelamentos.
Entre outros, o Oracle SE manteve a mesma quantidade de RAM que o OpenJDK.
Arredondado No. 5, 64 * 64 chunk e árvores Dinâmicas
Esta cena contém uma floresta e várias dúzias de monstros. Quilômetros de árvores estão constantemente crescendo e atualizando a posição de seus blocos.
Cada árvore é um bloco separado, mas inicialmente possui uma baixa taxa de ticks, marcando apenas 1 vez em 20 ticks de jogo. Abaixo está um gráfico da utilização do processador por taxa de verificação do servidor.
O Ubuntu + OpenJDK e o Windows Server com Oracle a bordo não puderam iniciar o servidor nos argumentos discutidos anteriormente; portanto, eles não entraram no cronograma.
Para iniciar o servidor, tive que alterar os sinalizadores para:
-Xms4g -Xmx8G -server -XX:+UseCompressedOops -XX:+AggressiveOpts
Todas as três instâncias repousaram inicialmente em 100% do processador, mas apenas o Windows Server + AdoptOpenJDK não eliminou o servidor. Após a coleta de lixo, tudo voltou ao cronograma abaixo.
Ao alternar de uma taxa de tick de 60 para 70, no Ubuntu, o cronograma de carregamento da CPU começou a se comportar como uma onda senoidal, e é por isso que a utilização média da CPU de repente começou a cair devido à crescente complexidade da tarefa. Por esse motivo, o cronograma teve que ser interrompido onde está agora.
Essa é provavelmente a diferença entre o agendador do Linux e o Windows.
Conclusões:
Apesar da diferença objetiva nas distribuições de SO e JRE, é impossível fazer uma recomendação específica, objetivamente melhor para manter o servidor nele.
Nesse caso, provavelmente vale a pena escolher o sistema operacional com o qual você está mais familiarizado.
