interhome

https://www.facebook.com/notes/mikro...47062648715336

[DICA] 16.1 - Unbound: Howto Optimizar


11 de novembro de 2013 às 19:12
http://translate.google.com.br/trans..._optimise.html


Unbound: Howto Optimizar


Por WCA Wijngaards, NLnet Labs, outubro de 2008, atualizada em julho de 2010. Este como contém um guia para otimizar desacoplado. A maioria dos usuários não tem que fazer isso, mas pode ser útil para grandes instalações de resolver. O texto abaixo é o resultado do feedback dos usuários não ligados, se você tem experiências diferentes ou ter recomendações, deixe-me saber.



Instalação de configuração


Definir num-threads igual ao número de núcleos de CPU no sistema. Porexemplo, para 4 CPUs com dois núcleos cada, use 8.


*Defina-lajes para uma potência de 2 perto do num-threads valor. Faça isso por msg-cache-slabs , rrset-cache-slabs , infra-cache-slabs e key-cache-slabs . Isso reduz a contenção debloqueio.


Aumente otamanho da memória do cache. Use cerca de duas vezes mais memória cache rrsetcomo você usa memória cache msg. Por exemplo, rrset-cache-size: 100m e msg-cache-size: 50m . Devido à sobrecarga de malloc, o uso total damemória é susceptível de aumentar para o dobro (ou 2.5x) a memória cache totalque é inserido na configuração.


Defina a outgoing-range a um valor tão grande quanto possível, consulte asseções abaixo sobre como superar o limite de 1.024 no total. Este serviço maisclientes ao mesmo tempo. Com um núcleo, tente 950. Com dois núcleos, tente 450.



Com quatro núcleos de tentar 200. O num-queries-per-thread é melhor fixado em metade o número de outgoing-range , mas você gostaria de um lote inteiro para sercapaz de absorver um aumento nas consultas. Devido ao limite de outgoing-range , assim, também limita num-queries-per-thread , é melhor para compilar comlibevent (consulte a seção abaixo), de modo que não há mais limite de 1.024 em outgoing-range .


Defina so-rcvbuf para um valor maior (4m ou 8m) para um servidorocupado. Isso define o buffer do kernel maior, de modo que nenhuma mensagem éperdida em picos no tráfego. Adiciona 9s extra para o percentual respostaconfiabilidade. O OS tampas que no máximo, em desacoplado linux precisa depermissão de root para contornar o limite, ou o administrador pode usar sysctl net.core.rmem_max . Sobre a mudança BSD kern.ipc.maxsockbuf em /etc/sysctl.conf . NoOpenBSD cabeçalho mudança do kernel e recompilar. No Solaris ndd -set /dev/udp udp_max_buf 8388608 .


Tambémdefinir so-sndbuf para um valor maior (4m ou 8m)para um servidor ocupado. Mesmo que rcvbuf, mas agora para picos de respostas,e é net.core.wmem_max. Talvez seja necessário um valor menor, como picos sãomenos comuns em respostas, você pode ver VN e snd estouros de buffer com netstat -su , 'RcvbufErrors' e 'SndbufErrors', e os relatóriossemelhantes em BSD.


Aqui estáum breve resumo de configuração de otimização
# Algumas opções de otimização.
servidor:
# Usar todas as CPUs
num-threads: <number of cores>
# Potência de 2 perto de num-threads
msg-cache-slabs: <same>
rrset-cache-slabs: <same>
infra-cache-slabs: <same>
key-cache-slabs: <same>
# Mais memória cache, rrset = msg * 2
rrset-cache-size: 100m
msg-cache-size: 50m
# Mais conexoes de saida (outgoing connections)
# Depende do número de núcleos: 1024/cores - 50
outgoing-range: 950
# Larger socket buffer.OS pode precisar de configuração.
so-rcvbuf: 4m
so-sndbuf: 4m
Aconfiguração padrão funciona bem, mas quando um grande número de usuários temque ser servido, os limites do sistema sejam alcançados. Mais premente é onúmero de descritores de arquivo, o padrão tem um limite de 1024. Para usarmais de 1.024 descritores de arquivo, use libevent ou o método de operaçãobifurcada. Estes são descritos nas secções seguintes.
Usando libevent


Libeventé um wrapper multiplataforma licenciado BSD em torno do evento de notificaçãode chamadas de sistema específicas da plataforma. Não consolidado, pode usá-lopara o uso eficiente de mais de 1.024 descritores de arquivos.



Instale libevent(e libevent-devel, se existir) com o seu gerenciador de pacotes favorito. Antesde compilar prazo não ligado. / Configure --with-libevent .


Agoravocê pode dar qualquer número que você quiser para outgoing-range . Também aumentar o num-queries-per-thread valor.


# Com libevent

outgoing-range: 8192
num-queries-per-thread: 4096 Osusuários relatam que os trabalhos libevent-1.4.8-stable bem. Os usuários têmconfirmado que funciona bem em Linux e FreeBSD com 4096 ou 8192 como valores. Odobro do num-queries-per-thread e usar isso como outgoing-range .


Estáveis(idade) distribuições pode empacotar as versões mais antigas (tais comolibevent-1.1), para o qual existem crashreports, assim você pode precisaratualizar seu libevent. Em desacoplado 1.2.0 uma condição de corrida naschamadas libevent foi corrigido.


Unboundpode compilar do libevent ou libev construir diretório para fazer isso fácil, configure--with-libevent=/home/user/libevent-1.4.8-stable , ou configure --with-libevent=/home/user/libev-3.52 .
Observação: Se você experimentar falhas de qualquermaneira, então você pode tentar o seguinte. Atualize libevent. Se o problemapersistir, libevent pode ser feito para usar diferentes sistema de chamada deback-ends, definindo as variáveis de ambiente. Não consolidado, relata oback-end em uso quando verbosidade está no nível 4. Ao definir EVENT_NOKQUEUE , EVENT_NODEVPOLL , EVENT_NOPOLL , EVENT_NOSELECT , EVENT_NOEPOLL ou EVENT_NOEVPORT para yesno shell antes de começar soltos, alguns back-ends pode ser excluído do uso. Apesquisa (2) backend é confiável, mas lento.
Operação bifurcada


Nãoconsolidado, tem um único modo em que pode operar sem segmentação. Isto podeser útil se libevent falhar na plataforma, para um desempenho adicional, oupara a criação de paredes entre os núcleos de modo a que não se pode envenenaro outro.


Paracompilar para a operação bifurcada, antes do uso de compilação. / Configure --without-pthreads --without-solaris-threads para desativar linhas e permitira operação bifurcada. Porque nenhum bloqueio tem de ser feito, o código acelera(cerca de 10 a 20%).


Noarquivo de configuração, num-threads ainda especifica o número denúcleos que você deseja usar (mesmo que utiliza processos e não threads). Enote que as outgoing-range valores de memória cache e sãotodos por segmento.



Isso significa que mais memória é usada, como cada núcleousa seu próprio cache. Como cada núcleo tem seu próprio cache, se obtém o cacheenvenenado, os outros não são afetados.


# Com operação bifurcada


servidor:
# Usar todas as CPUs

num-threads: <number de cores>

msg-cache-slabs: 1
rrset-cache-slabs: 1
infra-cache-slabs: 1
key-cache-slabs: 1
# Mais memória cache, rrset = msg * 2
# total é * núcleos 150m


rrset-cache-size: 100m
msg-cache-size: 50m
# Não dependem do número de núcleos

outgoing-range: 950
num-queries-per-thread: 512
Buffer de socket # maior. OS pode precisar de configuração.

so-rcvbuf: 4m Como cadaprocesso está usando na maioria das 1.024 descritores de arquivo agora, omáximo eficaz é o número de núcleos * 1024. A configuração acima usa 950 porprocesso, por quatro processos dá uns respeitáveis 3.800 órbitas. O número deconsultas por segmento é a metade do número de tomadas, para garantir que cadaconsulta pode obter um socket, e alguns de sobra para consultas-para-nomes.


Utilizandobifurcado operação, juntamente com libevent também é possível. Pode ser útil paraforçar o sistema operacional para atender os filedescriptors para diferentesprocessos, em vez de threads. Isso pode ter (radicalmente) o desempenhodiferente, se a pilha de rede subjacente usa (lento) estruturas de pesquisa porprocesso.

LINK ORIGINAL:
http://www.unbound.net/documentation/howto_optimise.html

Avalie nosso Post e nos ajude a continuar escrevendo. Obrigado.