Como eu diagnostico um gargalo em um servidor Ubuntu baseado em Intel Atom?

1

Eu tenho um pequeno servidor de mídia em casa que tem software RAID e um link gigabit para o resto da minha rede.

Por alguma razão, eu só recebo transferências de ~ 10MB / s ao copiar para / do servidor.

Eu uso o software RAID5 (mdadm) em 4 discos de 1 TB. Além disso, uso o LVM para criar um grande espaço em disco que é dividido em várias partições, que podem ser redimensionadas quando e como forem necessárias. Eu estou supondo que provavelmente a causa, mas eu gostaria de saber com certeza onde está a causa raiz.

Então, como posso avaliar o rendimento da rede (o Windows 7 desktop < - > Ubuntu server) e o desempenho do disco rígido para tentar identificar onde meu gargalo pode estar?

[Editar] Se alguém estiver interessado, a placa-mãe é uma Intel Desktop Board D945GCLF2 . Então é um processador Atom série 300 com o Chipset Intel® 945GC Express

[Edit2] Eu me sinto como um idiota! Acabei de verificar minha área de trabalho e tive o mais lento das duas placas de rede onboard conectadas para que o servidor provavelmente não está em falta aqui. Transferindo uma cópia do Ubuntu do servidor eu recebo ~ 35-40MB / s de acordo com o Windows 7. Eu vou fazer esses testes HD quando tiver uma chance (apenas para completar).

    
por Jon Cage 09.04.2010 / 10:58

4 respostas

0

Acontece que era a máquina desktop que eu estava usando; estava correndo a 100MBit. Obrigado por todos os conselhos - pode ser muito útil para benchmarking e melhorar a velocidade geral do meu sistema!

    
por 29.04.2010 / 11:12
4

Como Antoine disse: Uma CPU Atom e SW RAID são uma má ideia. Para medir o troughput de seus discos, você pode usar hdparm .

Veja isto: link

Você deve medir seus dispositivos de disco e seus dispositivos de raide separadamente. Dessa forma, você pode ver se os discos estão lentos (quebrados?) Ou se o RAID está lento. Também dê uma olhada no uso de sua CPU (por exemplo, com top ) enquanto mede ou acessa seu RAID de outra maneira.

Se esse não for o gargalo, verifique se o GBEthernet Link está usando sua capacidade total. Dê uma olhada na saída de ifconfig . O meu diz o seguinte (Mac OS X 10.6, deve ser semelhante no Ubuntu):

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 64:b9:e8:bf:8f:b4 
    inet 192.168.0.5 netmask 0xffffff00 broadcast 192.168.0.255
    media: autoselect (1000baseT <full-duplex,flow-control>)
    status: active

2a linha da parte inferior: 1000baseT significa: GB Ethernet!

[editar] Eu encontrei este artigo: link Recomenda sar e iostat para monitorar o IO do disco.

    
por 09.04.2010 / 11:30
2

Algumas coisas para verificar:

  • verifique se a NIC está realmente em Gbit mais, não 10Mbit com ethtool eth0 (substitua eth0 pelo ID do dispositivo da NIC relevante, se diferente), procure a leitura "velocidade" para o modo atual
  • verifique se o Windows está atualmente usando sua placa no modo Gbit também
  • verifique qual carga de CPU e E / S é imposta ao servidor durante a transferência - se você vir (em top ou similar) um núcleo em quase 100% do estado de espera de E / S, suas unidades serão as gargalo, se você ver alta "sistema" uso da CPU, em seguida, a CPU é o bottlneck (poderia ser uma mistura dos dois para gravações devido a "write - > read + read + write + write" do RAID 5 atingido em quatro unidades e os cálculos de paridade feitos pela CPU, se as leituras do sistema ou do IO forem altas, a rede provavelmente será o gargalo.
  • teste o desempenho de leitura em massa apenas no servidor (para testar o desempenho de E / S bruto, independentemente da rede): cat um arquivo grande para /dev/null para ver até onde vai (faça echo 3 > /proc/sys/vm/drop_caches para conhecer o IO está realmente batendo nos discos e não vindo da memória, e se você tiver instalado, use pv ao invés de cat, pois ele dá velocidade útil + leituras de progresso), observando a carga da CPU + IO, pois isso também acontece
  • teste o desempenho de gravação em massa com cat /dev/zero > /some/file/on/the/array (ou pv /dev/zero > /some/file/on/the/array ), observando o uso da CPU, pois isso também acontece.
  • taxa de transferência de rede test bluk, independentemente do desempenho da unidade / matriz, entre as máquinas com netcat e pv - na máquina Win7 faça nc -l -p 123 > NUL e no servidor então pv /dev/zero | nc 1.2.3.4 123 onde 1.2.3.4 é o Windows endereço da caixa (você pode terminar para adicionar uma exceção de firewall para nc ).

Como você está vendo uma taxa fixa de ~ 10Mbyte / seg eu suspeitaria de um problema de rede primeiro do que de um gargalo nos discos ou CPU - mas o RAID5 em uma CPU Atom pode ser um dos gargalos, então você pode querer considerar RAID1 + 0 ou RAID10 (se a sua matriz RAID5 for 3 + mais sobressalente, o driver RAID10 do Linux com 3 + reserva deve fornecer redundância semelhante (qualquer falha de unidade individual é perceptível) mas com melhor desempenho (escrever- > escrever * 2 em vez de escrever-> ler + paritycalc + escrever * 2) , no modo de 3 unidades o driver RAID10 faz algo semelhante ao que os controladores IBM chamam de RAID-1E, consulte link ).

editar:

Adicionado algo extra para testar na lista acima e outros detalhes menores

    
por 09.04.2010 / 11:31
1

Primeiro de tudo, você está usando o SMB / CIFS, que não é um protocolo muito rápido, (é definitivamente mais lento que o NFS, para referência).

Em segundo lugar, depende da carga de trabalho que você está testando. É principalmente sequencial ou aleatório? Se for principalmente E / S aleatória, então 10MB / s provavelmente está OK. Realisticamente, a partir de uma placa de rede GB você pode esperar 30-50MB / s do CIFS (mas, como eu disse, pode ser maior ou menor, dependendo da carga de trabalho).

Você também pode verificar essa outra resposta do serverfault para ajuste de desempenho do CIFS.

Uma pesquisa rápida revelou esta página com resultados do desempenho do CIFS . Você pode achar útil.

Finalmente, você pode testar o desempenho da rede com iperf (ele também pode ser compilado para janelas e você pode encontrá-lo pré-compilado em algum lugar)

    
por 09.04.2010 / 11:55