De Quanta RAM Precisa um Servidor de Minecraft?

O que decide realmente de quanta RAM precisas

São duas as alavancas que decidem de quanta memória um servidor de Minecraft precisa. Tudo o resto é ruído ao lado delas.

• O número de jogadores vai somando RAM aos poucos. Cada jogador ligado carrega os chunks à sua volta, por isso mais jogadores — e um view-distance mais alto — significam mais mundo retido em memória ao mesmo tempo. Passar de 4 para 20 jogadores é um aumento real, mas gerível.
• Os mods e os plugins são a grande alavanca, por larga margem. O vanilla é leve. Uma mão-cheia de plugins de Paper acrescenta um pouco. Um modpack é uma categoria à parte: cada mod carrega o seu próprio código, itens, blocos e geração de mundo para a memória antes de um único jogador entrar, e é por isso que um pack de 200 mods do CurseForge pode precisar de várias vezes a RAM de um servidor vanilla para o mesmo número de jogadores.

É este o modelo, por inteiro: o vanilla escala com os jogadores, o modded escala com os mods. O tamanho e a idade de um mundo também empurram o número para cima — um mapa vasto, com anos e muitos chunks carregados, custa mais do que um acabado de criar — mas é em torno dos jogadores e dos mods que dimensionas. Guarda uma coisa na cabeça à medida que continuas a ler: a RAM é apenas um dos recursos do servidor e, a partir de certo ponto, deixa de ser o que importa (mais sobre isso em porque mais RAM nem sempre é a solução).

De quanta RAM precisa um servidor de Minecraft, por configuração

Aqui está o dimensionamento em torno do qual construímos os planos — os mesmos números que daríamos a um amigo. "RAM a apontar" é o que atribuis ao servidor em si, não o total do teu PC, que ainda precisa de folga por cima (vê como a atribuir).

A correr um modpack e não tens a certeza em que banda cais? Tanto o tamanho do pack como o número de jogadores te empurram para cima na tabela — o guia de servidor de Minecraft com mods detalha os loaders e os tamanhos de pack ao pormenor.

Como dar essa RAM ao teu servidor

Saber o número é metade do trabalho; a outra metade é entregar mesmo essa memória ao servidor. Funciona de forma diferente consoante o sítio onde o servidor corre.

Auto-alojado: as flags -Xmx e -Xms

Quando és tu a lançar o jar do servidor, são duas as flags que controlam a sua memória. A -Xmx define o heap máximo (o teto) e a -Xms define o heap inicial. Para o Minecraft, o conselho comum e bem testado é defini-las iguais, para que a JVM reserve toda a sua memória logo de início em vez de a redimensionar sob carga:

java -Xms4G -Xmx4G -jar server.jar nogui

Essa linha arranca um servidor com 4 GB. Umas quantas coisas em que as pessoas tropeçam:

• Usa Java de 64 bits. O Java de 32 bits não consegue endereçar mais do que cerca de 1,5 GB, por isso, se o -Xmx4G se recusar a arrancar, é normalmente por causa disso. Qualquer build atual do Temurin ou do Java 25 é de 64 bits.
• Nunca dês toda a tua RAM ao servidor. Deixa pelo menos 1-2 GB para o sistema operativo, e mais se também correres o cliente de Minecraft no mesmo PC — o jogo precisa da sua própria memória, além da do servidor.
• Depois afina com as flags do Aikar. Assim que o básico funcionar, as "Aikar's flags", padrão da comunidade, reafinam o coletor de lixo G1 do Java para o padrão de memória do Minecraft, trocando um bocadinho de RAM por ticks visivelmente mais estáveis. São o passo seguinte habitual, depois de um -Xmx/-Xms simples. O passo a passo completo de auto-alojamento — jar, EULA, encaminhamento de portas e tudo o resto — está em Como Criar um Servidor de Minecraft.

Alojado: escolhe um tamanho, faz upgrade no mesmo sítio

Num servidor gerido não há flags para editar. Escolhes a RAM com um cursor quando encomendas, e o plano é aprovisionado com esse tamanho — as flags de arranque (as do Aikar incluídas) já vêm afinadas por ti.

A verdadeira vantagem aparece quando ultrapassas o teu primeiro palpite: na página de alojamento de Minecraft deslocas o cursor para cima e a RAM extra aplica-se ao mesmo servidor, com o mundo e as definições intactos — sem reinstalação, sem migração, feito em cerca de um minuto. É exatamente por isso que a regra prática lá em cima é "começa pequeno": num plano alojado, acrescentar RAM mais tarde não custa mais do que um minuto.

Sinais de que o teu servidor precisa de mais RAM

Não tens de adivinhar se o teu servidor está a passar fome. Ele avisa-te, de umas quantas formas fáceis de reconhecer:

• Os ticks ficam para trás. A consola imprime Can't keep up! Is the server overloaded? Running Xms behind, skipping Xs tick(s), e dentro do jogo isso aparece como rubber-banding, mobs a congelar e blocos que demoram um instante a partir.
• Guardar o mundo engasga. Um breve congelamento de poucos em poucos minutos, a coincidir com o autosave, quer muitas vezes dizer que o servidor está a lutar por memória.
• Crasha por completo. O sinal mais claro de todos é um crash cujo registo contém java.lang.OutOfMemoryError: Java heap space — o servidor pediu mais memória do que o teto do seu -Xmx permitia.

Para veres qual dos casos é, o profiler gratuito spark (executa /spark health ou /spark profiler) mostra os tempos dos ticks e o uso de memória, e um painel alojado desenha a RAM em direto num gráfico. Se a memória estiver colada ao teto, sobe de tamanho. Se a memória tiver espaço mas os ticks continuarem com lag, lê primeiro a secção seguinte.

Porque mais RAM nem sempre é a solução

Esta é a parte que a maioria dos conselhos de dimensionamento deixa de fora. O Minecraft corre o ciclo principal do jogo — o "tick" que move os mobs, faz crescer as plantações e processa a redstone — sobretudo numa única thread de CPU. A memória guarda o mundo; um núcleo faz o pensamento. Assim que o servidor tem RAM suficiente para guardar tudo, acrescentar mais não torna esse núcleo mais rápido.

Vale a pena interiorizar duas consequências:

• Se os ticks têm lag enquanto a RAM tem folga, o estrangulamento é a CPU, não a memória. Atirar 32 GB a um servidor preso num único núcleo não muda nada. Este é, de longe, o erro de dimensionamento mais comum que as pessoas cometem.
• RAM a mais pode até prejudicar. Um heap muito grande dá ao coletor de lixo do Java mais para varrer de uma só vez, o que pode transformar-se em pausas-engasgos mais longas — mais uma razão para a regra do "começa mais pequeno" se manter.

O que realmente faz a diferença quando a CPU é o limite é uma frequência de relógio elevada. É por isso que a HytHost corre o Minecraft em CPUs Ryzen e Intel i9 de frequência elevada, em vez de muitos núcleos lentos — ao Minecraft interessa a rapidez de um núcleo, não quantos existem. Do lado do software, podes aliviar a carga desse núcleo baixando o view-distance e o simulation-distance, pré-gerando os chunks do teu mundo, correndo Paper em vez de vanilla, ou acrescentando mods de desempenho como o Lithium numa configuração com mods. A RAM põe o teu mundo carregado; a CPU e as tuas escolhas de software decidem com que suavidade ele corre.