Melhorias na Pilha de Rede do FreeBSD, uma análise.

Transcrição

Análise e Considerações Sobre Melhorias e Recursos na Pilha de Rede do FreeBSD FreeBSD Brasil LTDA
Relatório Revisional Analítico 2007/00003– Março 2007
Espécie: Relatorio / Revision al / O p p e r m a n n 0 1 - 2007- rev2
Belo Horizonte 10 de Março de 2007
FreeBSD Brasil LTDA
Client e s Corporativo s FreeBSD Brasil LTDA
FreeBSD Brasil LTDA.
Avenida Getulio Vargas,54 – Savassi – Belo Horizonte, MG
Patrick Tracanelli – Diretor de Consultoria – [email protected] – Tel.: (31) 3281 9633
I – SOBRE ESTE DOCUMENTO
Este documen to tem como objetivo apresent ar uma síntese sobre as recentes
modificações na pilha de rede do FreeBSD. Algumas dessas modificações já estão
disponíveis no FreeBSD -STABLE, e outras
FreeBBSD 7.0- RELEASE. Todas
porém
estarão
represent a m
disponíveis a partir
aumen to
do
significativo de
performa nce ou melhorias no comportame n to do stack de rede do sistema.
Em Julho de 2005, Andre Opperma n n , commiter FreeBSD e conhecido
também
por ser autor do qmail- ldap solicitou levantame n to
de fundos para
trabalhar de forma dedicada em melhorias do protocolo TCP/IP no FreeBSD.
Sistemas BSD tem, desde seus primórdios, a reconhecida fama de ter uma das
pilhas TCP/IP mais robusta s e com melhor performa nce, além de ter sido o sistema
onde o TCP/IP foi projetado, criado e popularizado. O FreeBSD por volta da série 3
teve um grande número de muda nç a s, e o sistema ficou conhecido na época como a
melhor implement ação TCP/IP disponível, e manteve esse título sem contestações
até início da série 4. Na série 4 o FreeBSD perdeu a hegemonia e o título de melhor
pilha de rede não se apresent ava mais como una nimidade. Sistemas como Solaris e
Linux tiveram por exemplo, implement ações mais rasoáveis do sack antes do
FreeBSD. Além do sack não houve qualquer outro momento que FreeBSD não
apresent ava uma pilha de rede melhor, mas alguns sistemas já haviam conseguido
qualidade similar a do FreeBSD.
Desta forma, Opperma n n se propôs a implement ar em detalhes tecnologias apenas
parcialmente
implementa d a s
em outro sistema
e fazer uma
revisão fina de
performa nce e recursos do ambiente de rede TCP/IP no FreeBSD. Este docume nto
discute estas implement ações. Este documen to encontra- se em sua revisão número
2, e conforme o trabalho liderado por Opperma n n evoluir, este será atualizado.
O leitor que já tenha feito treina me n to FreeBSD Brasil, que tenha acesso à
apostila da formação em FreeBSD ou que frequentemen te está em contato direto
com a consultoria FreeBSD Brasil sobre tuning de sistemas, ou que tem um
conhecimento básico sobre tuning no FreeBSD, proveniente especialmente da
referência bibliográfica The Design & Implementation of the FreeBSD Operating
System s de Marshall Kirk McKusick absorverá detalhes relevantes do documen to a
seguir.
II – MELHORIAS E NOVAS IMPLEMENTAÇÕES NO NETWORKING STACK
II.I – Melhorias na implem e n t a çã o sendfile();
sendfile() é a função respon s ável por tornar disponível um arquivo
direta m e n t e acessa do no sistem a de arquivos para trans mi s s ã o pela pilha de
rede; esse recur so é muito utilizado por daemon s de rede, como o Apache
por exemplo, que faz uso desse recur so resulta r em melhoria significativa de
performa n ce. No FreeBSD o sendfile() sempre foi implement a do utilizando
a técnica de zero-copy , ou seja não há recópia dos dados em segmentos
distintos de memória para ser utilizado por subsiste m a s indepen de n t e s.
Com essa otimização a cópia de dados em memória é evitada e estes podem
ser tran s mitidos direta me n t e.
Em algum a s arquitet u r a s suport a d a s pelo FreeBSD, essa abordagem
pode inter na m e n t e fazer uso de um buffer sendfile() para controlar o envio de
dados para o cliente. Se o socket trans mi s sor bloqueia a remetência por
qualq uer motivo e em contra s te não há mais buffers sendfile() disponíveis, a
tran s mi s s ã o será bloquea d a e o sistem a reportar á o estado (erro) "sfbufa".
Assim sendo históricame n te sempre houve a necessida de de garantir a
possibilidade de alocação do sf_buf 's proporcional ao número de nmbclusters
usado s para trans mitir os dados ao cliente via sendfile(). De tal modo o
tuning desses requisitos para mantê- los em paridade com o valor de
kern.ipc.nmbclusters via /boot/loader.conf sempre foi - e contin u a
sendo - de sum a relevância em ambientes cogestiona do s e de anda dema n d a
de tráfego alocado por dema n d a de uso do sendfile().
O número de buffers sendfile() disponíveis é determin a do em mome n to
de boot pela configur aç ão da variável k ern.ipc.nsfbufs no
loader.conf(5) ou pela entrad a options NSFBUFS na configuração do
kernel. Como o número de buffers disponíveis para sendfile() é escalável,
aume n t a autom atica me n t e de acordo com o tuning definido em
kern.maxusers . Assim sendo, cumpri ndo as sugestões discutida s em
treina me n to ou pela cons ultoria FreeBSD Brasil por exemplo, existe a
hipótese de nunc a haver necessida de de tuning específico para NSFBUFS.
Como base para diagnóstico, també m como discutido, temos disponíveis as
MIB sysctl(8) apena s - leitura kern.ipc.nfsbufsused e
kern.ipc.nfsbufspeak que nos permitem avaliar a dema n d a atual de
NFSBUFS e a dema n d a máxima desde que o sistem a está up. Com netstat
-m podemos observar esses valores e compar á- los com osbuffers globais de
memória, disponíveis para todos os subsiste m a s e não apena s o sendfile().
Contu do, dur a n t e seu trabalho de otimização do ambiente de redes no
FreeBSD, Andre Opper m a n ao iniciar impleme nt a ç ã o do TSO (TCP
Segmentation Offload ) notou que o uso do sendfile() poderia ser otimizado
intern a m e n t e. O código até o FreeBSD 6.1 fazia um único loop (FIG I) sobre o
segmen to de dados do arquivo, convertendo cada 4k de memória (valor este
variável e portan to passível de tuning de acordo com o tama n h o de uma
página de memória) em um mbuff e enviando- o para tran s mi s s ão. Com isso
o TSO (segment aç ão leve TCP) só poderia gerar dois pacotes por segun do, ao
invés de até 44 quan do o buffer máximo de 64K fosse utilizado.
if (sbspace(&so->so_snd) < so->so_snd.sb_lowat) {
if (so->so_state & SS_NBIO) {
m_freem(m);
sbunlock(&so->so_snd);
SOCKBUF_UNLOCK(&so->so_snd);
error = EAGAIN;
goto done;
}
error = sbwait(&so->so_snd);
/*
* An error from sbwait usually indicates that we've
* been interrupted by a signal. If we've sent anything
* then return bytes sent, otherwise return the error.
*/
if (error) {
m_freem(m);
sbunlock(&so->so_snd);
SOCKBUF_UNLOCK(&so->so_snd);
goto done;
}
goto retry_space;
}
FIGURA I – trecho do loop original de conversão de página s para mbuff .
Dessa forma, a implement aç ão kern_sendfile() foi repens a d a para
utilizar dois loops ao invés de apena s um. O loop interno (o segundo)
converte o maior número possível de páginas em mbufs, enqua n to o loop
externo tran s por t a toda a cadeia mbuff para o buffer do socket de
tran s mi s s ã o, cham a o t cp_output() e então espera até que 50% do buffer
de tran s mi s s ão esteja disponível novame nte para reiniciar um novo ciclo do
loop . Assim sendo, t cp_output() tem a qua ntia total de dados disponíveis
para ser tran s mitidos e pode abrir mão de até 64K de trans mi s s ões por meio
de TSO em conju nto com a placa de rede sem dema n d a r ciclos adicionais de
process a m e n t o.
Assim ganh a m o s eficiência, especialme nte com a técnica de leitur a
adiant a d a (readahe a d) de segmentos de memória do subsiste m a de memória
virtu al os quais são exaus tiva me n te execut ados també m pelos subsiste m a s
de I/O.
Na prática, testes de performa nce realizados pelos desenvolvedores
aprese n t a m que as alterações de Oppermann represe nt a m , com 95% de
segur a n ç a , 45% menos dema n d a de CPU (fator de melhoria de 1.81) sem
TSO e 83% menos dema n d a de CPU (fator de melhoria de 5.7 vezes) com
TSO. Porta nto essas mud a n ç a implicam em ganho de perform a nce maior
que 5 vezes. Esse aume n to de perform a nce padr ão em placas de rede que
suport a m TSO torna m menos comu m os ambiente s onde tuning de
performa n ce relaciona do ao sendfile() fazer- se- á necess á rio.
Essas alterações já foram incorpor ad a s no FreeBSD -STABLE sem TSO
e parcialmen te com TSO, pois a implement aç ão plena do TSO estar á
disponível no FreeBSD 7.
II.II - Melhorias na imple m e n t a ç ã o do sosend_*();
O conjun to de cham a d a s de sistem a sosend_*() é usado para
propiciar a tran s mi s s ã o de dados através de um socket de rede Unix. Não
tinh a uma implemen t aç ão zero-copy antes das revisões atuais, e a partir do
FreeBSD 6.1- RELEASE pass a a contar com a técnica zero-copy sempre que
possível. Em determi n a d a s circu n s t â n cia s, quan do os dados estão sendo
alterado em múltiplas páginas de memória paralela me n te, faz- se imperativo
a cópia ao menos dos segmentos não indepen de n te s de memória, torna n do a
técnica zero-copy apena s parcialme n te implement a d a , porém, impleme nt a d a
ainda nas páginas indepen de n t e s .
O código atual fazia uso da função s osend_copyin() que, através de
um loop sobre a estrut u r a inter na fornecida pelo uio{} faz enlace com as
alocações mbuf através de cham a d a s uiomove(). As alterações atuais fazem
uso de uma reimpleme nt a ç ão do m_getm() que simplifica a alocação até o
tama n h o de PAGE_SIZE em relação aos clusters mbuff que, em quase todas
arquitet u r a s é const a n te (4k, padrão). Em seguida a as funções sosend_*()
fazem um loop novame nt e sobre o segmento e copia os dados nos mbufs
usa n d o o uiomove(). O sosend_dgram() e sosend_generic() foram
modificados para usar o m_uiotombuf() ao invés do sosend_copyin() de
menor performa nc e.
Em termos práticos temos ganhos apresen t a do s em testes de
performa n ce, com 95% de confiança, com no máximo 2.5% de margem de
erro, que indicam 66% menos cons u m o de CPU (fator de melhoria de 2.9
vezes) com o novo sosend_*() sem TSO e, 65% menos cons u m o de CPU (fator
de melhoria de 2.8 vezes) com o novo sosend_*() com TSO.
Portanto identificamos fácilmente que não há qualquer ganho de
performa n ce em utilizar interfaces de rede compatíveis com TSO, e o suporte
ao TSO garante perform a nc e menor, ainda que um fator de 0.3%. Quase
similares portan to. Com base nisso essas novas implement ações já foram
plena m e n t e integrad a s, sem TSO, ao FreeBSD -STABLE, disponível desde o
6.1- STABLE e 6.2- RELEASE, gara ntindo ganho de perform a nc e de quase
três vezes no uso desses recur sos.
II.III - Suporte a TSO (TCP/IP Segm e n t a t i o n Offload);
Antes de entender que o FreeBSD agora suport a TSO, é importa n t e
enten der o que é TSO. Trata- se de uma tecnologia implement a d a em
dispositivos físicos de rede (placas) capaz de reduzir drástica m e n t e o
cons u m o de CPU do comp ut a dor, em ambiente de rede de alta velocidade.
TSO també m é cham a do de liberação de carga por grandes segme ntos ou
apen a s LSO (Large Segment Offload ).
Quan do grandes sequê ncias de dados precisa m ser tran s mitida s pela
rede, estas são primeiro fragment a d a s em peque nos pacotes, para que
possa m pass ar por todos os dispositivos de rede e segme ntos, como
roteadores, switches e placas. Isso é a segme nt aç ao, que, em redes
100BaseTX requer que pacotes tenh a m tama n h o máximo de 1500 bytes.
Essa segment aç ão é sempre intríseca ao tama n h o da MTU (Max Transfer
Unit) de cada interface. Qua n do um pacote tem que ser fragment a do dess a
forma, é o sistem a operaciona m respons ável por essa divisisão em pacotes
menores. Normalme nt e isso acontece na maior frequê ncia, com pacotes TCP.
Quan d o a placa de rede consegue fazer essa segment aç ão sozinh a, sem
depen der do S.O., dizemos que ela tem suporte a TSO. Contudo, o S.O. deve
estar ciente, implemen t a r e reconher TSO pois é o sistem a quem controlar á a
fragmen t aç ão desempe n h a d a pela interface.
Assim sendo uma unidade de dados de 64KB por exemplo, é
normalme n te fragment a d a em 44 unidade s de 1500 bytes pela própria
interface. Com suporte a TSO o FreeBSD pode por exemplo trabal h a r com os
64KB de dados como um único segmento / p a c o te, que é a interface quem
segmen t a r á ele em 44 unida de s de 1500 bytes.
Simplificando, pense na seguinte hipótese. Uma requisição de
tran s mi s s ã o de uma mens age m de correio eletrônico com 128KB de
tama n h o, em um ambiente sem suporte a TSO requer que o FreeBSD divida
esses 128KB em 88 segmentos de 1500 bytes, e o sistem a o fará,
adiciona n do os headers convencionais de fragment aç ão, para que a interface
possa então trans mitir esses dados. Em um ambiente com suporte a TSO,
FreeBSD dividiria pelo tama n h o máximo do segmento suport a do pela
interface, normal me n t e 64KB em ambiente Gigabit. Assim sendo FreeBSD
fragmen t a ria em apena s 2 pacotes, e tran s mitiria- os a interface que, por sua
vez, fragment a esses pacotes em 44 segmentos a cada 64KB. O resultado
disso é que a interface que suport a TSO poderá enviar 44 segmentos a uma
outra ponta que só consiga se comu nic ar com pacotes de tama n h o 1500
bytes mas poderia enviar em um único pacote, para outra interface Gibabit
que suporta s s e 64KB por unidade s de tran s mi s s ões .
Temos ainda a possibilidade e o sistem a decidir como fragment a r para
cada destino, de acordo com regras pré estabelecidas pelo administr a dor de
sistem a s ou de acordo com as caracterísitca s do dispositivo de rede da outra
ponta. Assim sendo pacotes podem ser fragment a do s de forma distinta, por
dema n d a , se a outra ponta for uma interface 100BaseTX, Gigabit ou Frame.
Nem todas interfaces de rede suporta m TSO. No FreeBSD as interfaces
sk(4) suport a m TSO em modo de operação Gigabit, enqu a n to as em(4) da
Intel suport a m em modo Gigabit e també m obtém vantage ns em modo
100BaseTX.
O suporte a TSO no FreeBSD está parcialmen te completo. As
implemen t a çõe s atuais equivalem- se ou tem vantagens sobre a de outros
sistem a s, em especial Solaris e Linux de acordo com benchmark atual
realizado pelo Centro de Computação em Redes de Alta Performance da
Universidade de Washingnto w n em Seattle , onde TSO no FreeBSD em
interfaces Gigabit em(4) tem 3.9 vezes mais performa n ce que o TSO do
Linux no mes mo hardwa re e 3.2 vezes mais performa n ce que Solaris com
TSO no mes mo hardware. TSO estar á disponível apena s no FreeBSD 7, e
esses res ultados compar ativos tendem a melhor ar pois o FreeBSD hoje é de
desenvolvimento, onde inúmeros aspectos de performa n ce não são
otimizados, e outros subsiste m a s estão imcompletos ou em modo de
dep ur a ç ão.
II.IV - Definição autom át i ca de taman h o buffer de soc k e t TCP.
As MIB sysctl(8) net.inet.tcp.sendspace e
net.inet.tcp.recvspace em ambiente de alta performa n ce são alvo
frequen te de tuning específico. Elas são respon s áveis pela alocação de espaço
em memória em avanço (antes de ser utilizado), tenta n do gara ntir sempre
um buffer de memória disponível para todas as operações de tran s mi s s ão
(send) e recepção (recv) de pacotes através da pilha de redes do FreeBSD.
Com essa configuração podemos tran s mitir aproximad a m e n t e a 20Mbit / s de
vazão real em links com latência de até 100ms . Com uma peque n a alteração
man u al, seria possível escalar até 120Mbit / s com a mesm a latência. Porém,
normalme n te essa s alterações tem que ser feitas man u al me n t e, pelo
administr a dor de sistem a s . Com base nisso, as modificações recentes na
pilha de rede fazem esse buffer deixar de ser estático, e torna- se autom á tico.
Conforme o buffer se alinha em uma curva consta n t e de aume n to de
alocação, o FreeBSD detecta potencial dema n d a de mais espaço e aloca, em
página de memória múltiplas de 2, mais espaço para esse buffer, até um
limite predefinido pelo administr a dor de sistem a s ou, se nenn h u m limite for
estabelecido (MIB sysctl(8) valendo 0) enqua n to o sistem a detectar memória
disponível. Com um algorítimo similar, ainda detecta dimin uição de
dema n d a de espaço em buffer , e com um atraso artificialmente imposto para
evitar ciclos adicionais de cons u m o de CPU, pode dimin uir o espaço do
buffer em questão, mante n do sempre janela de 20% da curva média de
dema n d a , gara ntindo espaço para picos de tráfego sem que haja cham a d a as
rotinas de drenage m de memória.
II.V - Definição autom át i ca de taman h o buffer e núm ero de
clus t e r s de buffer de pilha de rede.
Com base nos bons resultados da implemen t a ç ão de alocação
auto m á tica de tama n h o de buffer de socket TCP, a definição autom á tica de
tama n h o buffer e nú mero de clusters de buffer de pilha de rede, idéia teórica
até então, foi encorajad a. Com essa implement aç ão o espaço disponível para
memória tem potencial para se expan dir dinâ mica m e n t e até um fator
percen t u al da quantid a de total de memória disponível, e diminuir
dinâ mica m e n te també m caso muito espaço esteja alocado. O grande
problema dessa impleme nt aç ão é sua interoper a bilidade com outros
sub siste m a s do kernel que já estejam conta n do com um espaça m e n to de
memória disponível. Torna- se necess á rio dina mizar també m outra s regiões
do sistem a s sem relação direta com a pilha de rede para evitar que ambos
sub siste m a s considere m as mes m a s página s de memória disponível,
resulta n do comporta m e n to adverso do sistem a como um todo. Apesar da
gran de dificuldade de impleme nt aç ão, esta está sendo realiada, e també m
deve estar concluída até o FreeBSD 7.0- RELEASE. Com essa s dua s
modificações estare mo s diante do fim de event u ais problem a s de “no buffer
space available” que diagnostica m dema n d a imediata de tuning na pilha de
rede do FreeBSD.
II.VI - Otimização do tcp_outpu t() para melhoria de performan c e
do soc k e t de envio.
Com a definição autom ática de tama n h o do buffer de socket de envio
de dados e conseque n te maior dema n d a de memória para conexões de ban d a
larga (aqui, como banda larga estamos nos referindo a conexões Gibagit) e
em conexões com grande delay, o tcp_outp u t() torno u- se proporcionalme n te
ineficiente em relação às novas muda n ç a s dos segmentos de trans mi s s ã o de
dados.
Na implement aç ão anterior, em cada segmento enviado de dados
tran s p o s to sobre o buffer inteiro de rede, a cadeia mbuf é process a d a até que
encontre o offset do ponto em que deve contin u a r . Normalme n te esse ponto é
encontr a do próximo ao fim da cadeia. Uma vez que algum a s dúzias de mb ufs
sejam cons u mi dos, a dema n d e de cache de CPU aume n t a e a performa nce
começa a sofrer depreciação.
A nova implement aç ão resolve esse problema mante n do um ponteiro
padr ão no buffer do socket para oferecer ao tcp_outp u t() o mbuf mais
próximo, evitando que haja um reinicio da análise da cadeia. Ou seja com
essa estr ut u r a o ponteiro atua como uma lista que sempre aponta para o
próximo segmento mbuf, de forma que o tcp_outp u t() sempre saber á quem é
o próximo e onde encontr á- lo. Nunca mais re- analisar á a cadeia de
segmen tos toda.
III - Conclusão
Testes compar a tivos de performa n ce realizados pelo próprio Projeto
FreeBSD ou instit uições indepen de n te s , com a WU de Seattle demons t r a m
que no FreeBSD -STABLE as impleme nt ações já incorpor a d a s através de
MFC bem como as parcialmen te incorpor ad a s represe nt a m ganhos
significativos de performa n ce, enqua n to a maioria das grandes mud a n ç a s
estar ão disponíveis aos us u á rios finais apena s com o FreeBSD 7. Testes
desem pe n h a d o s pelas mesm a s organizações mostr a m aume n to ainda mais
interes s a n t e de ganho de performa n ce sobre o FreeBSD atual, variando de
fatores de 3 vezes à 6 vezes, e ganho sobre outros sistem a s , em especial
Linux e Solaris variando de fator de 5 vezes à fator de até 11 vezes.
Com essas modificações FreeBSD começa a mais uma vez curvar
positivame nt e a linha de performa n ce compar a tiva uniforme em sua pilha de
rede TCP /IP, destaca n do- se ainda mais frente à outra s impleme nt ações,
especialme n te nos trechos onde as implement ações são apena s equivalentes,
e au me n t a n d o o destaq u e onde as implement ações FreeBSD já se
sobres aia m.
IV – Referên cias
•
Sobre atividades na pilha de rede e Bench m a r k da Universidade de
Washingtow n: http: / / w w w .os n ew s.com / s t o r y.p h p / 1 6 9 7 6 / F r e e BS DNtworkStck
•
Modificações (código, referência inter na):
http: / / p e o ple.freebs d.org / ~ a n d r e / s e n dfile- 200609 2 0.diff,
http: / / p e o ple.freebs d.org / ~ a n d r e / s o s e n d+ m_ uiotom b uf200609 2 8.diff, http: / / l i s t s .freebs d.org / p i pe r m ail / f reeb s dcurrent / 2 0 0 6 - Septem ber / 0 6 5 9 0 4 . h t ml,
http: / / p e o ple.freebs d.org / ~ a n d r e / s o c k b uf_s n d p t r - 2007030 1. diff
•
Resu mo
das
atividades
desenvolvidas
por
Opper m a n :
http: / / p e o ple.freebs d.org / ~ a n d r e /

Melhorias na Pilha de Rede do FreeBSD, uma análise.

Transcrição

Documentos relacionados

How-to de instalação do FreeBSD

SITUAÇÃO : REGULAR PROCESSO Nº : 2016.10000

Seriados e Campanhas Publicitárias de TV

Lojamundi – Tecnologia Sem Limites www.lojamundi.com.br

Contas a pagar - Átimo Software

Labnet Ciencor 0840424 1139

Patrick Swayze e produtos de saúde dominam spams da semana

2012 - Sudene

Termo de Julgamento

Publicação no diário oficial sobre a estrada!

MINISTÉRIO PÚBLICO DO TRABALHO