Resultado inconsistente do desempenho do tamanho do bloco de leitura / gravação, o teste está correto?

Question

Estou tentando fazer alguns testes em termos de tamanho de bloco do sistema de arquivos para identificar algum gargalo potencial em um trabalho de grade devido a um mau IO. Eu observo um grande incremento de arquivo pequeno de 8096 B durante o trabalho enquanto o tamanho do bloco do FS é:

stat -fc %s /my/filesytem
1048576

O que está longe de ser ideal. Para simular esse comportamento, criei dois pequenos arquivos aleatórios, de 1 GB a 20 GB, com dd e /dev/urandom como fonte, e testei este código python:

#!/bin/python
bsize=8096
print('File random.20g1')
print(strftime("%Y-%m-%d_%H:%M:%S"))
f1= open('random.20g1','rb')
f2= open('random.20g1.dest','wb')

while True:
   b = f1.read(bsize)
   if b:
       f2.write(b)
   else:
       break
print(strftime("%Y-%m-%d_%H:%M:%S"))

E eu tentei o mesmo com bsize=1048576 .

Primeiro observo uma pequena diferença de tempo de leitura / gravação de 4 segundos entre um tamanho de bloco de 8096 e 1048576 (4 segundos a menos para o tamanho de bloco grande). Este primeiro resultado foi promissor, mas depois de mais testes, como aumentar o tamanho do arquivo para 20GB ou fazer o mesmo com 10 arquivos de GB, eu sempre observo a mesma diferença de 4/3 segundos em termos de desempenho e o ganho nunca é escalável Arquivo.

Estou fazendo algo errado no meu procedimento de teste ou parece OK para você?
Eu teria esperado alguma melhora no aumento do tamanho do arquivo, por exemplo.

    

Answer 1

Este código

while True:
   b = f1.read(bsize)
   if b:
       f2.write(b)
   else:
       break

está fazendo sequenciais leituras e gravações - dado qualquer bsize , ele lê o primeiro bsize bytes, grava no arquivo de destino, depois lê o segundo bsize bytes, acrescenta esses para o arquivo de destino, ...

Seu sistema operacional armazenará esses buffers por meio do cache de páginas e poderá até ler antecipadamente e pré-armazenar em buffer sua entrada dados como @StephenKitt mencionados nos comentários. Assim, as chamadas de IO subjacentes para o disco real acabarão coalescidas em pedaços muito maiores, provavelmente o 1 MB que você mencionou.

A pequena diferença que você vê no desempenho é quase certamente devida apenas porque quando você usa um bsize menor, seu processo precisa fazer mais chamadas ao kernel para realmente mover os dados.

Então, é quase certo por que você não vê muita diferença quando você altera bsize no seu código de teste, mas não é realmente possível dizer com certeza sem muito mais detalhes sobre o seu sistema.

MAIS ...

O que você está fazendo é efetivamente idêntico a

dd if=random.20g1 of=random.20g1.dest bs=8192

Se você realmente usasse dd , você pode fazer muito mais coisas para testar o disco rígido (basta olhar para a página de manual - você pode usar E / S direto para ignorar o cache de páginas, por exemplo), mas no final, o teste de E / S que você pode fazer com dd é bastante limitado ser sequencial. dd mostrará o seu desempenho de IO melhor , mas não pode simular muitas cargas de trabalho reais que revelam as desvantagens do desempenho do IO.

Você precisa determinar mais sobre o padrão IO que seu trabalho em grade realmente usa - ele está fazendo leituras / gravações seqüenciais como em seu teste, ou está fazendo aleatório leituras e / ou gravações onde ele procura no arquivo (s) para um local efetivamente aleatório antes de fazer o IO? Operações aleatórias de E / S são muito mais exigentes em um sistema de arquivos e hardware de disco subjacente - especialmente discos giratórios. Sistemas que podem mover centenas de MB / s de I / O sequencial de fluxo podem ser reduzidos a literalmente um punhado de kilobytes por segundo por operações IO aleatórias de pequeno porte. Especialmente se você estiver usando discos SATA S-L-O-W de 5.000 RPM.

Pode ficar muito ruim quando pessoas que não entendem sistemas de arquivos e matrizes RAID configuram armazenamento. O sistema de arquivos de 1 MB que você menciona com certeza parece estar lidando com uma configuração do sistema de armazenamento sob um paradigma equivocado de que "maior é sempre mais rápido".

Misturar um paradigma "maior sempre é mais rápido" com coisas como matrizes RAID5 / 6 e IOs aleatórios de blocos pequenos (como o que seu trabalho em grade parece estar fazendo) pode ser uma receita para um desempenho de IO totalmente horrível.

Você pode usar strace no Linux para obter o sistema real chama seu trabalho (s) fazer. Procure chamadas como lseek , write , read e pwrite e pread . Isso lhe dirá o padrão real de IO que seu trabalho faz.

Depois de obter seu padrão IO, você pode testar e comparar o desempenho real do armazenamento nesse padrão com uma ferramenta que quase duplica esse padrão. Você provavelmente precisará de uma ferramenta que escreva ou leia para / de locais aleatórios. Novamente, assumindo o Linux, você pode começar com fio . Você provavelmente precisará usar as opções aleatórias de leitura / gravação.