Fio é a abreviação de Flexible IO, um gerador de carga de trabalho IO versátil. Em 2005, Jens Axboe, o backbone por trás e autor da pilha IO no kernel do Linux, estava cansado de escrever constantemente programas de teste únicos para fazer benchmark ou verificar alterações no subsistema Linux IO. Por isso, a fio nasceu para facilitar muito o trabalho. Era flexível o suficiente para permitir configurações de carga de trabalho detalhadas e continha os relatórios necessários para dar sentido aos dados na conclusão. Jens continuou trabalhando em fio quando ingressou na Oracle e, posteriormente, na Fusion-io.
Fio é a abreviação de Flexible IO, um gerador de carga de trabalho IO versátil. Em 2005, Jens Axboe, o backbone por trás e autor da pilha IO no kernel do Linux, estava cansado de escrever constantemente programas de teste únicos para fazer benchmark ou verificar alterações no subsistema Linux IO. Por isso, a fio nasceu para facilitar muito o trabalho. Era flexível o suficiente para permitir configurações de carga de trabalho detalhadas e continha os relatórios necessários para dar sentido aos dados na conclusão. Jens continuou trabalhando em fio quando ingressou na Oracle e, posteriormente, na Fusion-io. Hoje, a comunidade de usuários do fio é ativa e engajada no desenvolvimento e, conseqüentemente, desenvolve continuamente o fio e implementa novos recursos. Mais de 100 pessoas contribuíram para o fio, e muitas o fizeram várias vezes. Graças a esse compromisso, uma nova versão do fio é lançada aproximadamente a cada 4-6 semanas, e o fio é amplamente usado como referência padrão do setor, ferramenta de teste de estresse e para fins de verificação de IO.
Conjunto de recursos principais e capacidades
Os dois recursos principais em um bom benchmark são poder executar a carga de trabalho desejada e obter as unidades de saída desejadas. Ser flexível foi (e continua sendo) o foco principal da fio. Ele oferece suporte a opções de carga de trabalho não encontradas em outros benchmarks, juntamente com estatísticas de E/S rigorosamente detalhadas. Qualquer tipo de mistura de IO aleatória e sequencial, ou mistura de leitura/gravação, é fácil de definir. O design interno do fio também é flexível. A definição de uma carga de trabalho é completamente separada do mecanismo IO (um termo que fio usa para significar como IO é entregue ao kernel). Por exemplo, se você deseja executar uma carga de trabalho com assíncrono nativo no Linux e comparar a mesma carga de trabalho no Windows, basta alterar a linha do mecanismo de E/S único para a versão nativa no Windows. Ou, se você quiser estatísticas de percentil de latência mais detalhadas na parte final da distribuição, isso também é fácil. Basta especificar os percentis exatos nos quais você está interessado e o fio rastreará isso para você.
Embora inicialmente desenvolvido no Linux, as áreas em fio que não estão vinculadas a recursos específicos do sistema operacional funcionam em qualquer plataforma, do Windows ao HP-UX e ao Android. Também existem mecanismos IO nativos no Linux, Windows, Solaris etc. Esse é um recurso importante para ambientes mistos nos quais você deseja executar (o mais próximo possível) cargas de trabalho idênticas em diferentes ambientes operacionais. Além disso, embora o fio normalmente seja executado diretamente na máquina de destino, ele também oferece suporte a conexões de rede. Você pode executar um back-end de servidor na(s) máquina(s) de destino e executar o front-end de coleta de dados em uma máquina cliente. Isso facilita o gerenciamento, especialmente se o fio for usado com frequência em várias máquinas.
Fio é predominantemente um aplicativo CLI baseado em texto, embora exista suporte inicial para um frontend GUI baseado em gtk de plataforma cruzada (gfio). No momento desta publicação, o gfio está incluído na versão mais recente do fio, v2.1, e deve ser razoavelmente estável. Ele é capaz de servir como um front-end de GUI para qualquer carga de trabalho suportada pelo cliente CLI. Ele também fornece suporte básico para opções de trabalho de edição de GUI e cargas de trabalho, embora o suporte completo ainda esteja em desenvolvimento, pois o gfio é um trabalho em andamento.
Fio também suporta três tipos diferentes de formatos de saída. A saída “clássica” é o padrão que despeja estatísticas de carga de trabalho no final da carga de trabalho. Também há suporte para um formato CSV, embora isso esteja diminuindo lentamente em favor de um formato de saída baseado em JSON. O último é muito mais flexível e tem a vantagem de ser simples de analisar para pessoas e computadores.
A Fio está avançando rapidamente graças à sinergia de sua vibrante comunidade de usuários e desenvolvedores. É mais fácil de executar do que projetos concorrentes, flexível o suficiente para realizar as tarefas dos usuários e tem uma sobrecarga baixa o suficiente para conduzir qualquer tipo de sistema de armazenamento em velocidade total. Junte isso com suas opções e relatórios mais ricos do que qualquer outra coisa por aí, e o fio é uma ferramenta excelente.
Por que a StorageReview.com usa FIO
Como começamos a aumentar a quantidade e a profundidade de nossas análises de armazenamento corporativo, precisávamos de uma ferramenta de benchmarking melhor para medir com precisão o desempenho de diferentes produtos de armazenamento em vários sistemas operacionais. O software gerador de carga de trabalho tradicional, como Iometer ou Vdbench, oferece compatibilidade limitada com seu sistema operacional não nativo ou teve dificuldade em dimensionar cargas para dispositivos de armazenamento de alto desempenho, como aceleradores de aplicativos PCIe ou armazenamento em rede de alto desempenho. Desde o início de nossa implementação do FIO, ele resolveu muitos desses problemas e deu um passo além ao oferecer suporte a scripts para longos períodos de teste. Essa funcionalidade geral o torna nosso benchmark sintético de escolha para todas as análises corporativas.
Para nossas análises, usamos o FIO para medir o desempenho de um dispositivo de armazenamento em um determinado período de tempo. Para a maioria dos produtos, isso inclui 6 horas de pré-condicionamento antes de entrarmos em nossos testes principais. Para dispositivos de armazenamento PCIe maiores que podem não entrar em estado estacionário por muitas horas em teste, pré-condicionamos o dobro do tempo em 12 horas antes do início de nossos testes principais. Nosso processo de referência de armazenamento corporativo sintético começa com uma análise do desempenho da unidade durante uma fase de pré-condicionamento completa. Cada um dos produtos comparáveis é primeiro apagado com segurança usando as ferramentas do fornecedor e, em seguida, pré-condicionado em estado estacionário com a mesma carga de trabalho com a qual o dispositivo será testado sob uma carga pesada de 16 threads com uma fila pendente de 16 por thread. Completando o processo, testamos em intervalos definidos em vários perfis de profundidade de encadeamento/fila para mostrar o desempenho sob uso leve e pesado.
Testes de pré-condicionamento e estado estacionário primário:
- Rendimento (Agregado de IOPS de Leitura+Gravação)
- Latência média (latência de leitura+gravação calculada em conjunto)
- Latência máxima (latência máxima de leitura ou gravação)
- Desvio padrão de latência (desvio padrão de leitura + gravação calculado em conjunto)
Nossa Enterprise Synthetic Workload Analysis inclui diferentes perfis para refletir algumas tarefas do mundo real. Esses perfis foram desenvolvidos para facilitar a comparação com nossos benchmarks anteriores, bem como valores amplamente publicados, como velocidade máxima de leitura e gravação de 4k e 8k 70/30, que é comumente usado para hardware corporativo.
- 4k
- 100% de leitura ou 100% de gravação
- 100% 4K
- fio –filename=/dev/sdx –direct=1 –rw=randrw –refill_buffers –norandommap –randrepeat=0 –ioengine=libaio –bs=4k –rwmixread=100 –ioprofundidade=16 –numjobs=16 –runtime=60 –group_reporting –nome=4kteste
- 8k 70/30
- 70% de leitura, 30% de gravação
- 100% 8K
- fio –filename=/dev/sdx –direct=1 –rw=randrw –refill_buffers –norandommap –randrepeat=0 –ioengine=libaio –bs=8k –rwmixread=70 –iodepth=16 –numjobs=16 –runtime=60 –group_reporting –name=8k7030teste
Atualmente nós utilizamos FIO versão 2.0.7 (x64) no CentOS 6.3 para nossos testes de desempenho do Linux e FIO versão 2.0.12.2 (x64) no Windows Server 2008 R2 SP1 para nosso desempenho no Windows.
Plataformas de teste corporativo StorageReview
As soluções de armazenamento são testadas com o benchmark sintético FIO no Laboratório de teste StorageReview Enterprise utilizando servidores autônomos. Utilizamos o HP ProLiant DL380/DL360 Gen9 para mostrar desempenho realista, alterando apenas o adaptador de armazenamento ou interface de rede para conectar nosso DL380/DL360 a diferentes produtos de armazenamento. O DL380/DL360 provou oferecer grande compatibilidade com dispositivos de terceiros, tornando-o uma excelente plataforma para este ambiente de teste diversificado.
(Geração 1) Lenovo ThinkServer RD240
- 2 x Intel Xeon X5650 (2.66 GHz, 12 MB de cache)
- Chipset Intel 5500+ ICH10R
- Memória – 8GB (2 x 4GB) 1333Mhz DDR3 RDIMMs registrados
- Windows Server 2008 Standard Edition R2 SP1 64 bits e CentOS 6.2 64 bits
- HBA LSI 9211 SAS/SATA 6.0Gb/s
(Geração 2) Lenovo ThinkServer RD630
- 2 x Intel Xeon E5-2620 (2.0 GHz, 15 MB de cache, 6 núcleos)
- Chipset Intel C602
- Memória – 16GB (2 x 8GB) 1333Mhz DDR3 RDIMMs registrados
- Windows Server 2008 R2 SP1 de 64 bits, Windows Server 2012 Standard, CentOS 6.3 de 64 bits
- 100GB Micron RealSSD P400e SSD de inicialização
- LSI 9207-8i SAS/SATA 6.0Gb/s HBA (para benchmarking de SSDs ou HDDs)
(Geração 3) HP ProLiant DL380/DL360 Gen9
- CPUs duplas Intel E5-2667 v3 (3.2 GHz, 8 núcleos, 20 MB de cache)
- 256 GB de RAM (16 GB x 16 DDR4, 128 GB por CPU)
- Servidor Windows 2012 R2, CentOS 7.0
- SSD de inicialização de 400 GB – Windows
- HD de inicialização de 300 GB – Linux
- HBA LSI 9300-8e SAS/SATA 12.0 Gb/s (Para benchmarking de SSDs ou HDDs)
- Supermicro SuperChassis 846BE1C-R1K28B SAS3 JBOD (para anexar SSDs ou HDDs)