Como posso avaliar os sistemas de arquivos do Linux em uma SAN?

Question

Gostaria de fazer uma referência dos nossos sistemas de arquivos, armazenados na SAN.

Mas a SAN é apoiada por muito cache (apenas 10 a 20%) é usado, então, se eu fizer algum teste, o resultado não será realista.

O que devo fazer para corrigir os resultados?

Alguma recomendação para programas? Bonnie ++, IOZone ou ...?

    

Answer 1

Sendo um fã do iozone, eu tenho usado ele para benchmarking em sistemas Linux e Windows por anos. Sean tem o ponto chave, teste com um conjunto de dados que não conserte em RAM + Cache. IOZone torna isso muito fácil.

iozone -s 64G -r 16k

Teste com um conjunto de dados 64G e tamanhos de leitura de 16K. Você pode especificar -r várias vezes para fornecer um intervalo de tamanhos de operação de E / S. Você pode até especificar testes individuais:

iozone -s 32G -s 64G -r 8k -r 16k -r 32k -r 64k -i 1 -i 2

-i 1 é necessário, já que isso cria o conjunto de dados, mas -i 2 diz para ele também executar os testes de leitura aleatória e de gravação aleatória. Existem alguns outros testes que podem ser executados. Um teste interessante é o teste de "leitura de passada", que pula um número de fatias entre as leituras; configurar corretamente isso pode testar os limites de leitura antecipada, bem como alinhamentos de faixas RAID.

Ele também pode usar o IO direto como parte dos testes, se isso for importante para você. Alguns DBMSs usam o DirectIO, que ignora o sistema de cache do Linux:

iozone -s 8G -r 1k -I

Até tem um modo que testa vários arquivos simultaneamente. Isso é útil para casos de teste em que alguns arquivos podem caber no cache, mas não em todos.

iozone -t 32 -s 2G -r 8k -r 16k

Isto diz para usar 32 threads, cada um com seu próprio arquivo de 2GB, e testar vários tamanhos de registro.

Uma coisa que eu vi algumas vezes é quando eu testo um tamanho de registro do mesmo tamanho que a largura da minha faixa de RAID. Frequentemente, isso será um acesso mais lento do que os tamanhos de registro em ambos os lados. Isso é um sinal de uma partição desalinhada.

    

Answer 2

Quando o benchmarking é típico tentar "apagar o cache" usando um conjunto de dados com pelo menos o dobro do tamanho da RAM + cache. Isso pode ajudar a obter números de desempenho mais piores, mas realmente ajuda você com números realistas.

Infelizmente, para obter informações realistas sobre o desempenho, você realmente não tem muita opção a não ser criar algo que simule seu caso de uso específico com seu conjunto de dados específico. Idealmente, você também gostaria de envelhecer o sistema de arquivos antes de executar esse benchmark, carregando-o com dados que simulam o uso normal ao longo do tempo. Um novo sistema de arquivos "mkfs" ed pode responder de maneira bem diferente de um que tenha vários outros dados e tenha arquivos criados e deletados em diretórios.

Em outras palavras, se esse sistema for um servidor da web, carregue suas páginas, dados e aplicativos e obtenha um conjunto razoavelmente representativo de URLs para executar o cerco ou ab. Se for um servidor de banco de dados, carregue um banco de dados de produção e execute suas consultas típicas, etc ...

Na minha experiência, essa é realmente a única maneira de obter números realistas sobre o desempenho.

No entanto, quanto a uma comparação rápida, mas não muito realista, ferramentas como o bonnie ++ podem fornecer bons números. Eu normalmente tenho problemas com o Bonnie ++, o que me dá bons números para a seção de E / S aleatória, porque ela tende a ser executada com um conjunto de dados muito pequeno, então preste atenção nas opções para controlar isso.