Eu tenho uma máquina de 24 núcleos com 94.6GiB de RAM executando o servidor Ubuntu 10.04. A caixa está experimentando alta% iowait, ao contrário de outro servidor que temos (4 núcleos) executando os mesmos tipos e quantidades de processos. Ambas as máquinas estão conectadas a um servidor de arquivos VNX Raid, a máquina de 24 núcleos via 4 placas FC e a outra a placas de 2 gigabits. A máquina de 4 núcleos atualmente supera a máquina de 24 núcleos, tem maior uso de CPU e menor% iowait.
Em nove dias de atividade, a média do% iowait é de 16% e está rotineiramente acima de 30%. Na maior parte do tempo, o uso da CPU é muito baixo, em torno de 5% (devido ao alto iowait). Há muita memória livre.
Uma coisa que não entendo é por que todos os dados parecem estar passando pelo sdc do dispositivo, em vez de passar diretamente pelos movimentadores de dados:
avg-cpu: %user %nice %system %iowait %steal %idle
6.11 0.39 0.75 16.01 0.00 76.74
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.00 0.00 0.00 1232 0
sdb 0.00 0.00 0.00 2960 0
sdc 1.53 43.71 44.54 36726612 37425026
dm-0 0.43 27.69 0.32 23269498 268696
dm-1 1.00 1.86 7.74 1566234 6500432
dm-2 0.96 1.72 5.97 1442482 5014376
dm-3 0.49 9.57 0.18 8040490 153272
dm-4 0.00 0.00 0.00 1794 24
dm-5 0.00 0.00 0.00 296 0
Outra parte do quebra-cabeça é que as tarefas freqüentemente entram em modo de inatividade ininterrupta (no topo), provavelmente também devido ao holdup de io.
O que posso analisar para ajudar a diagnosticar o problema? Por que todos os dados estão passando por / dev / sdc? Isso é normal?
ATUALIZAÇÃO:
A conexão de rede e a capacidade de leitura / gravação do VNX foram descartadas como gargalos. Podemos atingir velocidades de 800MB / s com as 4 NICs ligadas (round-robin). As placas de canal de fibra ainda não estão sendo usadas. O VNX é capaz de lidar com os discos IO (RAID6, 30x2TB 7.2kRPM por pool em dois pools (60 discos no total), cerca de 60% de leitura).
Ignore acima sobre dm e sdc, eles são todos discos internos e não fazem parte do problema.
Achamos que o problema pode estar nas montagens nfs ou TCP (temos 5 montagens em 5 partições no VNX), mas não sabemos exatamente o que. Algum conselho?
Obrigado a todos pelas ideias e sugestões. O problema estava relacionado a uma combinação de configuração de ligação Ethernet não ideal, combinada com um módulo de E / S defeituoso no próprio VNX. A taxa de E / S está agora perto de onde esperamos. É interessante notar que os testes de leitura e escrita de arquivos dd e os benchmarks iozone não foram capazes de detectar isso, e podiam ler e escrever quase tão rápido quanto o esperado.
Exemplo, vamos supor que seu armazenamento possa fornecer uma taxa de transferência de 500MB / s, que você está conectado via 2 Gigabit Ethernet Line (ligação), a rede já limitará o throughput máximo a algo em torno de 100-180 MB / s. Se o seu processo comer dados na velocidade de 50 MB / se você executar 4 threads na sua máquina de 4 núcleos: 4 x 50 MB / s = 200 MB / s consumidos. Se a rede puder suportar os 180MB / s, você não terá muita latência e suas CPUs serão carregadas. A rede aqui é um pequeno gargalo.
Agora, se você dimensionar isso para 24 núcleos e 24 encadeamentos, você precisaria de 1200 MB / s, mesmo se você alterar a fiação para permitir esse rendimento, seu sistema de armazenamento não fornecerá mais de 500 MB / s, ele se tornará um gargalo.
Quando se trata de esperar, os gargalos podem estar em todo lugar. Não apenas nas camadas físicas, mas também em software e buffers de espaço do kernel. Isso realmente depende dos padrões de uso. Mas, como os afunilamentos de software são muito mais difíceis de identificar, geralmente é preferível verificar o rendimento teórico no hardware antes de investigar as pilhas de software.
Como dito, um iowait ocorre quando um processo faz uma leitura e os dados demoram a chegar, ou quando faz uma gravação de sincronização e a confirmação de modificação de dados leva seu tempo. Durante uma gravação de sincronização, o processo entra no modo de espera ininterrupta para que os dados não sejam corrompidos. Existe uma ferramenta útil para ver qual chamada faz um processo travar: latencytop . Não é o único do seu tipo, mas você pode tentar.
Observação: para sua informação, dm significa mapeador de dispositivo e não movedor de dados.
Primeiro de tudo, inferno sagrado que é muito ferro! :)
Infelizmente, como sua configuração parece muito complexa, não acho que ninguém conseguirá fornecer uma resposta imediata "Existe o seu problema!" responda, a menos que eles tenham feito algo com uma configuração extremamente semelhante ou idêntica e tenham encontrado o mesmo problema. Então, enquanto este texto é rotulado pelo SU como uma "Resposta", você provavelmente deve considerar mais como uma "Sugestão". E não posso colocar nos comentários porque são muitas palavras. : S Sem o conhecimento de como seu hardware é mapeado para os dispositivos, é difícil dizer por que o I / O está indo para um lugar e não para outro. Como você tem os dispositivos montados? Seus programas estão acessando diretamente os dispositivos sd* , ou todos os seus sistemas de arquivos estão montados nos dispositivos dm e todos os acessos a arquivos ocorrem por lá?
Outras coisas sobre as quais preciso perguntar:
Que tipo de RAID é esse? Se você está calculando bits de paridade com RAID5 ou RAID6, isso é cuidado pelo hardware do servidor RAID ... se não, os servidores de processamento estão fazendo isso ... o que é sub-ótimo e pode causar latência de E / S se feito em software.
Você isolou uma das principais diferenças entre os dois servidores em sua mensagem. Um está usando o canal de fibra e um está usando ethernet. O Fibre Channel deve fornecer melhor latência e largura de banda, mas talvez isso também seja um problema: se estiver fornecendo muito throughput, isso pode tornar o servidor RAID muito ocupado ... e o congestionamento leva a buffers / caches enchendo-se, o que aumenta a latência, o que causa maiores esperas de E / S.
É quase como se você pudesse ter um problema de buffer bloat com seus arrays de disco - sabe? Controladores RAID de hardware normalmente têm uma grande quantidade de cache on-board, não é? Assim, à medida que a E / S da mídia é enfileirada e os caches ficam cheios de páginas sujas, eventualmente tudo fica saturado (se o armazenamento mecânico não conseguir acompanhar a carga) e a latência passa pelo telhado ... certamente você pode produzir mais carga com 24 núcleos + FC do que com 4 núcleos + GbE :) Verifique o servidor RAID e veja como os discos estão ocupados ... muito da "E / S" pode ser apenas pacotes de controle, etc. Não tenho certeza de como o FC funciona, mas se for algo como o TCP, você verá retransmissões se as latências forem muito altas.
Como se você perguntasse a alguém uma pergunta pelo telefone e ela não respondesse por alguns segundos, você dizia "Olá?" - os protocolos de rede (e o FC é apenas um protocolo de rede) fazem a mesma coisa, apenas em uma escala de tempo menor. Mas é claro que esse extra "Olá"? é caro no contexto da rede porque adiciona ainda mais dados a um pipe já congestionado.
Para encerrar, uma dica geral:
Ao depurar problemas de latência / IO espera / taxa de transferência, sempre mede . Meça em todos os lugares. Meça no fio, meça o que os próprios programas estão fazendo, meça no final do processamento, meça no servidor RAID, etc. Não olhe apenas de uma perspectiva - tente considerar cada componente individual do sistema que está responsável pelo processamento, leitura ou gravação de qualquer um dos dados no pipeline. Desmonte uma transação ou uma unidade de trabalho discreta e dissecar exatamente o caminho percorrido pelo seu hardware, e meça em cada componente distinto para ver se há pontos de estrangulamento ou locais em que haja latência indevida, etc. Um amigo meu chamou isso de "descamação" voltar a cebola ", e eu usei a frase desde então para se referir à tarefa de depuração de um fluxo de dados.
Uma pequena adição. Talvez você queira examinar seus planejamentos de nível de bloco e de programação de E / S nesse caso. Eu não sou tão familiarizado com o Ubuntu, mas há uma boa quantidade de botões de desempenho de armazenamento para ajustar. Isso definitivamente se aplica no caso de armazenamento SAN e bancos de dados.
nobarrier . ( Sugestão para o Ubuntu ) Alguns links relevantes de falha do servidor ...
Linux - ajuste de controlador RAID de hardware do mundo real (scsi e cciss)
Eu vou editar com mais informações em breve, mas primeiro eu gostaria de dizer que você não deve deixar a saída dm- * do iostat confundir você. O Device-mapper é um dispositivo intermediário no kernel exatamente como md * (md0, md1, etc.), portanto, você realmente se importa apenas com seus dispositivos subjacentes. Todos os dados transmitidos para seus discos passam por dm / md no caminho, e os totais reais (bytes, segundos, etc.) são precisos, mas o utilitário é enganoso.
Além disso, essa é uma quantidade muito grande de memória. Coisas engraçadas começam a acontecer tão alto (eu mesmo corro 2x64s e 2x96s), especialmente se você tiver um processo ocupando mais da metade do carneiro. Leia este artigo para mais informações . O artigo menciona o mysql mas por favor note que ele não é específico do mysql. Todo processo de software irá incorrer em penalidades para a memória de acesso de outro processador físico - pense que 48gb pertence a um proc, 48 a outro. O processo só pode pertencer a um proc e para alcançar a outra memória procs (depois que os próprios 48GB acabaram), ele deve decidir armazenar alguma das 48 em troca ou pagar um preço enorme para conseguir & da memória do outro proc. O artigo sugere a execução de um comando numactl para forçar o software a não trocar e, em vez disso, pagar a penalidade. Eu pessoalmente tenho visto grandes melhorias disso. Em outras palavras - verifique se algum dos seus I / O vai trocar! Use free -m (ou similar) para isso. Se você tem muita memória livre, mas uma quantidade não trivial de swappage (digamos, 10% a mais), isso pode muito bem ser o seu problema.
Olhando isso da perspectiva de armazenamento, você tem uma maneira de medir a latência do scsi? O tempo de espera do SO io inclui um monte de coisas fora do controle do armazenamento, mas quando entro em minha caixa de armazenamento e vejo a latência IO a 2ms, sei que, independentemente do servidor que está recebendo internamente, os comandos scsi estão sendo respondidos rapidamente, e posso eliminar o armazenamento como uma variável.
Tags io linux ubuntu-10.04 bottleneck