4.8. Opções utilizadas para testar o desempenho do VDO com fio

--size

A quantidade de dados que fio envia para o alvo por trabalho.

Veja também a opção --numjobs.

100 GiB

--bs

O tamanho do bloco de cada pedido de leitura e escrita produzido por fio.

A Red Hat recomenda um tamanho de bloco de 4 KiB para corresponder a 4 KiB padrão da VDO.

4k

--numjobs

O número de empregos que o site fio cria para o benchmark.

Cada trabalho envia a quantidade de dados especificada pela opção --size. O primeiro trabalho envia os dados para o dispositivo no offset especificado pela opção --offset. Os trabalhos subseqüentes sobrescrevem a mesma região do disco, a menos que você forneça a opção --offset_increment, que compensa cada trabalho de onde o trabalho anterior começou por esse valor.

Para atingir o desempenho máximo em discos flash (SSD), a Red Hat recomenda pelo menos dois trabalhos. Um trabalho é normalmente suficiente para saturar a produção do disco rotativo (HDD).

1 para HDD, 2 para SSD

--thread

Encarrega o site fio de executar os trabalhos em linhas em vez de garfos, o que poderia proporcionar melhor desempenho limitando a mudança de contexto.

none

--ioengine

O motor de E/S que fio utiliza para o benchmark.

O teste da Red Hat usa o motor assíncrono sem tampão chamado libaio para testar cargas de trabalho onde um ou mais processos estão fazendo solicitações simultâneas aleatórias. O motor libaio permite que um único tópico faça várias solicitações assíncronas antes de recuperar quaisquer dados. Isto limita o número de comutadores de contexto que um mecanismo síncrono exigiria se ele fornecesse as solicitações por muitos threads.

libaio

--direct

A opção permite que os pedidos apresentados ao dispositivo contornem o cache de páginas do kernel.

Você deve usar o motor libaio com a opção --direct. Caso contrário, o kernel usa a API de sincronização para todas as solicitações de E/S.

1 (libaio)

--iodepth

O número de buffers de E/S em vôo a qualquer momento.

Um valor alto normalmente aumenta o desempenho, particularmente para leituras ou escritas aleatórias. Valores altos garantem que o controlador tenha sempre pedidos de lote. Entretanto, a definição do valor muito alto, (normalmente maior que 1K, pode causar latência indesejável.

A Red Hat recomenda um valor entre 128 e 512. O valor final é um trade-off e depende de como sua aplicação tolera a latência.

128 no mínimo

--iodepth_batch_submit

O número de pedidos de E/S a serem criados quando o pool de tampão de profundidade de E/S começa a esvaziar.

Esta opção limita a troca de tarefas das operações de E/S para a criação de buffer durante o teste.

16

--iodepth_batch_complete

O número de operações de E/S a serem concluídas antes da apresentação de um lote.

Esta opção limita a troca de tarefas das operações de E/S para a criação de buffer durante o teste.

16

--gtod_reduce

Desativa as chamadas de tempo do dia para calcular a latência.

Este ajuste reduz a produção se ativado. Habilite a opção a menos que você necessite de medição de latência.

1