Eu tenho uma matriz RAID 5 na qual um banco de dados lê e grava pequenas quantidades de dados.
Em circunstâncias normais, as operações do banco de dados, incluindo a confirmação, são executadas em um tempo aceitável. No entanto, quando uma grande quantidade de dados é carregada na matriz RAID (mas não no banco de dados), a confirmação (mas não as outras operações) torna-se inaceitavelmente lenta.
Minha suposição atual é que o commit demora muito porque as informações de paridade precisam ser calculadas e/ou gravadas no disco.
Existe uma maneira de verificar minha suposição, ou seja, existe uma ferramenta que exibe a quantidade de CPU necessária para calcular as informações de paridade e se esse é o gargalo.
Além disso, estou pensando em mudar o array para RAID 10 ou RAID 1. Mas antes de fazer isso, existe uma abordagem científica que me permita estimar se vale a pena o incômodo?
Estou executando o Debian 12 com um RAID de software ( /dev/md/
).
Abra vários terminais e fique de olho em top ou htop . Procure especificamente picos no uso da CPU durante confirmações do banco de dados.
ou
Use iostat para ver quanto tempo a CPU gasta em operações de E/S:
O comando sar pode ser usado para coletar, relatar ou salvar informações de atividade do sistema, que incluem o uso da CPU.
Fornece uma visão geral do uso da CPU, incluindo o sistema e os tempos de espera de E/S
Dependendo do controlador RAID ou do software RAID que você está usando, pode haver ferramentas ou logs específicos que podem fornecer informações sobre as operações RAID. Para mdadm, verifique /proc/mdstat para status do RAID. Use iostat -xmd 1 para estatísticas detalhadas de E/S de RAID.
Além disso, traçar o perfil do processo de confirmação do banco de dados. Use strace para rastrear chamadas e sinais do sistema. Isso pode ajudar a identificar onde o processo passa a maior parte do tempo.
Isso resumirá o uso de chamadas do sistema e poderá destacar o tempo gasto em operações de E/S.
Use perf para criar o perfil do sistema e identificar gargalos.
ou
seguido pela
Eu acho que você já fez tudo isso.
É provável que o RAID 10 melhore significativamente o desempenho, mas eu gostaria que ele fosse devidamente documentado com resultados empíricos e revisado antes de emitir alguma RFC. O seguinte exigirá um pouco de esforço, mas definitivamente vale a pena.
Use ferramentas de benchmarking para medir o desempenho antes e depois das alterações. Ferramentas como fio (Flexible I/O Tester) podem ser usadas para simular cargas de banco de dados e medir o desempenho.
IMPORTANTE:
Crie um ambiente de teste separado e isolado para configurar e avaliar um array RAID 10 sem afetar seu sistema de produção atual.
Execute o benchmark fio em seu array RAID 5 existente :
Criar matriz RAID 10 de teste :
Use discos sobressalentes ou virtuais para esta configuração de teste (/dev/sdx, /dev/sdy, etc.).
Formatar e montar matriz RAID 10 de teste:
Execute o fio Benchmark no RAID 10:
Compare os resultados do fio dos benchmarks RAID 5 e RAID 10 para avaliar melhorias de desempenho.
Avalie os resultados
Métricas para comparar:
Em seguida, decida mudar para o RAID 10. Com base em seus benchmarks e na análise de uso da CPU, você pode tomar uma decisão informada sobre se a mudança para o RAID 10 resolverá seus problemas de desempenho.
Ao criar um array RAID 10 de teste em um ambiente isolado , você pode avaliar seu desempenho e compará-lo com sua configuração RAID 5 atual sem interromper seu sistema de produção. Dessa forma, você pode avaliar cientificamente se vale a pena mudar para o RAID 10 e se isso resolverá seus problemas de desempenho de maneira eficaz.
Boa sorte!