Editar : o problema está resolvido. As filas em questão foram usadas para pacotes de controle de fluxo. Por que o driver igb propagou pacotes FC para tê-los descartados (e contados) é outra questão. Mas a solução é que não há nada descartado de forma que os dados se perderam.
Muito obrigado, syneticon-dj, seu ponteiro para dropwatch era ouro!
=== pergunta original para referência futura ===
temos a seguinte situação:
Sistema:
O servidor em questão é um poweredge da Dell com 4 processadores quad-core de xenon, 128GB de RAM ECC e está executando o Debian Linux. O kernel é 3.2.26.
As interfaces em questão são placas iSCSI especiais com quatro interfaces, cada uma usando o Intel 82576 Gigabit Ethernet Controller.
Background: Em um dos nossos servidores, muito NAS (Thecus N5200 e Thecus XXX) são conectados usando iSCSI em interfaces dedicadas de 1GB / s. Nós temos 5 cartões com 4 portas cada. Os arquivadores NAS são conectados diretamente, sem alternar entre eles.
Duas semanas atrás, conseguimos limpar quatro arquivadores NAS e usá-los para criar um raid6 usando o mdadm neles. Usando o LVM isso nos permite criar dinamicamente, encolher e / ou aumentar o armazenamento para nossos vários projetos, em vez de pesquisar todos os nossos arquivadores NAS por espaço livre de vez em quando.
No entanto, temos muitas superações em praticamente todas as interfaces e muitos pacotes foram descartados. As investigações mostraram que as configurações padrão para as pilhas de rede tinham que ser aumentadas. Eu usei o sysctl para ajustar todas as configurações até que não ocorram mais ocorrências.
Infelizmente, as interfaces usadas para o ataque NAS ainda soltam muitos pacotes, mas apenas RX.
Após pesquisar (aqui, google, metager, intel, em qualquer lugar, em qualquer lugar) encontramos informações sobre os drivers intel igb para ter alguns problemas e que algum trabalho precisa ser feito.
Assim, baixei a última versão (igb-4.2.16), compilei o módulo com LRO e suporte a filas separadas e instalei o novo módulo.
Todas as 20 (!) interfaces que usam esse driver agora têm 8 filas RxTx (não pareadas) e têm a LRO habilitada. A linha de opções concretas é:
options igb InterruptThrottleRate=1 RSS=0 QueuePairs=0 LRO=1
O
irqbalancer está distribuindo bem as filas de todas as interfaces e tudo funciona de forma esplêndida.
Então, por que estou escrevendo? Nós temos a seguinte situação estranha e simplesmente não podemos explicar isso:
Três das cinco interfaces para a invasão NAS (adicionamos um NAS reserva, e a invasão deve ser aumentada depois que o mdadm tiver terminado sua remodelação atual) mostra uma quantidade enorme (milhões!) de pacotes perdidos.
Investigações com o ethtool agora mostram, graças aos novos drivers habilitados para várias filas, que cada interface usa uma fila massivamente, essa será a reformulação que imaginamos.
Mas três usam outra fila com milhões de pacotes de entrada, todos descartados. Pelo menos mostrou investigações utilizando 'watch', que os números de pacotes nessas filas se correlacionam com os pacotes descartados.
Alteramos o MTU no NAS e as interfaces de 9000 para 1500, mas a taxa de queda de pacotes aumentou e o desempenho do mdadm diminuiu. Assim, não parece um problema de MTU. Além disso, a pilha de rede tem quantidades insanas de memória à sua disposição, isso também não deve ser um problema. backlogs são grandes o suficiente (enormes, de fato) e estamos completamente no mar.
Tem uma saída de exemplo aqui:
~ # for nr in 2 3 4 5 9 ; do eth="eth1${nr}" ; echo " ==== $eth ==== " ; ethtool -S $eth | \
> grep rx_queue_._packet | grep -v " 0" ; ifconfig $eth | grep RX | grep dropped ; \
> echo "--------------" ; done
==== eth12 ====
rx_queue_0_packets: 114398096
rx_queue_2_packets: 189529879
RX packets:303928333 errors:0 dropped:114398375 overruns:0 frame:0
--------------
==== eth13 ====
rx_queue_0_packets: 103341085
rx_queue_1_packets: 163657597
rx_queue_5_packets: 52
RX packets:266998983 errors:0 dropped:103341256 overruns:0 frame:0
--------------
==== eth14 ====
rx_queue_0_packets: 106369905
rx_queue_4_packets: 164375748
RX packets:270745915 errors:0 dropped:106369904 overruns:0 frame:0
--------------
==== eth15 ====
rx_queue_0_packets: 161710572
rx_queue_1_packets: 10
rx_queue_2_packets: 10
rx_queue_3_packets: 23
rx_queue_4_packets: 10
rx_queue_5_packets: 9
rx_queue_6_packets: 81
rx_queue_7_packets: 15
RX packets:161710730 errors:0 dropped:4504 overruns:0 frame:0
--------------
==== eth19 ====
rx_queue_0_packets: 1
rx_queue_4_packets: 3687
rx_queue_7_packets: 32
RX packets:3720 errors:0 dropped:0 overruns:0 frame:0
--------------
A nova unidade sobressalente está conectada à eth15.
Como você pode ver, não há excessos nem erros. E os adaptadores relatam que não descartaram um único pacote. Assim, é o kernel jogando dados para longe. Mas por quê?
editar : esqueci de mencionar que eth12 para eth15 estão todos localizados no mesmo cartão. eth19 em outro.
Alguém já testemunhou um comportamento tão estranho, e houve uma solução para remediar a situação?
E, mesmo que não, alguém conhece algum método com o qual possamos pelo menos descobrir qual processo ocupa as filas de descarte?
Muito obrigado antecipadamente!