O que exatamente é o iodepth in fio? [fechadas]

Question

O iodepth de fio e a profundidade de armazenamento da fila são os mesmos? Então, como é possível controlar a profundidade da fila com um parâmetro iodepth do comando fio? Será que isso vai criar empregos paralelos, mas, novamente, há uma opção para executar trabalhos em paralelo também (isso não será trivial ou conflitante?)

Eu estou lutando para entender como a control está controlando suas cargas de trabalho (especialmente sobre este iodepth). Alguém pode explicar o parâmetro iodepth em detalhes.

UPDATE # 1

Minha pergunta também foi perguntada no fórum do Flexible I / O Tester . Esta é a resposta que recebi lá.

Hi,

On 28 July 2018 at 14:26, Jeevan Patnaik wrote: Hi,

Is Iodepth of fio and queue depth of storage both same? Then, how is it possible to control queue depth with an iodepth parameter from fio

     

fio iodepth e a profundidade I / O seu sistema operacional consegue enviar I / O até   armazenamento estão ligados, mas certamente não tem que ser o mesmo e   o relacionamento é altamente dependente do seu funcionamento   sistema / armazenamento / fio ioengine utilizado / fio parâmetros. Basicamente, submete   I / O um caminho particular para o seu sistema operacional. Dependendo de como você   enviar o seu I / O para o seu sistema operacional, ele pode optar por enviá-lo   mais abaixo de uma maneira mais ótima / diferente (por exemplo, por lotes   solicitações em conjunto, interrompendo solicitações que são muito grandes em pequenos   peças, atrasando I / O etc). Além disso, e como indicado no HOWTO , o iodepth afeta apenas os ioengines assíncronos (e observe aquele texto   inclui avisos sobre a necessidade de usar o direct = 1 no Linux).

     

command? Will that be creating parallel jobs, but then again there is an option to run jobs in parallel also (will that not be a trivial or conflicting?)

     

Vou dar um breve resumo, mas note que não estou tentando cobrir   caching / readahead / plugging / block camadas de dispositivos (por exemplo, RAID / LVM) etc:

     

Um mecanismo de E / S de fio síncrono envia uma única E / S para o SO, aguarda   ser "reconhecido" como tendo sido recebido e, em seguida, envia outra   I / O etc.

     

Se um motor de fio I / O é capaz de enviar I / O para o sistema operacional em um verdadeiro   forma assíncrona (ver link acima), em seguida, a chave é que ele não faz   tem que esperar que a E / S seja "confirmada" antes de enviar   novo I / O. Se o iodepth for apenas 1, ele terá que se comportar de uma maneira   semelhante a um mecanismo de E / S síncrona. No entanto, digamos que um emprego   especifica um iodepth de 32. Nesse caso, até 32 E / Ss a serem   pendente antes do fio escolherá esperar antes de enviar mais   E / S (apenas quais são as marcas d'água e quanto é enviado de cada vez   é controlado pelas opções iodepth_batch_ *. Isso pode ser mais   eficiente e alcançar maiores taxas de transferência, mas muitas vezes vem com um custo   de maior latência.

     O

fio não criará trabalhos paralelos fio apenas por causa do iODepth MAS   usar trabalhos paralelos é outra maneira de aumentar a quantidade de   E / S simultâneas sendo enviadas a qualquer momento (usando diferentes   threads / processos) e usando ambos no mesmo dispositivo   tandem (por isso, se você tiver dois trabalhos de fio enviando E / S assíncronas em um   iodepth de 16 cada seu sistema operacional pode estar realmente recebendo 32 I / Os em   qualquer momento). Pode haver motivos para combinar os dois (por exemplo, você   tem vários dispositivos e eles são tão rápidos que uma CPU não consegue acompanhar   mesmo ao enviar E / S de forma assíncrona).

     

I am struggling to understand how fio is controlling it's workloads (especially about this iodepth). Can someone please explain the iodepth parameter in detail.

     

Eu observarei que você também fez essa pergunta no stackexchange   ( O que exatamente é o iodepth in fio? ). Você pode querer linkar para    link de lá para ajudar   outros que podem ter uma pergunta semelhante ...

    

Answer 1

will that not be a trivial?

Suponha IO direto, conforme necessário para o iodepth = funcionar.

Um trabalho seqüencial com iodepth = 2 enviará duas solicitações IO sequenciais de cada vez.

Um trabalho seqüencial com numjobs = 2 terá dois threads, cada um enviando IO sequencial.

Estes são diferentes padrões de IO. Este último irá gerar 2x a largura de banda através do barramento de E / S, mesmo se o E / S físico for reduzido para 1x devido a caches de dispositivos. (Eu suspeito que os dois trabalhos tenderiam a permanecer em sincronia devido aos caches do dispositivo, a menos que você tenha usado vários arquivos e um file_service_type= aleatório). Se os IOs forem gravações síncronas (sync = true), o IO físico não será reduzido, a menos que o dispositivo esteja fazendo uma otimização incomum (talvez um controlador SSD de desduplicação).

    

Answer 2

Para os documentos do kernel do Linux :

.. option:: iodepth=int

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 :option:verify_async is in use). 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 :option:direct\=1, since buffered I/O is not async on that OS. Keep an eye on the I/O depth distribution in the fio output to verify that the achieved depth is as expected. Default: 1.

Este tutorial intitulado: Saída do Fio explicada tinha este exemplo:

Fio has an iodepth setting that controls how many IOs it issues to the OS at any given time. This is entirely application-side, meaning it is not the same thing as the device's IO queue. In this case, iodepth was set to 1 so the IO depth was always 1 100% of the time.

    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.0%, 32=0.0%, 64=0.0%, >=64=0.0%

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.