Eu recentemente fiz alguns testes de desempenho em um novo servidor (usando dd) e me pergunto por que o desempenho de leitura é muito pior do que o desempenho de gravação? Não deveria ser outra maneira de contornar?
o tamanho do arquivo foi em ambos os testes 550GB, ler: em segundos: 3704 em MB / s: 148
e escreva: em segundos: 1539 em MB / s: 357
comando de gravação:
time sh -c "dd if=/dev/zero of=/local/postgresql/bigfile
bs=8k count=67108864 && sync"
comando de leitura:
time dd if=/local/postgresql/bigfile of=/dev/null bs=8k
saída do comando bash time:
real: 61m44.335s
user: 0m12.721s
sys: 10m35.884s
Resultados Bonnie ++ comando:
bonnie++ -f -D -n 0 -u root -d /local/postgresql/
os resultados são para arquivos com o dobro do tamanho da RAM.
escreva:
419 918 K / s
leia:
~ 187 000 K / s
Você precisa usar os sinalizadores de sincronização de gravação para testar o desempenho, para garantir que esteja realmente gravando no disco e não no cache. Use conv=fdatasync para forçar uma sincronização de buffers após a gravação terminar. Veja aqui para detalhes.
time dd .... conv=fdatasync
para teste de leitura, descarte caches antes do teste:
flush
echo 3 | sudo tee /proc/sys/vm/drop_caches
time dd ....
Qual foi o comando que você usou? dd faz muito coisas diferentes relacionadas a percormance dependendo das opções.
Mas pelo que você escreve,
Eu acho que você estava lendo blocos pequenos, que serão lidos no disco como você pede, aproximadamente.
E você escrevendo pequenos blocos, que serão gravados no disco quando o kernel achar que tem tempo para fazê-lo - não quando dd os escrever.
Isso já explicaria a diferença, certo?
Tenho muita dúvida de que você pode obter benchmarks significativos de dd . dd mostra apenas como grandes leituras sequenciais ou grandes gravações assíncronas seqüenciais executam entre vários dispositivos. Contanto que sua carga de trabalho consista principalmente na cópia de arquivos grandes entre esses sistemas de arquivos, você está bem. Eu duvido que essa seja sua carga de trabalho.
Sua melhor aposta é fazer o perfil do uso do disco e usar uma verdadeira suíte de benchmarking de E / S (link bonnie++ ou algo assim) para testar quanto efeito a alteração de vários tunables tem. Para um banco de dados, eu esperaria muitas leituras aleatórias. Definir noatime e fazer data=writeback em seus arquivos de dados principais (com backups regulares sendo feitos) é provavelmente o melhor que você pode fazer com as informações que temos até agora.
Para responder ao que parece ser a sua maior questão, é porque as gravações assíncronas (como as feitas por dd ) podem ser armazenadas em buffer na memória e confirmadas no disco. Eles são kind de I / O ligado na medida em que filas e buffers podem preencher e você teria que esperar que eles se tornassem disponíveis novamente (ao se comprometer em disco) antes que você pudesse empilhar mais.
As leituras, por outro lado, são definidas como E / S limitadas, portanto, você não costuma executar a mesma ação assíncrona. Você pode brincar com read_ahead_kb e afins para que mais dados sequenciais sejam lidos na memória antes de serem solicitados pela carga de trabalho no futuro próximo.
Isso é tudo o que posso pensar em responder com o que sabemos até agora. Deixe-me saber se você tem alguma dúvida.
Tags performance dd hard-disk