Como reduzir o lag em servidores de Tibia: 15 dicas que funcionam

Lag em OTServ é um sintoma, não um problema. E é aí que quase todo dono de servidor se perde: o jogador reclama que "está lagando", e a reação instintiva é subir de plano. Às vezes resolve. Na maioria das vezes, some o dinheiro e o lag continua.

Porque "lag" no vocabulário do jogador cobre pelo menos quatro coisas completamente diferentes: o personagem demora para responder, o mundo inteiro engasga por dois segundos, a conexão cai, ou o servidor demora para carregar. Cada uma tem causa própria e conserto próprio.

Este guia separa as 15 causas reais, explica como identificar cada uma pelo comportamento e diz, em cada caso, se você está diante de um problema de configuração ou de falta de hardware. Essa distinção é o que economiza dinheiro.

Antes de tudo: aprenda a ler o sintoma

Faça esta pergunta antes de qualquer ajuste: o problema é de todo mundo ao mesmo tempo, ou só de alguns jogadores?

Se é de todo mundo simultaneamente, o servidor engasgou. Causa interna: processador, memória, script, banco.

Se é só de alguns, e esses alguns estão sempre nas mesmas regiões, é rede. O servidor está fino, o caminho até o jogador é que não está.

Se piora conforme enche, é escala: alguma coisa que funcionava com 30 pessoas não funciona com 120.

Se acontece em horário fixo, é tarefa agendada, backup ou save rodando junto.

Essa triagem de trinta segundos já elimina metade das hipóteses.

Causas ligadas a hardware

1. VPS lenta ou mal dimensionada

Sintoma: lentidão constante, presente mesmo com poucos jogadores online, sem picos definidos.

Este é o caso em que trocar de máquina realmente resolve, e é justamente o menos comum entre os que reclamam.

O engano mais frequente é comparar planos por quantidade de núcleos. Um OTServ concentra a lógica do jogo, então clock por núcleo pesa muito mais que quantidade de núcleos. Um processador antigo de servidor, com dezesseis núcleos a 2,1 GHz, entrega pior num OTServ que um processador moderno com quatro núcleos a 4,5 GHz.

Como confirmar: com o servidor rodando e poucos jogadores, olhe o uso de processador. Se um núcleo já vive acima de 70% com o servidor quase vazio, a máquina está no limite antes mesmo da carga chegar.

Configuração ou hardware: hardware, se e somente se o teste acima confirmar.

2. CPU sobrecarregada

Sintoma: o servidor inteiro trava por um a três segundos, todo mundo sente ao mesmo tempo, e depois volta ao normal.

Diferente do caso anterior, aqui a máquina dá conta na média mas não dá conta nos picos. Alguma coisa consome muito processamento de uma vez.

Os suspeitos habituais, em ordem:

• Spawn de muita criatura simultânea, tipicamente em invasão ou evento
• Script rodando em loop curto sobre muitos objetos
• Guerra de guild com dezenas de jogadores trocando dano na mesma tela
• Save do mundo em servidor com muitos jogadores e casas

Como confirmar: acompanhe o uso de processador enquanto o travamento acontece. Se um núcleo satura a 100% no exato instante do engasgo e volta depois, é pico de carga, não falta de máquina.

Configuração ou hardware: quase sempre configuração. Só vire hardware depois de descartar script.

3. Memória insuficiente

Sintoma: o servidor fica progressivamente mais lento ao longo das horas, e um reinício resolve por um tempo.

Esse padrão é característico. Se reiniciar melhora, o problema é acúmulo, e memória é o suspeito principal.

No Tibia isso pesa mais que em outros jogos porque o mapa inteiro é carregado na memória quando o servidor sobe. Mapa customizado grande já ocupa uma fatia considerável antes do primeiro jogador entrar. Some o MySQL, que usa memória livre como cache, e o site da comunidade rodando junto.

Quando a memória acaba, o sistema começa a usar disco como memória. É aí que a lentidão vira travamento.

Como confirmar: monitore a memória ao longo de algumas horas. Se ela sobe e nunca desce, e o uso de swap começa a crescer, você achou.

Configuração ou hardware: pode ser os dois. Se o consumo cresce sem parar, há vazamento em algum script. Se ele estabiliza num valor alto demais para o plano, é hardware.

4. Disco lento, sem NVMe

Sintoma: demora para carregar ao entrar, travadas ao abrir depot cheio, save do mundo derrubando o desempenho.

O disco entra na conta em três momentos: quando o servidor sobe e lê o mapa, quando o banco responde consulta, e quando o mundo é salvo.

A diferença entre HDD, SSD SATA e SSD NVMe aparece exatamente nesses picos. Num servidor com muitos jogadores e muitas casas, o save periódico é uma operação pesada de escrita, e em disco lento ele trava o mundo enquanto acontece.

Como confirmar: se as travadas coincidem com o intervalo de save configurado, o disco é o gargalo.

Configuração ou hardware: hardware, com atenuante. Espaçar o save ajuda, mas é remendo.

Causas ligadas ao software do servidor

5. Banco de dados mal configurado

Sintoma: travadas ao salvar personagem, ao abrir highscore no site, ao entrar e ao sair do jogo.

Este é, na minha experiência, o item mais subestimado da lista. O banco de dados faz parte do caminho crítico do jogo: cada login, cada logout, cada save de personagem passa por ele.

Os problemas mais comuns:

• Tabelas sem índice adequado, fazendo o banco varrer registro por registro
• Tabela de histórico crescendo sem limpeza, com meses de log acumulado
• Configuração padrão do MySQL, que reserva pouca memória para cache
• Site da comunidade fazendo consulta pesada a cada visita, sem cache

Uma tabela de players com dezenas de milhares de registros e sem índice transforma cada login numa operação cara.

Como confirmar: ative o log de consultas lentas do MySQL por algumas horas e veja o que aparece. Costuma haver dois ou três culpados repetindo.

Configuração ou hardware: configuração, na imensa maioria dos casos.

6. Scripts pesados

Sintoma: travadas em situações específicas e reproduzíveis, sempre ligadas a uma ação, item, área ou evento.

Esta é a causa número um de lag em servidor de Tibia, com folga. E é a que menos gente investiga, porque exige olhar código.

Os padrões que mais aparecem:

• Loop com intervalo curto demais, rodando a cada poucos milissegundos
• Varredura de todos os jogadores online dentro de um evento frequente
• Consulta ao banco dentro de loop, quando bastaria uma consulta fora
• Script de evento que não é encerrado quando o evento termina, e fica rodando para sempre
• addEvent acumulando sem limpeza

Como confirmar: identifique um travamento reproduzível e vá desabilitando scripts suspeitos até ele parar. É trabalhoso, mas é conclusivo. Servidores que guardam log com marcação de tempo conseguem cruzar o horário do engasgo com o que estava executando.

Configuração ou hardware: configuração, sempre. Nenhuma máquina resolve loop infinito.

7. Monstros demais no mapa

Sintoma: lag proporcional à quantidade de criatura ativa, pior em áreas com spawn denso.

Cada monstro no mapa custa processamento contínuo: caminhar, procurar alvo, verificar condição, decidir ação. Multiplique por milhares e vira carga permanente.

Duas armadilhas comuns:

• Spawn com tempo de respawn muito curto, mantendo densidade alta o tempo todo
• Mapa customizado com áreas de spawn esquecidas, cheias de criatura que ninguém caça

Como confirmar: compare o uso de processador com o servidor vazio e com o servidor vazio mas com os spawns ativos. A diferença é o custo do mundo em si.

Configuração ou hardware: configuração. Ajustar densidade e tempo de respawn costuma dar ganho imediato.

8. Muitos jogadores para o dimensionamento

Sintoma: tudo funciona bem até certo número de pessoas online, e a partir dali degrada rápido.

Este é o caso legítimo de crescer a máquina, e ele tem uma assinatura clara: o desempenho é bom e estável abaixo de um limiar, e ruim acima dele.

Antes de aceitar essa conclusão, confirme que o limiar não é causado por script que varre todos os jogadores. Esse tipo de script tem custo que cresce rapidamente com a quantidade de gente, e imita perfeitamente um problema de hardware.

Como confirmar: anote a quantidade de jogadores online no momento em que o desempenho começa a cair. Se o número é consistente, e o uso de processador acompanha de forma proporcional, é escala real.

Configuração ou hardware: hardware, se os scripts estiverem limpos.

Causas ligadas a rede

9. Ping alto por distância

Sintoma: atraso constante entre a ação e a resposta, sentido por um grupo específico de jogadores, sem travadas no servidor.

Aqui não há travamento nenhum. O servidor está respondendo perfeitamente. O que demora é o pacote ir e voltar.

Esse é o tipo de lag que nenhuma configuração conserta, porque o limite é distância física. Servidor hospedado no exterior sempre vai entregar latência maior para jogador brasileiro, independente de quantos núcleos tenha.

E no Tibia isso pesa mais que em outros jogos, porque o combate é feito de reação: sair do wave na hora, dar o exori no tempo certo, fugir da trap. Cem milissegundos a mais mudam o resultado.

Como confirmar: peça para os jogadores rodarem um teste de latência para o IP do servidor. Se os números são altos mas estáveis, é distância. Se oscilam muito, é qualidade de rota.

Configuração ou hardware: localização da hospedagem. Os números estão em por que hospedar no Brasil faz diferença.

10. Firewall mal configurado

Sintoma: quedas intermitentes, jogadores caindo em momentos aparentemente aleatórios, reconexão frequente.

Firewall costuma ser lembrado só quando bloqueia tudo. Mas configuração parcialmente errada gera problema mais difícil: conexão que funciona e cai.

Os casos que aparecem:

• Regra de saída ausente, deixando a comunicação funcionar num sentido só
• Limite de conexões simultâneas por IP baixo demais, derrubando jogadores que compartilham conexão
• Inspeção profunda de pacote interferindo no protocolo do jogo

Como confirmar: desative temporariamente as regras específicas, num horário de baixo movimento, e veja se as quedas cessam. Se cessarem, reative uma a uma.

Configuração ou hardware: configuração. O passo a passo correto está em como abrir uma porta na sua VPS e, no Linux, em como ativar o firewall e liberar portas.

11. Ataque DDoS em andamento

Sintoma: lentidão severa e súbita, sem aumento correspondente de uso de processador, muitas vezes com jogadores caindo em massa.

A assinatura que distingue DDoS de sobrecarga é essa: a máquina não está trabalhando mais, mas está inacessível. Se o processador está tranquilo e o servidor está inalcançável, o problema não é interno.

Servidor de jogo tem IP público e recebe ataque automatizado com frequência. Não é preciso ser um servidor grande para virar alvo.

Como confirmar: olhe o volume de tráfego de entrada. Um salto brusco sem aumento correspondente de jogadores é o indicador.

Configuração ou hardware: proteção da hospedagem. A diferença entre mitigação real e simples descarte de tráfego está em como proteger o servidor de Tibia contra DDoS.

Causas ligadas a manutenção

12. Sistema e distribuição desatualizados

Sintoma: problemas de desempenho que a comunidade já resolveu, e você continua enfrentando.

Distribuições de OTServ recebem correção de desempenho com frequência. Um memory leak conhecido, uma consulta otimizada, um ajuste no tratamento de rede. Rodar uma versão de dois anos atrás significa carregar bugs que já têm conserto.

O mesmo vale para o sistema operacional e para o MySQL.

Ressalva importante: atualizar distribuição de OTServ não é trivial, porque o datapack precisa acompanhar. Faça em ambiente de teste antes, sempre.

Configuração ou hardware: manutenção.

13. Falta de reinício programado

Sintoma: desempenho que degrada ao longo de dias e melhora após reinício manual.

Isto não é solução de causa, é gestão de sintoma, e vale dizer isso com todas as letras. Um servidor bem construído não deveria precisar reiniciar.

Mas na prática, com dezenas de scripts de origens diferentes, algum acúmulo acontece. Um reinício diário em horário de baixo movimento, tipicamente entre 5h e 7h da manhã, evita que o acúmulo chegue no horário de pico.

Boas práticas ao automatizar:

• Avise no jogo com antecedência de alguns minutos
• Force o save do mundo antes de derrubar
• Confirme que subiu depois, com verificação automática
• Registre em log, para você saber se algum reinício falhou

Configuração ou hardware: manutenção. Se o reinício diário virou obrigatório para o servidor funcionar, existe um vazamento a investigar.

14. Ausência de monitoramento

Sintoma: você descobre os problemas pelos jogadores, e não pelos dados.

Sem histórico, todo diagnóstico vira adivinhação. Você não sabe se o uso de memória de hoje é normal, porque não sabe qual era o de semana passada.

O mínimo viável para acompanhar:

• Uso de processador, por núcleo, não só a média
• Memória usada e uso de swap
• Jogadores online, para cruzar com os dois anteriores
• Tempo de resposta do banco
• Tráfego de rede de entrada e saída

Com esses cinco gráficos lado a lado, a maior parte dos diagnósticos deste artigo vira questão de olhar em vez de testar.

Configuração ou hardware: processo. É o item com melhor retorno sobre o tempo investido.

15. Hospedagem inadequada para jogo

Sintoma: desempenho inconsistente sem explicação interna, variando ao longo do dia sem relação com a sua carga.

Nem toda VPS é feita para jogo. Duas armadilhas frequentes:

Superlotação do hospedeiro. Em ambientes muito compartilhados, o desempenho que você recebe depende do que os vizinhos estão fazendo. Você não vê nada de errado na sua máquina, e mesmo assim ela oscila.

Hardware voltado para outro perfil. Máquinas otimizadas para hospedagem de site priorizam quantidade de núcleos e não clock alto. É a configuração errada para OTServ.

Como confirmar: se o desempenho oscila em horários que não têm relação com a sua quantidade de jogadores, e você já descartou tudo acima, é o ambiente.

Configuração ou hardware: escolha de hospedagem.

Ordem prática de diagnóstico

Se você está com lag agora e não sabe por onde começar, siga nesta sequência. Ela vai do mais barato para o mais caro.

1. Todo mundo ou só alguns? Se for só alguns, vá direto para rede
2. É reproduzível? Se sim, é script. Isole desativando
3. Melhora com reinício? Se sim, é acúmulo de memória
4. Coincide com o save? Se sim, é disco ou banco
5. Começa a partir de um número de jogadores? Se sim, é escala
6. Processador tranquilo mas inacessível? Se sim, é ataque
7. Oscila sem relação com a sua carga? Se sim, é o ambiente da hospedagem
8. Nada acima explica? Aí sim, considere subir de plano

Note que "subir de plano" está em oitavo lugar. Não é acaso.

Perguntas frequentes

Quantos jogadores um OTServ aguenta?

Não existe número fixo, e desconfie de quem der um. Depende do peso do mapa, da quantidade de scripts, da densidade de spawn e da qualidade do código. Dois servidores no mesmo plano podem ter resultados muito diferentes.

Trocar de plano resolve o lag?

Só se a causa for hardware, o que é minoria. Se o problema é script pesado ou banco mal indexado, você vai levar o problema para a máquina nova.

Como sei se é script ou falta de máquina?

Pela reprodutibilidade. Script gera travadas ligadas a uma ação específica e repetível. Falta de máquina gera degradação proporcional à carga.

Reiniciar o servidor todo dia faz mal?

Não faz mal, mas é sintoma. Se o servidor precisa de reinício diário para funcionar bem, existe um vazamento não resolvido.

O que causa mais lag no Tibia?

Scripts mal otimizados, com larga vantagem. Depois, banco de dados sem manutenção. Hardware insuficiente vem bem depois desses dois.

Vale usar Linux para reduzir lag?

Ajuda, porque libera memória e processamento que o Windows gasta com interface gráfica. Mas não conserta script ruim. A comparação completa está em Linux ou Windows para servidor de Tibia.

Conclusão

A conclusão honesta deste artigo é que a maior parte do lag em OTServ é configuração, não hardware. Script pesado, banco sem manutenção e spawn mal dimensionado respondem pela maioria dos casos, e nenhum deles se resolve com dinheiro.

Mas existe a outra parte, e ela é real. Depois de limpar o que dava para limpar, o que sobra é o piso da máquina. E aí três coisas mudam o resultado de verdade:

Clock por núcleo, porque a lógica do jogo é concentrada e responde diretamente à frequência do processador. Disco NVMe, porque o save do mundo e as consultas ao banco são operações de pico que o disco lento transforma em travamento. E localização no Brasil, porque latência é distância física e nenhuma otimização vence isso.

É por esse motivo que os planos de host de Tibia da WyzeHost usam AMD Ryzen 9 e SSD NVMe, com proteção DDoS inclusa e máquinas no Brasil. Não é para compensar servidor mal configurado, e sim para que, depois de você fazer a sua parte, a máquina não seja o gargalo.

Se estiver na dúvida sobre o tamanho, o dimensionamento por cenário está em como escolher a VPS para o seu servidor de Tibia.