Shamvil Kazmi's questions

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

1. SAN

RESTORE DATABASE processou com sucesso 612.466 páginas em 369,425 segundos (12,952 MB/s).

2. 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

Informação do servidor

SO Redhat 7 Memória 100 GB Uso da CPU 1% Tamanho do banco de dados do usuário 2 GB cada em média total 7 bancos de dados de usuários SSMS instalado em um servidor de salto Azure Data Studio também está instalado App Gui no servidor de aplicativos Latência entre servidor de salto para servidor de banco de dados <1ms Latência entre aplicativos servidor e servidor db <1ms todos estão na mesma rede, apenas o switch está entre eles todos são máquinas físicas

Questão

1. SSMS - Quando me conecto ao SSMS, os bancos de dados no explorador de objetos demoram cerca de 30 segundos para serem preenchidos. A abertura das propriedades do banco de dados leva até 50 segundos para abrir o Query Analyzer/sqlcmd do SSMS executa "select name from sys.sysdatabases" instantaneamente sem demora

2. Estúdio de dados do Azure - preenche a lista de bancos de dados com bastante rapidez, mas leva mais de um minuto para mostrar as propriedades do banco de dados.

3. App Gui - também tem o mesmo comportamento do SSMS.

De todos os locais, a consulta parece rápida o suficiente, mas a GUI é lenta.

Cenário diferente

Eu tenho outro SQL Server no sistema operacional Windows, o SSMS, o comportamento do estúdio de dados do Azure é comum onde eles preenchem informações na GUI instantaneamente. Também temos poucos bancos de dados no Banco de Dados SQL do Azure e na VM do Azure, eles também se conectam instantaneamente e preenchem informações instantaneamente na GUI do SSMS

O que queremos alcançar?

Precisamos que nosso App gui, SSMS, funcione tão rápido quanto o SQL Server no sistema operacional Windows no nível do gui.

Então, qual poderia ser o problema e como posso corrigir isso?

Por favor ajude!

Editar -

Eu perdi a parte mais importante. A referida instância é a edição Express. Portanto, o hardware super impressionante que eles colocaram nele não estava sendo totalmente utilizado. Além do recurso padrão de fechamento automático.