IOMeter - Com quais valores devo testar?

Question

De certa forma, acho que isso é uma questão de string, no entanto, mesmo que haja uma resposta "isso serve para a maioria das situações", não tenho idéia do que é, então ...

Eu tenho uma SAN em avaliação, um HP P4000. Eu gostaria de usar o IOMeter para fazer um benchmarking para ver do que ele é capaz.

No entanto, não tenho ideia de qual combinação de tamanho de bloco, divisão de leitura / gravação e divisão aleatória / sequencial é aplicável a diferentes usos.

Por exemplo, como você simularia alguma atividade do Exchange, alguma atividade de SQL, alguma atividade geral da VM e assim por diante.

Eu sei como adicionar trabalhadores e configurá-los com configurações diferentes, mas quais configurações devo usar?

Obrigado.

    

Answer 1

A atividade Exchange e SQL tende para o final de escala IO / Ops mais frequente e menor. O Exchange tem algumas explosões de E / S maiores à medida que os anexos são gravados / extraídos. Intervalos de backup e consultas de longa duração também podem funcionar bem, e provavelmente são suas instâncias de E / S de pico. O Defrag do Exchange Online é o nosso pico de IO para o Exchange, e o backup de SQL é o nosso pico de I / O para o nosso servidor SQL.

O Desfragmentação do Exchange Online envolve muitas operações de E / S, mas não muito throughput, por isso o tamanho médio de transferência é pequeno, 512b pequeno e muitos deles. Relação de leitura / gravação varia tremendamente, mas para um banco de dados do Exchange bem conservado deve ser principalmente leituras. Isso será significativamente aleatório, mas com acesso sequencial suficiente para mantê-lo interessante (não, eu não tenho proporções exatas).

Os Backups SQL envolvem uma variedade de tamanhos, mas ao contrário da taxa de transferência online, a taxa de transferência também é alta. Planeje uma mistura de tamanhos de transferência de 512b a 4kb. As taxas de leitura / gravação dependem de onde os dados estão terminando! As gravações podem ter uma velocidade muito alta, mas (dependendo do script de backup) quase inteiramente sequenciais. As leituras serão 100% aleatórias.

A atividade geral da VM depende do que está nas VMs. Se você tiver o Exchange ou SQL lá, monitore para isso. Se, em geral, você quer dizer "serviço geral de arquivos", como compartilhamento da Web ou do CIFS, isso depende do que eles estão fazendo; Os engenheiros de CAD têm padrões de acesso muito diferentes de um escritório cheio de funcionários do Departamento de Compras. Não há padrão genérico de E / S para 'atividade geral da VM'. Você tem que planejar o que você realmente tem na VM.

    

Answer 2

Análise de desempenho do sistema de armazenamento com Iometer: link

    

Answer 3

De uma perspectiva do SQL Server

Em uma caixa do SQL Server, você preferencialmente testaria os discos com os seguintes parâmetros, dependendo de onde você armazenaria os arquivos MDF, NDF, LDF e TEMPDB:

Todos os discos (MDF, NDF, LDF, TEMPDB)

• Tamanho do pedido de transferência de 8 KiB
• 80% de taxa de leitura
• 95% de leituras aleatórias
• Tempo de aceleração 10 (para contornar o cache de armazenamento)
• Tamanho máximo do disco (4'000'000 setores = 2 GiB)

Discos gravados em série (LDF, TEMPDB)

• Tamanho do pedido de transferência de 8 KiB
• 20% de taxa de leitura (os logs e o TEMPDB exigem muita gravação)
• 0% de leituras aleatórias
• Tempo de aceleração 10 (para contornar o cache de armazenamento)
• Tamanho máximo do disco (4'000'000 setores = 2 GiB)

Disco de leitura serial (MDF, NDF)

64 KiB de leitura de extensão

• Tamanho da solicitação de transferência de 64 KiB
• Relação de leitura de 80% (os arquivos MDF e LDF são mais lidos a partir de)
• 0% de leituras aleatórias
• Tempo de aceleração 10 (para contornar o cache de armazenamento)
• Tamanho máximo do disco (4'000'000 setores = 2 GiB)

Leitura de 128 KiB

• Tamanho da solicitação de transferência de 128 KiB
• Relação de leitura de 80% (os arquivos MDF e LDF são mais lidos a partir de)
• 0% de leituras aleatórias
• Tempo de aceleração 10 (para contornar o cache de armazenamento)
• Tamanho máximo do disco (4'000'000 setores = 2 GiB)

256 KiB de leitura antecipada

• Tamanho da solicitação de transferência de 256 KiB
• Relação de leitura de 80% (os arquivos MDF e LDF são mais lidos a partir de)
• 0% de leituras aleatórias
• Tempo de aceleração 10 (para contornar o cache de armazenamento)
• Tamanho máximo do disco (4'000'000 setores = 2 GiB)

512 KiB de leitura antecipada

• Tamanho da solicitação de transferência de 512 KiB
• Relação de leitura de 80% (os arquivos MDF e LDF são mais lidos a partir de)
• 0% de leituras aleatórias
• Tempo de aceleração 10 (para contornar o cache de armazenamento)
• Tamanho máximo do disco (4'000'000 setores = 2 GiB)

1024 KiB de leitura antecipada (Enterprise Edition)

• Tamanho da solicitação de transferência de 1024 KiB
• Relação de leitura de 80% (os arquivos MDF e LDF são mais lidos a partir de)
• 0% de leituras aleatórias
• Tempo de aceleração 10 (para contornar o cache de armazenamento)
• Tamanho máximo do disco (4'000'000 setores = 2 GiB)

Você pode variar a porcentagem de leituras aleatórias para ver se seus resultados variam, mas descobri que os valores acima são um ótimo ponto de partida.

Artigo sobre práticas recomendadas do SQL Server (MSDN)

Test a combination of I/O sizes for read/write and sequential/random. For SQL-focused deployments, be sure to include I/O sizes of 8 KB, 64 KB, 128 KB, 256 KB & 1024 for sequential I/O. (Read-ahead can be up to 1024 KB when running SQL Server Enterprise Edition). For random I/O it is generally safe to focus only on 8-KB I/O.

Solução de problemas de E / S de disco lento no SQL Server (Blogs MSDN)

If you suspect you are experiencing poor disk performance you can use internal DMVs combined with a Performance Monitor collection to get a good picture of the health of the disk I/O subsystem and any latency SQL Server is experiencing from its poor performance.

Melhor desempenho do SQL Server (Monitor de Desempenho) Práticas (Brent Ozar)

In the Performance object dropdown, choose Physical Disk, and choose the “% Disk Time” counter. Notice that again on the right side window, we get multiple instances; this time, we get one per physical disk. In performance terms, physical disk means one disk shown in Computer Management’s Disk Management tool. One physical disk may have multiple partitions, each with its own drive letter, but for performance tuning, we want to know how hard that one physical disk is working.

This one “physical disk” may have a bunch of actual physical drives, like in RAID systems. However, Windows isn’t quite smart enough to know exactly how many drives are in the RAID array, so the term “physical disk” is a little misleading here.

Como examinar as latências do subsistema IO de dentro do SQL Server (SQLSkills)

Most SQL Server’s today are I/O bound – that’s a generally agreed-on statement by DBAs and consultants in the field. This means that the major factor in server performance is its ability to perform I/O operations quickly. If the I/O subsystem cannot keep up with the demand being placed on it, then the SQL Server workload will suffer performance problems.

Now, saying that, one trap that many people fall into is equating increased I/O subsystem latencies with poor I/O subsystem performance. This is often not the case at all. It’s usually the case that the I/O subsystem performs fine when the designed-for I/O workload is happening, but becomes the performance bottleneck when the I/O workload increases past the I/O subsystem design point. The I/O workload increase is what’s causing the problem, not the I/O subsystem – if you design an I/O subsystem to support 1000 IOPS (I/O operations per second – and making sure you’re using the right I/O size and the workload characteristics make sense to be defined in terms of the number of random IOPS) and SQL Server is trying to push 2000 IOPS, performance is going to suffer.