Pediram-me para examinar um servidor de banco de dados/aplicativo que está "desempenhando lentamente". Ninguém poderia realmente me dizer o que estava lento (exceto para os backups do banco de dados), então este foi um processo de descoberta.
Este servidor está em Dell PowerEdge R720execução Windows Server 2008 R2e SQL Server 2012 Standard (11.0.2100.60) (x64).
-CPU Intel(R) Xeon(R) E5-2640 0 @ 2,50 GHz, 2500 Mhz, 6 Núcleos, 12 Processadores Lógicos
-16 GB RAM
-Dispositivo de disco DELL PERC S110 SCSI em execução como um software RAID 5.
O disco é particionado em duas unidades locais: C e D. Os arquivos do sistema operacional estão todos em C. O SQL Server está instalado em D e os arquivos de banco de dados (.mdf e .ldf) também estão em D. Além disso, estamos gravando nossos backups noturnos na unidade D! :-)
O arquivo mdf do banco de dados tem cerca de 6 GB. Os backups estão demorando 30 minutos.
Uma rápida olhada nos tipos de espera revelou que o WRITELOGtipo de espera era o mais prevalente - consumindo 69%:
Suspeitando de problemas de desempenho de log/disco de transações, habilitei vários contadores PerfMon e estabeleci médias de linha de base em alguns dias. Os contadores PerfMon incluem, mas não estão limitados a:
\PhysicalDisk(0 C: D:)\Avg. Disk sec/Write - Avg = 0.073
\SQLServer:Databases\Log Flush Wait Time - Avg = 71.403
\SQLServer:Databases\Log Flushes/sec - Avg = 1.910
\SQLServer:Databases\Log Bytes Flushed/sec - Avg = 1724.604
O log de transações foi originalmente configurado com um tamanho inicial de 100MBe definido para crescer em 10%. Quando entrei na máquina pela primeira vez, o log de transações havia aumentado, 5GBsugerindo 256 VLFsalguma fragmentação.
A consulta de Paul Randall sys.dm_io_virtual_file_statsrevela uma séria latência de gravação com os arquivos de dados e de log - embora, ao contrário do tipo de espera WRITELOG, a latência de gravação do arquivo de dados seja um pouco maior:
Data File: 1369
Log File: 66
Com base no artigo de Kimberly Tripp, "reconstruí" o log de transações e atribuí a ele um tamanho de 2 GB (um tanto arbitrariamente), gerando 24 VLFs.
Isso pareceu diminuir a WRITELOGporcentagem do tipo de espera (agora em ~61%), bem como \SQLServer:Databases\Log Flush Wait Time(agora em ~48ms).
Ônibus isso ainda parece alto.
Percebo que os arquivos de dados e log (e backups) devem estar todos em unidades diferentes para leituras/gravações paralelas e taxa de transferência máxima. Deixando de lado as melhores práticas, temos outros sistemas de produção configurados da mesma forma que este, mas que estão rodando melhor, por exemplo, Avg Log Flush Wait Time = < 3 ms.
O que mais eu poderia examinar para descobrir por que esse servidor em particular é mais lento em relação ao tempo de resposta de leitura/gravação do disco e backups?
As configurações de fragmentação de índice/fator de preenchimento podem causar esse baixo desempenho? E a fragmentação do disco?
Se eu precisar dizer ao cliente que precisamos de outro disco, que assim seja - só quero ter certeza antes de gastar dinheiro.
Alguma outra ideia???
Pontos:
RAID 5 é uma configuração de baixo desempenho para arquivos de banco de dados, especialmente para gravações, e
Particionar é ainda pior.
Sim, funciona e é confiável, mas é definitivamente uma configuração de disco de baixo desempenho que eu usaria apenas para desenvolvimento ou o mais leve dos aplicativos. A configuração padrão para o host físico de um SQL Server são volumes físicos separados para o sistema e discos de dados usando RAID 1+0.
Também observarei a recomendação de @ Spörri: primeiro, verifique se a matriz RAID está degradada devido a um disco com falha.