Throughput = BS * IOPS?

Question

Eu vi em muitos lugares que throughput = bs * iops deve ser verdade. Por exemplo, gravar em tamanho de bloco de 128k em um disco SAS que possa suportar 190 IOPS deve fornecer uma taxa de transferência de ~ 23 MBps - 23.75(MBs) = 128(BS)*190(SAS-15 IOPS)/1024 .

Agora, quando eu testei em uma VM com um arquivador NetApp monstruoso, obtive esses resultados:

# dd if=/dev/zero of=/tmp/dd.out bs=4k count=2097152
8589934592 bytes (8.6 GB) copied, 61.5996 seconds, 139 MB/s

Para ver a taxa de E / S da VM, usei o iostat e o esxtop, e os dois mostraram cerca de 250 IOPS.

Então, para mim, a taxa de transferência deveria ser de ~ 1000k: 1000(KBs) = 4(BS)*250(IOPS) .

dd de 8GB é o dobro do tamanho da RAM, é claro, então não há cache de página aqui.

O que estou perdendo?

Obrigado!

    

Answer 1

O que você está perdendo é o contexto. O IOPS é TOTALMENTE ALEATÓRIO. Uma cópia não é aleatória, mas sequencial. Os discos rígidos ficam lentos quando a cabeça é movida - as IOPS basicamente assumem, IO devidamente medido, que é distribuído aleatoriamente sobre o disco completo (ou pelo menos uma grande parte dele).

Sim, você é muito mais rápido ao copiar um disco. SADLY isso é totalmente irrelevante, a menos que seu uso normal seja apenas copiado por SOMENTE UM USUÁRIO AO MESMO TEMPO.

Isso é como medir a velocidade máxima de um carro de Fórmula 1 e depois assumir que esta é a velocidade média durante uma corrida ruim, as Fórmulas 1 têm curvas e os carros, em sua maioria, são bem mais lentos.

Então, se você não fizer padrões totalmente degenerados (no termo técnico), ou seja, só tiver uma operação de cópia de cada vez, então o IO será aleatório (especialmente máquinas virtuais - um pode ser sequencial, 20 atingindo o mesmo disco é aleatório) e a cabeça passa a maior parte do tempo em movimento, não fazendo operações de E / S.

dd of 8GB is twice the size of RAM

Ainda é patético, não é? Quão grande é o disco? (gb é apenas uma pequena parte, então a parte "aleatória" é muito poucos movimentos (medidos em comprimento) em comparação com o cenário do mundo real;) Na verdade, nenhum movimento aleatório quando você copia de uma fonte zero, soiit apenas escrevendo, nunca movendo a cabeça. BAD;)

NO alto:

against a monster NetApp filer

Alguma idéia de quanto esses grandes itens de SAN podem otimizar seu IO? Quanto cache tem? Um arquivador de "monstros" seria um dos principais modelos, que tem mais de 16 gigabytes de ememory para seu próprio uso de cache. Se for irreally um monstro, seu arquivo é patético - wikipedia lê a linha superior de 2010 (!) Com 192gb de memória;) nem sequer percebe quando buffer de 8GB. E a desduplicação (isso acontece em tempo real?) Pode eliminar praticamente todas as operações de gravação. Tem certeza de que você mediu mesmo a IOPS baseada em disco?

    

Answer 2

Existe um aplicativo chamado SQLIO, não se preocupe com o nome, ele não tem nada a ver com SQL, foi escrito pela equipe do SQL Server na Microsoft, que permite testar seu disco com E / S aleatório (ler ou escrever ) e veja quanto carga os discos podem suportar. Você pode baixá-lo do site da Microsoft.

    

Answer 3

Se você for usar throughput = block size * IOPS , terá que usar o tamanho de bloco das operações de E / S que está contando, não o tamanho do bloco do sistema de arquivos, não o tamanho do bloco do dispositivo de bloco. / p>

Os 139MB / s são provavelmente um pouco mais altos do que o que você realmente obteve porque a E / S provavelmente continuava quando a medição parou. O cache de blocos provavelmente ainda estava liberando. Portanto, parece que a explicação mais lógica é que o tamanho das operações de E / S subjacentes que você está contando é de 512 KB.

O tamanho do bloco das operações de E / S deve ser um múltiplo do tamanho do bloco do dispositivo de bloco. Eu acredito que você diz que é 128KB. Portanto, operações de 512 KB (4 blocos) são certamente possíveis.

512 * 250 = 128 MB / s