Eu tenho um servidor com um controlador LSI MegaRAID SAS 9260-4i, RAID-5 com discos de 3 x 2 TB. Fiz alguns testes de desempenho (com o iozone3) e os números mostram claramente que a política de cache de gravação afeta também o desempenho de leitura. Se eu definir a diretiva para WriteBack, recebo cerca de 2x o desempenho de leitura em comparação com WriteThrough. Como o cache de gravação pode afetar o desempenho de leitura?
Aqui estão os detalhes da configuração:
megacli -LDInfo -L0 -a0
Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name :
RAID Level : Primary-5, Secondary-0, RAID Level Qualifier-3
Size : 3.637 TB
Is VD emulated : Yes
Parity Size : 1.818 TB
State : Optimal
Strip Size : 512 KB
Number Of Drives : 3
Span Depth : 1
Default Cache Policy: WriteThrough, ReadAhead, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteThrough, ReadAhead, Direct, No Write Cache if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy : Disabled
Encryption Type : None
Bad Blocks Exist: No
Is VD Cached: No
Com o WriteBack ativado (todo o resto não é alterado):
Default Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBU
Current Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBU
Alguns números do iozone3:
WriteThrough:
random random
KB reclen write rewrite read reread read write
2033120 64 91963 38146 144980 139122 11795 21564
2033120 128 83039 90746 118660 118147 21193 33686
2033120 256 78933 40359 113611 114327 31493 51838
2033120 512 71133 39453 131113 143323 28712 60946
2033120 1024 91233 76601 141257 142820 35869 45331
2033120 2048 58507 48419 136078 135220 51200 54548
2033120 4096 98426 70490 119342 134319 80883 57843
2033120 8192 70302 63047 132495 144537 101882 57984
2033120 16384 79594 29208 148972 135650 124207 79281
WriteBack:
random random
KB reclen write rewrite read reread read write
2033120 64 347208 302472 331824 302075 12923 31795
2033120 128 354489 343420 292668 322294 24018 45813
2033120 256 379546 343659 320315 302126 37747 71769
2033120 512 381603 352871 280553 322664 33192 116522
2033120 1024 374790 349123 289219 290284 43154 232669
2033120 2048 364758 342957 297345 320794 73880 264555
2033120 4096 368939 339926 303161 324334 128764 281280
2033120 8192 374004 346851 303138 326100 186427 324315
2033120 16384 379416 340577 284131 289762 254757 356530
Alguns detalhes sobre o sistema:
Ao usar um cache de write-back, você está salvando o IOPS do disco. O controlador pode agrupar gravações menores em uma gravação grande.
Assim, há mais IOPS disponíveis para leituras.
Isso pressupõe que os testes são simultâneos. Se um determinado teste é apenas leituras ou apenas escreve isso não importa.
Em que sistema de arquivos este teste é executado?
O que vem à mente é um tempo. Se o seu sistema de arquivos estiver montado com a opção atime ou se não houver nenhuma opção de montagem / relatime, você receberá uma gravação para cada leitura.
(atime significa registrar o último horário de acesso dos arquivos)
Pode ser útil publicar a saída de
mount
e especifique em qual dispositivo você fez os testes.
Política de write-back do tem efeitos no desempenho do vermelho ao usar testes como o iozone, porque essas ferramentas de benchmark medem o desempenho de leitura lendo dados que eles escreveram anteriormente. portanto, quando o iozone inicia os testes de leitura, alguns dados ainda estão no cache, tornando a taxa de transferência de leitura muito mais alta. isso é independente do tamanho dos arquivos, pois o adaptador raid não tem conhecimento de arquivos ou mesmo de sistemas de arquivos. Tudo o que sabe são IOs e blocos. Lembre-se iozonr eu tinha uma ferramenta de benchmark fs e bandido totalmente abstraem hardware. talvez usando -J / -Y você poderia atenuar os efeitos da política de write back e ter uma idéia do seu desempenho de leitura ... ou usar uma verdadeira ferramenta de HDD (hdparm?)
A razão mais óbvia é que as leituras vêm do cache, e não do próprio disco. Lembre-se que com WriteBack, os dados gravados são mantidos no cache, até que o controlador RAID tenha uma chance / decida gravá-lo no disco. No entanto, faz sentido que, se os mesmos dados forem lidos (ou qualquer coisa que ainda contenha cache), ele usa o cache para recuperar os dados, em vez de entrar em leituras de disco relativamente caras.
É provável que, enquanto o arquivo está sendo gravado, ele também esteja sendo gravado como no bloco contínuo no disco.
Uma coisa que as soluções anteriores não levam em conta é a diferença entre como os comandos write-back e write-through são manipulados no controlador.
Write-Back significa que quando o controlador recebe um comando, ele imediatamente informa ao manipulador do sistema operacional que ele está "ok" e fornece o próximo. Write-While espera que cada comando individual relate um sucesso antes de processar a próxima consulta.
Como resultado, os comandos são enfileirados mais rapidamente. Em seguida, a configuração Read-Ahead da Matriz começará a preencher o cache com um fluxo contínuo de dados.
Você pode ver que o Read-Ahead com o enfileiramento de comandos mais rápido está ajudando bastante, se você observar as diferenças percentuais muito pequenas entre os eventos Random Write e Random Read, que na maioria removem o aumento do Read-Ahead, especialmente no menor tamanhos de partes.
Outra coisa que pode afetar o desempenho é o tamanho da fatia e o tamanho do bloco para quantas cabeças diferentes estão envolvidas em cada operação de leitura ou gravação.