Sou novo no Linux e nosso cliente decidiu usar o SQL Server no Linux. Assim que começamos a testar, encontramos problemas de desempenho.
O servidor em questão é uma máquina física configurada com um disco local SSD e um armazenamento conectado "nativamente". Eu não sei o que uma citação "nativamente" realmente significa aqui. Palavras exatas do cara do Linux abaixo
o armazenamento é "nativamente" anexado ao servidor
A rede de área de armazenamento também é construída em cima do SSD e copiei um arquivo de backup de 4,7 GB de lá para o SSD local em um segundo.
cp \gsfs\sql\backups\testdb01.bak \tmp\backups\testdb01.bak
Mas quando tento restaurar de
- SAN
RESTORE DATABASE processou com sucesso 612.466 páginas em 369,425 segundos (12,952 MB/s).
- Disco local
RESTORE DATABASE processou com sucesso 612.466 páginas em 26,248 segundos (182,295 MB/s).
Os arquivos de banco de dados também são armazenados na SAN e, embora a SAN para a máquina física não tenha problemas de conectividade, estou certo de que a maneira como o MS SQL lê os arquivos na SAN tem algo a ver com a lentidão.
O tamanho do banco de dados não é grande o suficiente e o banco de dados geralmente está ocioso com base nas estatísticas de espera
Quero entender por que o SQL Server está restaurando da SAN mais lentamente que o sistema de arquivos local. Eu entenderia se a diferença fosse pequena, mas atualmente, a diferença é dramática. Como nossos arquivos de dados e arquivos de log também estão na SAN, precisamos garantir que o disco seja lido/gravado o mais rápido possível.
- A maioria das configurações são definidas como padrão
- tamanho do pacote de rede é 4096
- Nenhum antivírus instalado
Larguei o emprego, então não sei o que eles fizeram a respeito. Antes de sair, foi decidido que um administrador de SAN investigaria se seu armazenamento estava lento ou se eles estavam enfrentando outros desafios.
Fechando esta pergunta, pois não há como rastrear mais o problema.