Calculadora de RAM para servidor de Minecraft

Quanta RAM um servidor de Minecraft precisa?

A maioria dos servidores Paper vai bem com 3 a 8 GB de heap: 3 ou 4 GB para um grupo de amigos, 5 ou 6 GB para 20 ou 30 jogadores com um conjunto normal de plugins, e 8 GB ou mais acima de 50 jogadores. O plano que você aluga precisa ser um pouco maior que isso, porque o Java também usa memória fora do heap.

A calculadora acima faz a mesma conta com os seus números. Use o resultado como ponto de partida: o uso real depende de quão espalhados estão os jogadores, da view distance e do que cada plugin faz.

Como a estimativa é calculada

A calculadora soma o heap, a memória que o Java dá ao Minecraft (a que você define com -Xmx):

• 2 GB de base para Paper ou Purpur com os mundos carregados e ninguém online. O Folia começa em 3 GB, porque é feito para muitos jogadores espalhados pelo mapa.
• 75 MB por jogador online ao mesmo tempo. Cada jogador mantém carregados os chunks em volta dele, com os mobs e itens que estão neles. Jogadores espalhados pelo mundo custam mais do que jogadores juntos num lobby.
• 40 MB por plugin, em média. A maioria dos plugins usa bem menos, e alguns usam bem mais.
• 2 GB a mais para plugins pesados ou mundo grande: mapas web (Dynmap, BlueMap), modelos personalizados (ItemsAdder, ModelEngine), muitos mobs ou farms, ou uma view distance acima de 10.
• Três quartos do total na 1.8 a 1.11, cujos chunks são mais leves.

O resultado é arredondado para cima em GB inteiros e nunca fica abaixo de 3 GB (2 GB na 1.8 a 1.11). O mínimo é mais ou menos dois terços disso: o servidor roda, mas com pouca folga para momentos de pico, geração de chunks novos ou backups. A calculadora para em 31 GB, porque acima de uns 32 GB o Java desliga os compressed object pointers, e passar um pouco disso deixa menos memória útil, não mais.

Esses números puxam para cima de propósito. Ficar sem memória faz o servidor travar e depois crashar, enquanto um pouco a mais só custa um pouco mais por mês.

Deixe espaço para o Java: heap e plano

O -Xmx só limita o heap. O Java também usa memória para as classes de todos os plugins, as threads, o código que ele compila, os buffers de rede e a contabilidade do próprio coletor de lixo. A calculadora reserva 1 GB ou 15 % do heap para isso, o que for maior, seguindo a recomendação do Paper de dar ao -Xmx de 1000 a 1500 MB a menos do que a memória que você tem. Na prática:

• Vai alugar um plano: guie-se pelo tamanho de plano que a calculadora mostra, não pelo heap. Um heap de 8 GB precisa de um plano de 10 GB.
• Já tem um plano: coloque ele em RAM do seu plano e as flags são dimensionadas para caber nele. Um plano de 8 GB deixa um heap de 6,5 GB.
• Pterodactyl, Docker e a maioria das hospedagens limitam o contêiner inteiro. Se o Java passar disso, o servidor é morto na hora, muitas vezes sem nenhum erro no console.
• Seu próprio PC ou VPS: deixe memória para o sistema operacional e para o que mais estiver rodando ali.

Por que -Xms é igual a -Xmx

As flags do Aikar dão o mesmo valor ao -Xms e ao -Xmx e adicionam -XX:+AlwaysPreTouch, que reserva o heap inteiro quando o servidor inicia. O G1 funciona melhor com um heap que nunca cresce nem diminui, e se a memória não existir de verdade, você descobre na inicialização. Um efeito colateral: o gráfico de memória do seu painel mostra o heap inteiro em uso desde o primeiro minuto. Isso é normal.

Flags do Aikar e ZGC

As flags do Aikar ajustam o coletor de lixo G1 ao jeito que o Minecraft usa a memória: uma quantidade enorme de objetos que vivem por um tick, e pausas que precisam ser curtas. O Paper recomenda essas flags, e elas servem para servidores de qualquer tamanho. Acima de 12 GB de heap, a calculadora passa a usar os valores do Aikar para heaps grandes: G1NewSizePercent=40, G1MaxNewSizePercent=50, G1HeapRegionSize=16M, G1ReservePercent=15 e InitiatingHeapOccupancyPercent=20.

O ZGC é outro coletor, que faz quase todo o trabalho enquanto o servidor continua rodando, então as pausas ficam abaixo de um milissegundo. Em troca, ele usa mais CPU, e só faz sentido em heaps grandes (16 GB ou mais) com núcleos sobrando. Use a versão geracional: no Java 21 ela precisa de -XX:+ZGenerational, e a partir do Java 23 é o padrão, então a calculadora deixa essa flag de fora. Se estiver em dúvida, fique com o G1.

Qual versão do Java

Esta é a tabela da documentação do Paper. Confira qual você tem com java -version. Se tiver várias instaladas, o script inicia a que o comando java executar.

Iniciando o servidor

1. Preencha jogadores, plugins, software e versão, e a RAM do seu plano se você já tiver um.
2. Escolha um Script de inicialização:
   • start.sh para Linux e macOS. Salve ao lado do jar, rode chmod +x start.sh uma vez e depois ./start.sh.
   • start.bat para Windows. Salve ao lado do jar e clique duas vezes nele. O pause no final deixa a janela aberta se o servidor parar, para você conseguir ler o erro.
   • Pterodactyl dá o comando de inicialização, com {{SERVER_JARFILE}} para o painel preencher o jar. Depois, defina no painel a memória do servidor com pelo menos o tamanho do plano.
   • Só as flags é para hospedagens com um campo para argumentos da JVM. Se a sua hospedagem define a memória sozinha, tire -Xms e -Xmx.
3. Clique em Copiar. Copiar link de compartilhamento guarda suas configurações no link.

Quando mais RAM não ajuda

O lag normalmente vem da CPU: um servidor normal faz a maior parte do trabalho numa só thread principal, então um núcleo mais rápido ajuda mais do que memória extra. Antes de fazer upgrade, rode /spark health para ver a memória e o TPS, e /spark profiler para ver o que está tomando o tempo. O spark vem com o Paper desde a 1.21. Diminuir view-distance e simulation-distance economiza memória e CPU ao mesmo tempo, e pré-gerar o mundo com um plugin como o Chunky evita os picos de gerar chunks novos enquanto o pessoal joga.