O que realmente significa iodepth in fio tests? É a profundidade da fila?

Question

Eu entendo a profundidade da fila, que é o número de solicitações de E / S pendentes que o controlador de armazenamento pode manipular ( link ) ou seja, essa é a limitação em um controlador de armazenamento que manipula as solicitações de E / S e envia os comandos para o disco (r / w) e ele (não estritamente?) descarta as solicitações se houver são mais do que ele pode manipular (que será reenviada pelos clientes presumivelmente).

E o motivo de ter altas solicitações de I / O pode ser várias conexões de cliente solicitando I / O ou vários processos, mesmo de um único host solicitando I / O (o que eu acho, mas parece que o SO usa fusões de agendador de E / S as solicitações de E / S - que são originadas do buffer ao fazer a sincronização periódica ou sob demanda e enviam apenas um número fixo de solicitações outstading, para que não sobrecarreguem os dispositivos de armazenamento?)

Agora, chegando à definição de iodepth in fio man page:

Number of I/O units to keep in flight against the file. Note that increasing iodepth beyond 1 will not affect synchronous ioengines (except for small degrees when verify_async is in use).

Isso se alinha com meu entendimento da profundidade da fila. Se o IO for síncrono (bloqueio de IO), podemos ter apenas uma fila.

Even async engines may impose OS restrictions causing the desired depth not to be achieved. This may happen on Linux when using libaio and not setting 'direct=1', since buffered I/O is not async on that OS.

Confuso com toda essa declaração.

Keep an eye on the I/O depth distribution in the fio output to verify that the achieved depth is as expected. Default: 1.

Eu executei vários testes para cada iodepth e tipo de dispositivo, com 22 tarefas paralelas, pois a contagem de CPU é 24 e com rwtype: leitura seqüencial e gravação sequencial. Iodepths são 1,16,256,1024,32768 (eu sei 32 ou 64 deve ser o limite máximo, eu justed queria tentar de qualquer maneira).

E os resultados são quase iguais para todas as profundidades e para todos os discos (RAID 6 SSD, NVME e NFS): exceto para leitura sequencial em disco NVME com 32768 de profundidade.

IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=99.9%
submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%

Para NVME com 32768 profundidade,

complete  : 0=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=100.0%

Eu usei o libaio engine in fio (porque não tenho certeza qual mecanismo de E / S preciso dar para o teste de E / S assíncrona e libaio aparentemente o caminho certo. Essa é uma pergunta completamente diferente)

Então, o que está acontecendo? Por que Enviar e Completa mostra 1-4 (com exceção de uma execução de NVME onde é > 64)

[global]
lockfile=none
kb_base=1024
fallocate=posix
blocksize=64k
openfiles=100
ioengine=libaio
buffered=1
invalidate=1
loops=5
randrepeat=1
size=512M
numjobs=22

[sr-iodepth-1]
description="Sequential Write,Parallel jobs-22,IO depth-1,libaio"
readwrite=write
size=5G
iodepth=1

[sr-iodepth-16]
description="Sequential Write,Parallel jobs-22,IO depth-16,libaio"
readwrite=write
size=5G
iodepth=16

[sr-iodepth-256]
description="Sequential Write,Parallel jobs-22,IO depth-256,libaio"
readwrite=write
size=5G
iodepth=256

[sr-iodepth-1024]
description="Sequential Write,Parallel jobs-22,IO depth-1024,libaio"
readwrite=write
size=5G
iodepth=1024

[sr-iodepth-32768]
description="Sequential Write,Parallel jobs-22,IO depth-32768,libaio"
readwrite=write
size=5G
iodepth=32768


[sw-iodepth-1]
description="Sequential Read,Parallel jobs-22,IO depth-1,libaio"
readwrite=read
size=512M
iodepth=1

[sw-iodepth-16]
description="Sequential Read,Parallel jobs-22,IO depth-16,libaio"
readwrite=read
size=512M
iodepth=16

[sw-iodepth-256]
description="Sequential Read,Parallel jobs-22,IO depth-256,libaio"
readwrite=read
size=512M
iodepth=256

[sw-iodepth-1024]
description="Sequential Read,Parallel jobs-22,IO depth-1024,libaio"
readwrite=read
size=512M
iodepth=1024

[sw-iodepth-32768]
description="Sequential Read,Parallel jobs-22,IO depth-32768,libaio"
readwrite=read
size=512M
iodepth=32768

    

Answer 1

(Por favor, não faça várias perguntas em um post - isso torna a resposta realmente difícil ...)

queue depth which is the number of outstanding I/O requests [...] which handles the I/O requests and sends the commands to disk (r/w) and it (not strictly?) drops the requests

Solicitações excessivas geralmente não são descartadas - não há nenhum lugar para enfileirá-las no dispositivo para que outra coisa (por exemplo, o sistema operacional) precise mantê-las e enviá-las quando houver espaço disponível. Eles não estão perdidos, eles simplesmente não são aceitos.

And the reason for having high outstading [sic] I/O requests

Existem muitos motivos diferentes - você listou um deles. Por exemplo, o dispositivo pode ser lento (pense em um cartão SD antigo) e não é capaz de acompanhar até mesmo um "cliente".

only a fixed number of outstading [sic] requests, so that it won't overload the storage devices?)

Esse é o objetivo, mas não há nada dizendo que o dispositivo será capaz de acompanhar (e às vezes existem razões / configurações em que a fusão não acontece).

Even async engines may impose OS restrictions causing the desired depth not to be achieved. This may happen on Linux when using libaio and not setting 'direct=1', since buffered I/O is not async on that OS.

     

Confuso com toda essa declaração.

Uma peculiaridade do Linux é que não O_DIRECT I / O (o padrão) passa pelo cache de buffer (isso é chamado de E / S armazenada em buffer). Por causa disso, mesmo que você pense que enviou de forma assíncrona (usando o Linux AIO), na verdade você acabará tendo um comportamento síncrono. Consulte o link para obter uma explicação com palavras diferentes.

Why is Submit and complete shows 1-4

Sua configuração tem isto:

buffered=1

Você não deu atenção ao aviso sobre o qual estava se perguntando antes! buffered=1 é o mesmo que dizer direct=0 . Mesmo se você tivesse direct=1 , por padrão fio envia I / Os um por vez, então se o seu dispositivo é tão rápido que tenha completado o I / O antes que o próximo seja enfileirado, você pode não ver uma profundidade maior do que um. Se você deseja forçar / garantir o envio em lote, consulte as iodepth_batch_* options mencionado no fio HOWTO / manual .

OK retornando às perguntas no título:

What does iodepth in fio tests really mean?

É a quantidade máxima de E / S pendente que fio tentará e enfileirará internamente (mas observe que fio talvez nunca consiga alcançá-la pelas razões dadas acima e abaixo) .

Is it [iodepth] the queue depth?

Talvez, e além disso, também dependa do que você entende por "profundidade da fila". Se você quer dizer que o avgqu-sz informado por uma ferramenta como o iostat do Linux, então o iodepth pode ser semelhante ou totalmente diferente dependendo de coisas como o ioengine sendo usado, as opções sendo usadas com que o mecanismo de E / S, o tipo e o estilo da E / S sendo enviada, as camadas pelas quais ele deve percorrer até atingir o nível que está sendo relatado etc.

Acho que você fez variações sobre essas perguntas em alguns lugares diferentes - por exemplo, a lista de discussão de linhas tem uma resposta para algumas das opções acima - e esse email menciona que você também postou em link . Você pode querer tomar cuidado, porque você está potencialmente fazendo com que as pessoas respondam a perguntas que já foram respondidas em outro lugar e você não as está conectando, o que torna difícil descobrir as respostas duplicadas ...

    

Answer 2

De link

submit and complete represent the number of submitted IOs at a time by fio and the number completed at a time. In the case of the thrashing test used to generate this output, the iodepth is at the default value of 1, so 100% of IOs were submitted 1 at a time placing the results in the 1-4 bucket. Basically these only matter if iodepth is greater than 1.

Isso significa que a primeira linha mostra qual foi o número de IOs pendentes que você teve a qualquer momento e que está alinhado com o seu iodepth definido.

A linha de submissão mostra quantas IOs foram submetidas a cada vez que houve uma submissão e que essencialmente mostra que IOs foram submetidas a 4 de cada vez e a linha completa mostra que 4 IOs retornaram em cada ciclo de pollings, assim também submetido 4 IOs em troca.

Em geral, a profundidade io e a profundidade da fila são as mesmas. Eles são o número de IOs que um dispositivo / controlador pode ter pendente por vez, os outros IOs estarão pendentes em uma fila no nível do SO / aplicativo.

Você usa uma profundidade de fila baixa para obter latências mais baixas e uma profundidade de fila mais alta para obter melhor taxa de transferência. O dispositivo usa a profundidade da fila para paralelismo interno (SSDs) e / ou para reordenar e mesclar IOs relacionados (HDDs e SSDs).