O desempenho de operações de E / S massivas depende muito mais da velocidade do HDD e da carga de E / S atual, em vez da CPU.
Alguns de nossos proprietários de aplicativos estão dizendo que vários processos estão levando o dobro do tempo de execução que deveriam.
Este tem a nossa cabeça arranhando.
Não podemos entender por que algumas operações levam o dobro do tempo no Servidor 1 do que o Servidor 2.
Servidor 1: IBM x3850 M2 (atualização Nahant 4 do RHEL 4)
O servidor 1 está mais ocioso do ponto de vista do IO. S1 e S2 são ambos em unidades SAS no Raid 5. O servidor 1 possui 4 unidades, o Servidor 2 possui 4 unidades. Saída do Iostat do servidor 1
Linux [hostname-removed] 2.6.9-89.ELsmp # 1 SMP seg 20 de abril 10:34:33 BRT 2009 i686 i686 i386 GNU / Linux
Saída de / proc / cpuinfo
Saída de / proc / meminfo
Servidor 2: IBM x3650 (atualização 8 Nahant do RHEL 4)
O servidor 2 é o mais ativo dos dois servidores. A saída iostat parece que há uma tonelada de dispositivos conectados por causa do multipath de SAN. A operação dd e a operação tar foram feitas no armazenamento local. Saída do Iostat do servidor 2
Linux [nome-do-host removido] 2.6.9-78.0.13.ELsmp # 1 SMP Wed Jan 7 17:52:47 EST 2009 i686 i686 i386 GNU / Linux
Saída de / proc / cpuinfo
Saída de / proc / meminfo
Como esperado, a operação de gravar um arquivo de 1 GB é mais rápida no Servidor 1
[server1]$ time dd if=/dev/zero of=bigfile bs=1024 count=1048576
1048576+0 records in
1048576+0 records out
real 0m15.032s
user 0m0.961s
sys 0m11.389s
Versus Servidor 2, isso parece verificar:
[server2]$ time dd if=/dev/zero of=bigfile bs=1024 count=1048576
1048576+0 records in
1048576+0 records out
real 0m27.519s
user 0m0.531s
sys 0m8.612s
No entanto, tarballing esse mesmo arquivo no servidor 1 leva o dobro do tempo do 'usuário' e um pouco mais em tempo real.
[server1]$ time tar -czf server1.tgz bigfile
real 0m27.696s
user 0m20.977s
sys 0m5.294s
[server2]$ time tar -czf server2.tgz bigfile
real 0m23.300s
user 0m10.378s
sys 0m3.603s
O desempenho de operações de E / S massivas depende muito mais da velocidade do HDD e da carga de E / S atual, em vez da CPU.
Estes são exatamente os tipos de problemas que uma ferramenta como o collectl é ideal para endereçamento. Produzir o tempo necessário para que o dd ou o tar sejam executados é um bom começo, mas o que está acontecendo entre eles? Suas taxas de E / S estão estáveis ou estão atingindo vales e barracas? Existem todos os tipos de coisas que podem dar errado do começo ao fim.
Como você tem um sistema com um perfil de desempenho 'bom' conhecido, está na melhor posição para realmente resolver esse problema. Execute seus testes junto com o collectl e assista a sua cpu, memória, rede e discos (todos na mesma linha, facilitando a visualização das tendências ao longo do tempo). Você também pode ver coisas como nfs, tcp, sockets e várias outras coisas, mas suspeito que isso não se aplica a este caso.
Agora repita o teste na caixa sabendo que tem um desempenho ruim e veja o que é diferente. A resposta estará lá. Pode ser a falta de memória, muitas interrupções na CPU (o grupo também pode mostrar isso) ou grandes tempos de espera de E / S. O que quer que seja coletado pode identificá-lo para você, mas então você tem que descobrir qual é a causa raiz. Pode ser um disco altamente fragmentado ou até ruim. Talvez haja algo errado com um controlador. Essa parte é para você descobrir.
Espero que isso ajude ...
-mark
Tags performance tar linux