Ajustar o desempenho
Mexer nos parâmetros do resolvedor e do sistema com backup antes, e voltar atrás se piorar.
O ajuste fino existe para casar o servidor com o hardware que ele tem. Os valores padrão são conservadores de propósito — funcionam em qualquer máquina, e por isso não aproveitam nenhuma em particular.
Meça antes e depois
Ajustar sem medir é adivinhar. Rode o teste de capacidade antes de mexer, ajuste, e rode de novo. Sem o par de números, não há como saber se o ajuste ajudou ou atrapalhou.
Onde clicar, passo a passo
Quatro abas: o resolvedor, a camada de entrada, o sistema operacional e o backup. As três primeiras mexem em configuração; a última é a rede de proteção.
Antes de mudar qualquer valor, crie o ponto de retorno. Leva um segundo e é a diferença entre "deu ruim, volto" e "deu ruim, e agora?".
A tela avisa quando não existe backup nenhum.
Com o backup no lugar, dá para mexer com tranquilidade: qualquer valor pode ser revertido de uma vez.
Cada campo traz o valor padrão e a faixa aceita logo abaixo — não é preciso decorar nada.
O número de threads deve subir até o número de núcleos físicos do servidor. É o ajuste de maior efeito e o mais frequentemente esquecido: uma máquina de oito núcleos rodando com o padrão usa uma fração do que tem.
O aviso no topo é literal: salvar reinicia o resolvedor uma vez, com interrupção abaixo de um segundo. Valores fora da faixa são recusados antes de qualquer escrita.
O cache de registros é o que evita repetir resolução. A tela informa o custo: cada entrada usa cerca de 200 bytes, então um milhão de entradas custa aproximadamente 200 MB de memória.
Aumentar o cache reduz latência e reduz o tráfego que sai do servidor. É o ajuste com melhor retorno depois das threads — desde que sobre memória. Configurar um cache que não cabe na máquina troca um problema por outro pior.
O botão diz o que faz. A configuração é validada antes; o serviço não reinicia para dentro de uma configuração inválida.
Em produção, prefira uma janela de baixo movimento — a interrupção é curta, mas existe.
A aba de backup mostra as diferenças entre o backup e o estado atual antes de restaurar. Dá para conferir exatamente o que voltaria, em vez de restaurar às cegas.
É o passo que torna o ajuste seguro: se o teste depois do ajuste vier pior, restaure e repense.
O passo a passo em detalhe
Medir antes
Teste de capacidade. Anote a capacidade sustentada e o que limitou.
Criar o backup
Aba Backup & Rollback, criar backup agora.
Ajustar poucos valores por vez
Mudar dez parâmetros de uma vez e medir depois não diz qual deles fez efeito — nem qual deles estragou. Um grupo por vez.
A ordem que costuma render mais: threads, depois cache, e só então o resto.
Aplicar e medir de novo
Rode o mesmo teste, com os mesmos parâmetros de teto e duração. Comparar medições feitas com configurações de teste diferentes não significa nada.
Manter ou reverter
Melhorou, mantenha e siga para o próximo grupo. Piorou ou não mudou nada, restaure o backup — configuração alterada sem ganho é só dívida futura.
Sobre as sugestões automáticas
A tela de benchmark oferece recomendações de ajuste a partir das métricas observadas, e consegue aplicá-las. Vale como ponto de partida, principalmente quando o servidor está claramente mal dimensionado.
Ainda assim, meça depois. Uma recomendação é uma hipótese sobre a sua carga; a medição é o fato.
Armadilhas
- Ajustar sem medir antes — sem linha de base, não existe "melhorou".
- Não criar o backup antes de mexer.
- Mudar muita coisa de uma vez — nenhum resultado é atribuível.
- Cache maior que a memória disponível — troca latência por swap, que é muito pior.
- Aplicar em produção em horário de pico — a interrupção é curta, mas o pico não perdoa.
- Esquecer que o Dois ou mais servidores Made4DNS sincronizados entre si, com um deles como origem da configuração. replica boa parte dessa configuração: o ajuste vale para os parceiros, e aplicar reinicia serviço neles também. Veja montar um cluster.