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

Paper, plugins e leitura do mspt

# Servidor Paper com um TPS que consegue explicar

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

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

* São Paulo, Brasil
* Anti-DDoS até 400 Tbps
* NVMe

 Resposta rápida

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

## O 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 arranca sem recompilar. É por isso que a base instalada de EssentialsX, LuckPerms, Vault e WorldGuard continua a funcionar 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, funis. Nada disso torna o tick paralelo, o ganho vem de cada tick custar menos. Trocar o jar rende uma melhoria real e limitada, e o resto depende da configuração e de que plugins aceita carregar.

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

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

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

Vale ainda separar o lag de tick do lag de rede. Se o mspt está confortável e o jogador continua a sentir 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 ficheiros 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 pode ainda sobrepor o que quiser no próprio paper-world.yml. Tutorial antigo continua a mandar editar um paper.yml na raiz, que nessas versões já não existe.

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

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

## A armadilha da configuração copiada já feita

Aquele ficheiro otimizado que circula no fórum aplica dezenas de alterações de uma vez. Funciona no servidor de quem o escreveu. No seu, duas ou três daquelas chaves vão partir alguma coisa, e não terá como saber quais porque colou tudo junto.

Os estragos são previsíveis. Despawn demasiado curto somado a alcance de spawn reduzido gera a queixa clássica de que não nascem mobs para farmar. Alcance de ativação baixo demais faz o mob deixar de andar e a farm parar com ele. Tirar a inteligência aos mobs de spawner mata mecânicas que dependem de movimento. Raio de junção alto muda a forma como o drop se agrupa no chão. E trocar a implementação de redstone altera a ordem de atualização dos fios, o suficiente para uma contraption sensível ao 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, é o que consulta a base de dados 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 otimiza mesmo

* 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, funil 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 ciclo de tick continua numa só thread. A frequência por núcleo pesa mais do que o número de núcleos, e o Ryzen 9 9950X com DDR5 abre folga de mspt.

Casos de utilização

## Perfis de servidor em que esta escolha conta

* Survival com economia, proteção de terreno e registo de blocos, onde o estrangulamento é a escrita em disco dentro do tick, não a falta de RAM.
* Servidor de evento com pico de entidades, itens no chão e mobs concentrados numa região pequena.
* Spawn de autor cheio de redstone e funis, em que a configuração do mundo pesa mais do 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

* No server.properties, o simulation-distance corta trabalho de tick a sério. O view-distance custa largura de banda e envio de chunk, não processamento.
* No 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 entidades a mais.
* No spigot.yml, o entity-activation-range e o merge-radius têm efeito imediato, e são também os que mais partem farms quando exagera.
* As Aikar flags atuam na pausa do coletor de lixo da JVM, não no custo de plugin dentro do tick. Confundir as duas coisas queima tempo de diagnóstico.

 Ficha técnica

## Números para dimensionar antes de contratar

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

Linha Performance

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

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

A pagar por ano

R$ 48,60/mês no 4GB

O anual desconta 10% e o trimestral, 4%.

CPU atribuída

300% no plano de 4GB

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

Disco no plano de entrada

30GB NVMe

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

Avaliação pública

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

 Comparação

## Spigot, Paper e Purpur lado a lado

Os três correm plugins de Bukkit. A diferença está em quanto do servidor foi reescrito e em quanto de comportamento original 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, no 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 andar a ligar opções sem ler        |
| Quando escolher                           | Plugin muito antigo sem substituto | Padrão para servidor público com plugins | Quando personalizar mecânicas é o objetivo  |

O Paper é o meio-termo previsível. O Purpur só compensa se for usar as opções extra 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 na consola ou no painel. Abaixo de 50 com o jogador ainda a queixar-se, a investigação passa 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 para autosave, task agendada ou geração de terreno. Valor alto e constante aponta para entidades, funis ou código que corre em todo o evento.
3. 03

### Perfile durante o pico real
O timings foi reformado 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 o servidor vazio não mostra o que anda à procura.
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 ficheiros, conte entidades: itens no chão e animais acumulados explicam boa parte das quedas.
5. 05

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

 Lista de verificação

## Antes de aplicar uma configuração que encontrou já feita

Cinco verificações que evitam a semana perdida a descobrir que chave partiu o quê.

* Aponte o mspt mediano e o percentil 95 de agora, com o servidor cheio, para ter um antes.
* Faça cópia de segurança do mundo e da pasta config antes de editar qualquer ficheiro.
* Confirme a versão do Paper: material antigo cita ficheiros e chaves que já não existem.
* Divida as alterações por assunto, como entidades, chunk, redstone e rede, e aplique um grupo de cada vez.
* Teste as farms e as contraptions do spawn depois de mexer no alcance de ativação ou na redstone.

## Perguntas frequentes

01 Um plugin feito para Spigot funciona no Paper?

Funciona. O Paper preserva a API do Bukkit e do Spigot, por isso o jar arranca sem recompilar. O caminho inverso nem sempre vale: um plugin que use a camada exclusiva do Paper não corre em Spigot puro.

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

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

03 Como descobrir que plugin está a deitar o TPS abaixo?

A perfilar com o servidor em carga real. Um relatório agrupado por plugin às vezes acusa quem apenas disparou uma operação cara do próprio servidor, por isso confirme a pilha de chamadas antes de desinstalar seja o que for.

04 TPS a marcar 20 significa que está tudo bem?

Não necessariamente. O TPS tem teto nos 20, por isso um servidor a gastar 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 deita o servidor abaixo.

05 Vale a pena copiar uma configuração otimizada já feita?

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 itens mudam o spawn de mobs e o funcionamento das farms. Aplique em grupos pequenos e meça o mspt antes e depois de cada grupo.

 Continue por aqui

## Guias para executar o que está descrito aqui

* [Como reduzir lag num servidor Paper TPS e mspt na prática, com as chaves pela ordem em que valem a pena.](https://streethosting.com.br/pt-pt/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/pt-pt/guias/minecraft/spark-profiler-analisar-lag-minecraft)
* [Paper contra Spigot em produção O que muda no dia a dia quando troca o jar do servidor.](https://streethosting.com.br/pt-pt/guias/minecraft/paper-vs-spigot-servidor-minecraft)
* [Purpur contra Paper Quando as opções extra compensam e quando só criam bugs de jogabilidade.](https://streethosting.com.br/pt-pt/guias/minecraft/purpur-vs-paper-servidor-minecraft)

4.7/5 no Trustpilot

Garantia ou reembolso

Ativação em 60 s

Apoio Premium

Comprovado por mais de 2.500 clientes

## O que acompanha o plano

* Painel com consola, reinício e histórico de consumo, onde o pico aparece antes de virar queixa.
* Apoio em português habituado a ler perfis de desempenho e crash reports.
* Upgrade de RAM sem migração manual quando a economia e o registo de blocos crescerem.

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

Nenhuma configuração já feita substitui uma medição sua: meça, mude uma chave, meça outra vez.