O que define o desempenho de um servidor DayZ

Par Benjamin D. · PDG

1 Gwengolo 2026 · Mis à jour le 1 Gwengolo 2026 · Lecture 9 min

Sumário

Falar de servidor DayZ desempenho é falar de três gargalos muito concretos: a frequência de um único núcleo de CPU, a memória consumida pelo conjunto de mods e a qualidade da rota de rede até os jogadores. Tudo o mais — Economia Central, número de zumbis, persistência — se apoia nesses pilares. Este guia explica o que medir, o que ajustar e o que simplesmente não dá para forçar.

Servidor DayZ: desempenho começa no núcleo único de CPU

A Enfusion, engine que roda o DayZ Standalone, distribui algumas tarefas (streaming de terreno, I/O, rede) por várias threads, mas o laço principal de simulação — física dos objetos, IA dos infectados, avaliação dos scripts, Economia Central — permanece fortemente serializado. Na prática, isso significa uma coisa: um processador com 32 núcleos a 2,1 GHz vai render menos do que um Ryzen de 8 núcleos a 4,5 GHz para o mesmo mapa e o mesmo número de jogadores.

Como o server FPS revela a saturação

O indicador que importa não é o uso percentual de CPU exibido no painel, e sim o server FPS (também chamado de tickrate efetivo). Um servidor saudável mantém o laço de simulação estável; quando ele cai, os sintomas aparecem em ordem previsível:

Infectados começam a "teleportar" ou reagir com atraso de meio segundo.
Veículos ficam elásticos, saltam ao passar por obstáculos ou desyncam ao sair.
Ações de inventário demoram a confirmar (arrastar item, encher cantil, cozinhar).
Loot demora a repopular porque o ciclo da Economia Central perde janelas de execução.
Em casos extremos, o watchdog dispara e o log registra travamentos.

Ative os logs desde o início; sem eles, qualquer diagnóstico vira adivinhação:

./DayZServer -config=serverDZ.cfg -port=2302 -profiles=profiles \
  -BEpath=battleye -cpuCount=4 -dologs -adminlog -netlog -freezecheck \
  -mod=@CF;@DayZ-Expansion-Core;@DayZ-Expansion-Licensed

Depois, na console ou no gerenciador de arquivos do painel, procure os padrões que indicam estouro do laço principal:

grep -i "freeze" profiles/DayZServer_x64_*.RPT
grep -i "Cannot find" profiles/script.log
grep -i "NULL pointer" profiles/script.log
tail -n 200 profiles/DayZServer_x64_*.RPT

Quantos núcleos declarar em -cpuCount

Declarar -cpuCount igual ao total de threads da máquina raramente ajuda: a engine passa a competir consigo mesma por cache. Em máquinas compartilhadas, valores entre 2 e 6 costumam dar o comportamento mais previsível. O ganho real vem da frequência sustentada e do acesso exclusivo aos núcleos alocados — é exatamente por isso que uma máquina com Ryzen de alta frequência e NVMe muda o comportamento de uma comunidade de 60 slots com Expansion instalado.

Se você já está avaliando onde rodar sua comunidade em condições estáveis, veja as configurações disponíveis na página de hospedagem DayZ da Fly-Serv, com anti-DDoS incluído e painel Pterodactyl.

RAM: o consumo real muda conforme o conjunto de mods

DayZ vanilla é relativamente modesto em memória. O que explode o consumo é a combinação de mods pesados com um arquivo de persistência que cresce ao longo dos wipes. Cada mod carrega seus PBOs, texturas e scripts na memória do processo do servidor, e o Expansion, sozinho, já muda a escala do jogo.

Perfil do servidor	Memória a reservar	Observações
Vanilla, até 40 slots	4 a 6 GB	Chernarus padrão, CE sem alterações profundas
Vanilla + Livonia ou mapa alternativo	6 a 8 GB	Mapas custom variam muito conforme o número de objetos
Expansion completo (Core, Vehicles, Market, Base Building)	8 a 12 GB	Trader e AI de missões pesam em RAM e CPU
Modpack grande, 60+ slots, mapa custom	12 a 16 GB	Persistência grande de bases construídas eleva o consumo

Esses valores são pontos de partida operacionais, não uma regra fixa: dois servidores com o mesmo número de mods podem divergir bastante conforme quantos objetos persistentes os jogadores criaram.

A persistência é uma variável de memória e de disco

A pasta mpmissions/dayzOffline.chernarusplus/storage_1/ concentra os dados de bases, veículos e itens salvos. Quanto mais bases erguidas, maior o arquivo, mais longo o carregamento na inicialização e mais custosa cada gravação. Aqui o armazenamento NVMe faz diferença mensurável: um ciclo de save que trava o laço principal por alguns segundos em disco lento passa quase despercebido em NVMe.

Limpeza que devolve memória

Ajuste os tempos de limpeza em globals.xml para não acumular ruínas e cadáveres eternamente.
Revise types.xml: valores de nominal inflados multiplicam objetos ativos no mundo.
Retire mods que ninguém usa — cada PBO carregado é memória ocupada em tempo integral.
Programe wipes de persistência coerentes com a proposta do servidor (PvP rápido versus PvE de longa duração).

<var name="ZombieMaxCount" type="0" value="900"/>
<var name="AnimalMaxCount" type="0" value="200"/>
<var name="CleanupLifetimeRuined" type="0" value="330"/>
<var name="CleanupLifetimeDeadPlayer" type="0" value="3600"/>
<var name="IdleModeCountdown" type="0" value="60"/>
<var name="TimeLogin" type="0" value="15"/>

ZombieMaxCount é o parâmetro mais direto entre RAM, CPU e sensação de jogo. Reduzir de 1000 para 700 costuma liberar folga imediata no laço de simulação; reduzir demais transforma Chernarus em passeio no campo. Teste em incrementos de 100 e observe o comportamento com o servidor cheio, nunca vazio.

Rede, latência e proteção anti-DDoS

Mesmo um servidor com CPU sobrando entrega uma experiência ruim se a rota até os jogadores for longa ou instável. DayZ trafega em UDP, e o desync que os jogadores relatam como "bala que não registra" quase sempre é perda de pacotes, não falta de processamento.

O que realmente importa em latência

Proximidade geográfica: para uma comunidade majoritariamente brasileira, cada salto internacional adiciona dezenas de milissegundos irreversíveis.
Perda de pacotes: 1% de perda em UDP é mais destrutivo para o hitreg do que 30 ms extras de ping.
Jitter: variação de latência causa correções de posição bruscas nos infectados e nos veículos.
Banda por jogador: DayZ envia muitos updates de entidades próximas; servidores cheios em áreas quentes (Cherno, Tisy, aeroportos) elevam o tráfego rapidamente.

Parâmetros de rede no serverDZ.cfg

O arquivo de configuração permite calibrar o quanto o servidor envia e processa por ciclo. Estes valores afetam simultaneamente CPU e banda:

hostname = "Comunidade BR - PvE/PvP";
maxPlayers = 60;
instanceId = 1;
steamQueryPort = 2305;
respawnTime = 5;
timeAcceleration = 6;
nightTimeAcceleration = 8;
disableVoN = 0;
vonCodecQuality = 20;
loginQueueConcurrentPlayers = 5;
loginQueueMaxPlayers = 500;

networkRangeClose = 20;
networkRangeNear = 150;
networkRangeFar = 1000;
networkRangeDistantEffect = 4000;
networkObjectBatchSend = 100;
networkObjectBatchCompute = 1000;

defaultVisibility = 1375;
defaultObjectViewDistance = 1375;

Reduzir networkRangeFar e defaultObjectViewDistance alivia o servidor, mas encurta o alcance de renderização de objetos para o cliente — em servidor de sniper, isso é percebido na hora. Ajuste com critério e comunique mudanças à comunidade. A referência completa dos parâmetros está na documentação oficial da Bohemia Interactive.

Ataques volumétricos e floods de query

Servidores DayZ públicos são alvo frequente de dois tipos de abuso: floods na porta de query Steam, que derrubam o servidor das listas, e ataques volumétricos UDP contra a porta de jogo. O primeiro pode ser mitigado com rate limiting e com uma porta de query distinta da porta de jogo; o segundo exige filtragem na infraestrutura, e é isso que a proteção anti-DDoS incluída por padrão na Fly-Serv cobre — o tráfego sujo é descartado antes de chegar à máquina que roda a simulação.

Do lado administrativo, o que continua sob sua responsabilidade:

Senha de RCON longa e única em battleye/beserver_x64.cfg, nunca compartilhada em Discord público.
Filtros do BattlEye atualizados (scripts.txt, createvehicle.txt) para bloquear scripts injetados.
Whitelist ou fila de login controlada em servidores de comunidade fechada.
Sub-usuários no painel com permissões limitadas para a equipe de moderação, em vez de credenciais compartilhadas.
Rotina de backups verificada — testar a restauração vale mais do que acumular arquivos nunca abertos.

Rotina de diagnóstico e ajuste fino

Otimizar um servidor DayZ é um processo iterativo. Mudar cinco variáveis de uma vez impede saber qual delas resolveu — ou piorou — o quadro.

Ordem de investigação recomendada

Reproduza o problema com carga real. Servidor vazio nunca mostra gargalo. Meça com 70% dos slots ocupados, em horário de pico.
Isole os mods. Suba o servidor em vanilla, confirme a estabilidade, reintroduza os mods em blocos. Erros repetidos no script.log geralmente apontam o culpado.
Verifique a Economia Central. Erros de XML mal formado em types.xml ou events.xml fazem a CE reiniciar em loop e consumir CPU sem produzir loot.
Analise a persistência. Se o carregamento inicial passou de segundos para minutos, o storage_1 cresceu além do razoável.
Só então mexa em rede. Reduzir view distance é solução de último recurso, não de primeira linha.

Reinícios programados: aliados, não vergonha

A Enfusion acumula fragmentação de memória ao longo de horas. Reinícios a cada 3 ou 4 horas, anunciados no chat, mantêm o laço de simulação previsível e reduzem o risco de travamento em pico. Na console do painel Pterodactyl você acompanha o ciclo ao vivo e confirma que a Economia Central voltou a popular o mundo depois de cada restart.

Checklist rápido de sintomas

Sintoma relatado	Causa provável	Onde agir
Zumbis travando e teleportando	Laço principal saturado	`ZombieMaxCount`, frequência de CPU
Loot não repopula	Erro de XML ou CE sobrecarregada	`types.xml`, `cfgeconomycore.xml`, `script.log`
Veículos elásticos	Física + latência de rede	Rota de rede, número de veículos persistentes
Tiros que não registram	Perda de pacotes UDP	Proximidade geográfica, qualidade do link
Carregamento inicial muito longo	Persistência inflada ou disco lento	Wipe parcial, armazenamento NVMe
Servidor some da lista	Flood na porta de query	Porta de query separada, filtragem anti-DDoS

Boa parte desses princípios se repete em outros títulos de sobrevivência com simulação pesada no lado do servidor — quem administra Servidor Arma Reforger, também baseado na Enfusion, reconhece os mesmos padrões. Para outros títulos e configurações, consulte Todos os nossos servidores de jogos e os guias técnicos publicados no Blog da Fly-Serv.

Conclusão

Frequência de CPU por núcleo, memória compatível com o conjunto de mods, armazenamento rápido para a persistência e uma rota de rede curta e filtrada: esses quatro elementos explicam quase todo o comportamento percebido pelos jogadores em Chernarus. Ajuste uma variável por vez, meça com o mundo cheio e mantenha os logs ativos — o diagnóstico correto poupa horas de tentativa e erro.

FAQ

Quantos GB de RAM são necessários para um servidor DayZ com Expansion e 60 slots?

Reserve entre 8 e 12 GB como ponto de partida. Expansion Core, Vehicles, Market e Base Building carregam muitos PBOs na memória, e a persistência de bases construídas pelos jogadores cresce a cada semana. Monitore o consumo no painel durante o horário de pico e amplie a folga antes de chegar ao limite, porque swap em servidor DayZ causa travamentos imediatos.

Por que meu servidor DayZ trava mesmo com uso de CPU baixo no painel?

Porque o gráfico mostra a média entre todos os núcleos, e a Enfusion satura apenas um deles no laço principal. Um pico de 100% em um núcleo aparece como 12% em oito núcleos. Avalie o server FPS e procure entradas de freeze no arquivo RPT dentro da pasta profiles: elas indicam o momento exato em que o laço de simulação estourou.

Reduzir o número de zumbis realmente ajuda no desempenho?

Sim, é um dos ajustes de maior impacto. Cada infectado ativo consome pathfinding, física e sincronização de rede no laço principal. Baixe ZombieMaxCount em globals.xml em incrementos de 100, reinicie e observe com o servidor cheio. O objetivo é encontrar o ponto em que a simulação fica estável sem esvaziar a tensão das cidades do litoral.