---
title: "Servidor Minecraft Paper: diagnosticar e estabilizar TPS"
description: "Hospedagem para servidor Paper com foco no que derruba o tick: leitura de mspt, perfil com spark, chaves do paper-world-defaults.yml e o plugin culpado."
url: "https://streethosting.com.br/minecraft-paper"
type: "page"
language: "pt-BR"
---

Paper, plugins e leitura de mspt

# Servidor Paper com TPS que você consegue explicar

Paper é o fork de plugins que a maioria dos servidores públicos usa. Aqui o assunto é o que ele otimiza de verdade, quais chaves de configuração valem a mexida e como achar o plugin que come o tempo do tick.

[Ver planos para rodar Paper](https://streethosting.com.br/minecraft-pro#plans) [Entender TPS e mspt antes](https://streethosting.com.br/guias/minecraft/o-que-e-tps-minecraft-como-melhorar)

* São Paulo, Brasil
* AntiDDoS até 400 Tbps
* NVMe

 Resposta rápida

Paper é um fork do Spigot que mantém a API do Bukkit e reescreve partes caras do servidor, como carregamento de chunk e ticking de entidade. Na prática, o TPS de um servidor Paper depende muito mais de frequência por núcleo e de dois ou três plugins pesados do que da quantidade de RAM contratada.

## Paper é fork de plugin, e isso define o ecossistema

A linhagem é CraftBukkit, Spigot e Paper. Como o Paper preserva a API do Bukkit e do Spigot, o jar de um plugin compilado para Spigot sobe sem recompilar. É por isso que a base instalada de EssentialsX, LuckPerms, Vault e WorldGuard continua funcionando depois da troca.

O que o Paper acrescenta é implementação, não uma API nova incompatível: chunk reescrito, motor de luz, rastreio de entidade, hopper. Nada disso torna o tick paralelo, o ganho vem de cada tick custar menos. Trocar o jar rende uma melhora real e limitada, e o resto depende da configuração e de quais plugins você aceita carregar.

## mspt é a métrica, TPS é só o sintoma

O TPS tem teto em 20. Um servidor gastando 45 milissegundos por tick marca 20,0 e parece saudável, quando tem 5 milissegundos de folga. Basta uma explosão ou alguém explorando terreno novo para passar de 50 e o número despencar. Quem acompanha só o TPS descobre o problema depois do jogador.

Olhe a distribuição, não a média. Mediana baixa com percentil 95 alto indica pico periódico, e o suspeito costuma ser autosave, task agendada ou geração de terreno. Média alta com distribuição estreita indica carga constante, quase sempre entidade, hopper ou código que executa em todo evento de movimento.

Vale ainda separar lag de tick de lag de rede. Se o mspt está confortável e o jogador continua sentindo atraso, nenhuma chave de yml resolve.

## Onde mora a configuração e o que faz sentido tocar

A partir do Paper 1.19 a configuração foi dividida em dois arquivos dentro da pasta config: paper-global.yml, com o que vale para o servidor inteiro, e paper-world-defaults.yml, com os padrões dos mundos. Cada mundo ainda sobrescreve o que quiser no próprio paper-world.yml. Tutorial antigo continua mandando editar um paper.yml na raiz, que nessas versões não existe mais.

No arquivo global quase tudo fica no padrão, e o que justifica edição é integração com proxy, limitador de pacote e carregamento de chunk. Os ganhos que o pessoal procura estão no arquivo de mundo: faixas de despawn, mob por jogador, colisão, hopper e implementação de redstone.

A sobrescrita por mundo é o recurso mais subaproveitado. Um mundo de mineração aguenta despawn agressivo e simulação curta sem que ninguém reclame, enquanto o survival principal fica conservador. Aplicar a mesma configuração agressiva em todos os mundos transforma otimização em ticket de suporte.

## A armadilha da configuração copiada pronta

Aquele arquivo otimizado que circula em fórum aplica dezenas de mudanças de uma vez. Ele funciona no servidor de quem escreveu. No seu, duas ou três daquelas chaves vão quebrar alguma coisa, e você não terá como saber quais porque colou tudo junto.

Os estragos são previsíveis. Despawn muito curto somado a alcance de spawn reduzido gera a reclamação clássica de que não nasce mob para farmar. Alcance de ativação baixo demais faz o mob parar de andar e a farm parar junto. Tirar a inteligência dos mobs de spawner mata mecânica que depende de movimento. Raio de junção alto muda como o drop se agrupa no chão. E trocar a implementação de redstone altera a ordem de atualização dos fios, o bastante para uma contraption sensível a timing mudar de comportamento.

Aceite também que boa parte do ganho não está em yml nenhum. O plugin pesado quase nunca é o de jar maior, e sim o que consulta banco de forma síncrona a cada evento, varre entidades numa task repetida ou força carregamento de chunk fora do caminho assíncrono.

Infraestrutura

## O que o Paper realmente otimiza

* Carregamento e geração de chunk fora da thread principal, tirando do tick uma das operações mais caras do servidor original.
* Ticking de entidade, hopper e colisão com atalhos que o Spigot não tem, além de mobcap contado por jogador em vez de global.
* Uma camada de API própria sobre o Bukkit, que os plugins modernos usam para agendar trabalho sem travar o tick.
* O loop de tick continua em uma thread só. Frequência por núcleo pesa mais que contagem de núcleos, e a linha com Ryzen 9 9950X e DDR5 abre folga de mspt onde a DDR4 já está no teto.

Casos de uso

## Perfis de servidor em que essa escolha importa

* Survival com economia, proteção de terreno e log de bloco, onde o gargalo é escrita em disco dentro do tick, não falta de RAM.
* Servidor de evento com pico de entidade, item no chão e mobs concentrados numa região pequena.
* Spawn autoral cheio de redstone e hopper, em que a configuração de mundo pesa mais que o plano contratado.
* Backend de network atrás de proxy, onde cada instância precisa de mspt previsível para o proxy não acumular fila.

Otimização

## Chaves de configuração que valem a mexida

* Em server.properties, simulation-distance corta trabalho de tick de verdade. view-distance custa banda e envio de chunk, não processamento.
* Em paper-world-defaults.yml, as faixas de despawn, o per-player-mob-spawns e o limite de colisão por entidade resolvem a maioria dos casos de entidade demais.
* Em spigot.yml, entity-activation-range e merge-radius têm efeito imediato, e são também os que mais quebram farm quando você exagera.
* As Aikar flags atuam na pausa do coletor de lixo da JVM, não no custo de plugin dentro do tick. Confundir os dois queima tempo de diagnóstico.

 Ficha técnica

## Números para dimensionar antes de contratar

Dados de plano e de operação, sem estimativa.

Linha Performance

A partir de R$ 44/mês com 4GB DDR5

Ryzen 9 9950X, indicada quando o mspt já é dominado por plugin e entidade.

Linha Budget

A partir de R$ 34/mês com 4GB DDR4

Ryzen 9 5900XT. Cerca de 29% de diferença de preço para a linha DDR5 na mesma faixa de RAM, com menos clock por núcleo.

CPU liberada

300% no plano de 4GB

Três núcleos. O tick usa um, o restante atende chunk assíncrono, coleta de lixo e disco.

Disco no plano de entrada

30GB NVMe

Mantém autosave e leitura de arquivo de região longe do caminho crítico.

Teste antes de assinar

48 horas com 6GB e 30GB, sem cartão

Dá para subir o jar, instalar seus plugins e medir o mspt com gente dentro.

Avaliação pública

4,7 de 5 no Trustpilot, com 45 avaliações

 Comparativo

## Spigot, Paper e Purpur lado a lado

Os três rodam plugin de Bukkit. A diferença está em quanto do servidor foi reescrito e em quanto de comportamento original você aceita perder em troca.

| Item                                      | Spigot                             | Paper                                   | Purpur                                      |
| ----------------------------------------- | ---------------------------------- | --------------------------------------- | ------------------------------------------- |
| API de plugin                             | Bukkit e Spigot                    | Bukkit e Spigot, mais camada própria    | Tudo do Paper, mais extensões               |
| Chunk fora da thread principal            | Não tem                            | Tem                                     | Herdado do Paper                            |
| Chaves de desempenho                      | Poucas, em spigot.yml              | Muitas, separadas entre global e mundo  | As do Paper e dezenas de opções de mecânica |
| Risco de alterar o comportamento original | Baixo                              | Médio, conforme o que ativar            | Alto se sair ligando opção sem ler          |
| Quando escolher                           | Plugin muito antigo sem substituto | Padrão para servidor público com plugin | Quando customizar mecânica é o objetivo     |

Paper é o meio termo previsível. Purpur só compensa se você for usar as opções extras de propósito, e cada uma delas é uma decisão de jogabilidade antes de ser de desempenho.

 Passo a passo

## Fluxo para investigar uma queda de TPS

A ordem importa: cada passo elimina uma hipótese antes do seguinte.

1. 01

### Confirme que o problema é de tick
Veja o mspt no console ou no painel. Abaixo de 50 com jogador ainda reclamando, a investigação vai para rede, proxy ou cliente.
2. 02

### Leia a distribuição em vez da média
Compare o valor mediano com o percentil 95. Pico isolado aponta autosave, task agendada ou geração de terreno. Valor alto e constante aponta entidade, hopper ou código que roda em todo evento.
3. 03

### Perfile durante o pico real
O timings foi aposentado no Paper e o spark ocupou o lugar, embutido nas versões atuais e disponível como plugin nas antigas. Comece a amostra com o servidor cheio. Perfil com servidor vazio não mostra o que você está caçando.
4. 04

### Separe custo de plugin de custo de mundo
Veja se o tempo está em código de plugin ou no ticking de entidade e chunk do servidor. Antes de editar arquivo, conte entidades: item no chão e animal acumulado explicam boa parte das quedas.
5. 05

### Mude uma coisa e meça de novo
Aplique um ajuste, volte ao mesmo horário de carga e compare o mesmo percentil. Sem a segunda medição você não sabe se melhorou ou se o pico mudou de hora.

 Checklist

## Antes de aplicar uma configuração que você achou pronta

Cinco verificações que evitam a semana perdida descobrindo qual chave quebrou o quê.

* Anote o mspt mediano e o percentil 95 de agora, com o servidor cheio, para ter um antes.
* Faça backup do mundo e da pasta config antes de editar qualquer arquivo.
* Confira a versão do Paper: material antigo cita arquivo e chave que já não existem.
* Divida as mudanças por assunto, como entidade, chunk, redstone e rede, e aplique um grupo por vez.
* Teste as farms e as contraptions do spawn depois de mexer em alcance de ativação ou em redstone.

## Perguntas frequentes

01 Plugin feito para Spigot funciona no Paper?

Funciona. O Paper preserva a API do Bukkit e do Spigot, então o jar sobe sem recompilar. O caminho inverso nem sempre vale: plugin que usa a camada exclusiva do Paper não roda em Spigot puro.

02 Onde ficam os arquivos de configuração do Paper?

A partir do Paper 1.19 eles ficam na pasta config, separados em paper-global.yml, para o servidor inteiro, e paper-world-defaults.yml, para os mundos, com sobrescrita individual em paper-world.yml. Conteúdo antigo ainda cita um paper.yml na raiz, que nessas versões não existe.

03 Como descobrir qual plugin está derrubando o TPS?

Perfilando com o servidor em carga real. Relatório agrupado por plugin às vezes acusa quem apenas disparou uma operação cara do próprio servidor, então confira a pilha de chamada antes de desinstalar alguma coisa.

04 TPS marcando 20 significa que está tudo bem?

Não necessariamente. O TPS tem teto em 20, então um servidor gastando 45 milissegundos por tick ainda marca 20. Acompanhe o mspt: abaixo de 50 existe folga, e é o tamanho dessa folga que decide se o próximo evento pesado derruba o servidor.

05 Vale copiar uma configuração otimizada pronta?

Serve como lista de chaves para estudar, não para colar. Valores agressivos de despawn, de alcance de ativação e de junção de item mudam spawn de mob e funcionamento de farm. Aplique em grupos pequenos e meça o mspt antes e depois de cada grupo.

06 Preciso da linha DDR5 para rodar Paper?

Para começar, não. A DDR4 dá conta de survival pequeno com poucos plugins. A diferença aparece quando o mspt já ronda os 50 e a causa é código executando dentro do tick, porque aí só clock por núcleo compra folga.

 Continue por aqui

## Guias para executar o que está descrito aqui

* [Como reduzir lag em servidor Paper TPS e mspt na prática, com as chaves na ordem em que valem a pena.](https://streethosting.com.br/guias/minecraft/como-reduzir-lag-servidor-paper)
* [Analisar o lag com o spark profiler Como tirar a amostra e ler o resultado sem acusar o plugin errado.](https://streethosting.com.br/guias/minecraft/spark-profiler-analisar-lag-minecraft)
* [Paper contra Spigot em produção O que muda no dia a dia quando você troca o jar do servidor.](https://streethosting.com.br/guias/minecraft/paper-vs-spigot-servidor-minecraft)
* [Purpur contra Paper Quando as opções extras compensam e quando só criam bug de jogabilidade.](https://streethosting.com.br/guias/minecraft/purpur-vs-paper-servidor-minecraft)

4.7/5 no Trustpilot

Garantia ou Reembolso

Ativação em 60s

Suporte Premium

Comprovado por +2.500 clientes

## O que acompanha o plano

* Painel com console, reinício e histórico de consumo, onde o pico aparece antes de virar reclamação.
* Suporte em português acostumado a ler perfil de desempenho e crash report.
* Upgrade de RAM sem migração manual quando a economia e o log de bloco crescerem.

[Ver planos para rodar Paper](https://streethosting.com.br/minecraft-pro#plans) [Falar com o suporte](https://streethosting.com.br/contact)

Nenhuma configuração pronta substitui uma medição sua: meça, mude uma chave, meça de novo.
