A opção max-auto-save-chunks-per-tick na configuração de mundo do Paper define o máximo de chunks que o sistema de autosave salvará em um tick. A documentação mostra esse controle ao lado do intervalo de autosave e de outras políticas de gravação. Ele influencia como o trabalho pode ser distribuído; não é um botão genérico para acelerar o servidor nem substitui backup.

Se muitos chunks precisam ser salvos em uma janela curta, concentrar mais gravações por tick pode aumentar trabalho nesse momento. Limitar o número por tick pode espalhar o trabalho, mas também alongar o tempo necessário para processar a fila. O resultado depende de atividade, armazenamento, número de chunks e de outros mecanismos de Paper.

Entenda o máximo por tick

Um tick é uma unidade de atualização do servidor. Com meta de 20 ticks por segundo, um máximo de 24 chunks por tick permitiria processar até 480 tentativas por segundo no cenário ideal se houvesse fila suficiente. Isso não significa que toda instalação alcança esse ritmo nem que gravação física termine imediatamente; a taxa real depende do sistema e da configuração.

O parâmetro não define quantos chunks existem, nem quando o autosave dispara. O intervalo pode ser global em bukkit.yml ou específico por mundo em Paper. O número máximo controla quantos entram em cada tick enquanto o trabalho de autosave é executado. Ajustá-lo sem olhar o intervalo e o escopo do mundo pode levar a conclusões erradas.

Um valor mais alto não implica necessariamente maior durabilidade em falha; a persistência efetiva envolve o sistema de arquivos, armazenamento e outras opções. Não descreva esse parâmetro como quantidade de dados garantidamente gravados no disco ou como uma barreira contra corrupção.

Identifique o sintoma antes de ajustar

Se os jogadores sentem travamento periódico, capture métricas e um perfil durante o incidente. O profiling precisa coincidir com o problema para explicar o custo. Verifique MSPT, atividade de disco, número de chunks salvos, picos de CPU e mensagens em latest.log. Use a documentação de Paper para iniciar e compartilhar o relatório.

Determine se o problema aparece junto ao salvamento ou se é contínuo. Uma rotina de plugin, geração de chunks, GC, disco saturado ou antivírus pode produzir pausas semelhantes. Se uma gravação em massa coincide com o pico, ajuste somente o parâmetro relevante num teste controlado e compare com a mesma carga.

Observe a fila ou a progressão do salvamento quando possível, sem inventar métricas que o servidor não expõe. Confirme se todos os mundos compartilham o comportamento ou se um mapa de evento é a fonte. A configuração individual pode ajudar a limitar escopo caso apenas um mundo tenha problema.

Encontre configuração, herança e precedência

Consulte a documentação da versão Paper instalada. A configuração fica em arquivos de mundo e pode herdar defaults globais ou conter override por mundo. Verifique nomes e localização antes de editar: a estrutura de configuração já mudou entre gerações do software.

Copie o arquivo atual e mantenha indentação. Um YAML malformado pode impedir a inicialização ou fazer a aplicação manter padrões. Leia avisos no log depois do boot. Não confie exclusivamente no painel gráfico, pois ele pode alterar outro arquivo ou salvar valores diferentes do que você editou.

Verifique se plugins ou scripts de startup reescrevem o arquivo. Tenha certeza de que o servidor usa a pasta que está sendo editada. Em uma rede com várias instâncias, registre quais arquivos pertencem a cada mundo e JAR.

Faça uma comparação em ambiente de teste

Use uma cópia de mundo com quantidade e atividade semelhantes, armazenamento equivalente quando possível e sem jogadores reais. Anote o valor anterior, a versão, o intervalo global ou por mundo e as métricas. Mude apenas o máximo por tick e repita um cenário em que muitos chunks entram no ciclo de gravação.

Compare latência dos ticks, duração do trabalho de autosave, fila de IO e tempo total de persistência. Se o menor valor suaviza o pico, confira se o salvamento continua terminando em janela adequada. Se o maior valor termina rapidamente, avalie se introduziu picos que jogadores percebem. O objetivo é equilibrar as duas coisas, não otimizar uma única cifra.

Faça testes durante atividade baixa e em pico, pois jogadores explorando, teletransportes e geração de mundo alteram a quantidade de chunks sujos. Verifique mundo principal e dimensões. Um teste de curta duração não revela ciclos raros de autosave; acompanhe períodos suficientes para observar repetições.

Proteja a recuperação além da configuração

Mantenha backups completos, retidos e testados. Inclua mundos, dimensões, arquivos de configuração e bancos externos relevantes. Uma cópia deve estar fora do volume primário. Autosave frequente não cria histórico e pode persistir rapidamente uma exclusão acidental ou um estado ruim de plugin.

Teste restauração em diretório isolado, valide chunks, inventários, dimensões e plugins e mantenha intacto o backup original. Se atualizar Paper ou Minecraft, guarde ponto pré-migração. O procedimento para voltar de formato novo normalmente exige restaurar os dados compatíveis, não apenas iniciar o software antigo.

Defina o objetivo de ponto de recuperação e ponto de restauração do serviço. Se não pode perder progresso de horas, o parâmetro de chunks por tick não substitui snapshots mais frequentes. A política deve combinar intervalo, integridade do armazenamento, cópias e ensaios.

Promova a mudança com reversão

Programe a alteração numa janela, pare o servidor com segurança e guarde a versão original dos arquivos. Aplique um valor documentado e inicie a instância. Observe os logs e o próximo ciclo; confirme que nenhum mundo deixou de salvar ou apresentou erro.

Se o servidor piorar ou o ciclo não completar a tempo, restaure o valor anterior e revise o diagnóstico. Não altere ao mesmo tempo taxa de autosave, intervalo, flush de disco e chunk loading. Fazer várias mudanças dificulta separar efeito e aumenta o risco em caso de rollback.

Registre o responsável, o valor, o motivo, métricas antes e depois, período de observação e decisão. Reavalie após atualização de Paper ou mudança de armazenamento, pois o comportamento e opções podem variar. Configuração eficaz é resultado de evidência local e critérios de recuperação claros.

Fontes e referências

Documentação consultada em 2026-10-08. Os exemplos precisam ser conferidos na versão instalada; este guia não afirma que a configuração foi testada no seu ambiente.