|
Conexões de Usuário SQLSERVER As Conexões de Usuário de Estatísticas Gerais da instância SQL no contador de desempenho correspondem a ela Você também pode consultar TCPv4Connections Established no contador de desempenho
Em uma máquina com apenas o serviço SQLSERVER,Conexões TCPV4 Estabelecidas && Conexões de Usuário MssqlEsses dois parâmetros são basicamente sincronizados e são chamados de número de conexões no conteúdo do teste a seguir
Esse número de conexões é limitado, semelhante ao número máximo de limites de concorrência. Quando esse limite é atingido, isso fará com que as consultas se tornem não responsivas mesmo que haja recursos livres de CPU, E/S e MEM (algumas, nem todas as consultas, são afetadas)
O valor máximo de TCPV4 Connections Established & Mssql UserConnections depende dos seguintes fatores
a. A complexidade da instrução de execução está relacionada: quanto mais complexa a sentença, menor o número máximo de conexões (esse efeito é muito importante)
b. Está relacionado à concorrência de threads do pedido,
10 processos, cada processo abre 5.000 threads para solicitação,SELECIONE getdate()A declaração já é abandonada quando chega a cerca de 4000 (pelo que entendi, embora muitos threads não tenham solicitado recursos, o número de requisições é grande, o que também tem impacto).
10 processos, cada processo abre 1000 threads para solicitar, SELECIONE getdate()Os extratos podem chegar a mais de 10.000.
c. Está relacionado à frequência das solicitações de thread
Se cada thread executa uma consulta e pausa por 0-10.000 milissegundos, ela ocupará menos conexões do que se não estiver suspensa
d. No teste, também foi constatado que algumas conexões não fechadas causariam o inchaço do contador, o que não foi discutido
10 processos, cada processo abre 1000 threads de requisição, pausas aleatórias (de 0 a 10 segundos) após cada consulta no servidor. Os resultados dos testes são os seguintes:
Execução:SELECT * FROM [system]. [dbo]. [DBA_alert](essa consulta retorna 200 linhas, e o número máximo de conexões é 700 e o problema começa a ser emitido)
Quando o número de conexões chega a 700, alguns erros começam a ser relatados, e às 12h00, um grande número de erros começa a aparecer, e o número de conexões em torno de 1800 fica travado e não aumenta mais. Erros e conexões lentas são abundantes
Execução:SELECIONE getdate()Tempo da sentença(O número máximo de conexões é 3500 e o problema começa)
Quando o número de conexões chega a 3500, algumas começam a apresentar erros, e a pressão máxima chega a cerca de 11000, e o número de conexões ainda está aumentando lentamente. Erros e quebras lentas na conexão
A conclusão é: sob dadas condições de pressão: a mais simples de executarO número máximo de conexões pode chegar a 3500 quando SELECT getdate() e executa SELECT * FROM [sistema]. [dbo]. [DBA_alert], o número máximo de conexões só pode chegar a 700. O tempo de espera da consulta ocorre quando CPU, IO e MEM têm um grande número de recursos ociosos.
No ambiente de produção, a pressão de 10*1000 threads não pode ser alcançada, mas o SQL será mais complexo que o ambiente de teste.
Número concorrenteO gargalo não é causado pela largura de banda do meu computador ou da placa de rede do servidor
Para provar o que foi dito acima. Fiz os seguintes testes, exec dbo.run2 no caso de grande concorrência;
ALTER proc [dbo]. [run2]
como
Coloque o nocount em
selecione getdate()
declare @i int
conjunto @i=0
enquanto @i<1000 Quando esse valor é 1000, o número máximo de conexões é cerca de 1300, e quando esse valor é 10, é normal atingir 5000.
início
INSERIR EM [pubs]. [dbo]. [tb_test] ([nome]) valores (newid())
conjunto @i=@i+1
fim
Vai
O número de ciclos de mudança não afetará o resultado de retorno, ou seja, a pressão sobre o tráfego da placa de rede é a mesma, mas um expirará rapidamente e o outro sempre pode ser verificado, eliminando assim o impacto da largura de banda das placas de rede em ambos os lados pode ser eliminado.
Conteúdo de erro quando o número máximo de conexões está parado:
NetStat - Resultado de um An quando o número máximo de conexões está preso (fortemente estabelecido):
Programa de teste executando diagrama quando o número máximo de conexões está parado:
Vale ressaltar:A conexão com erros ou timeouts não é uniforme e estará concentrada em alguns processos, ou seja, alguns processos podem sempre rodar normalmente, e a outra parte reportará erros por muito tempo (não tem nada a ver com a ordem de início dos processos, pelo que entendo, alguns processos têm recursos, podem continuar funcionando normalmente, enquanto outros processos nas threads dos recursos originais são preemptados e não podem se aplicar a novos recursos, continuam reportando erros repetidamente). Como mostrado na figura acima, o 2º e 7º processos começaram a ter um grande número de timeouts, e outros processos continuaram funcionando. No servidor, as consultas podem parecer não afetadas ou menos afetadas por algumas máquinas, e algumas máquinas são significativamente afetadas.
Conclusão: Embora o limite superior das Conexões de Usuário SQLSERVER esteja relacionado a uma série de condições, ainda é possível estimar e prever o gargalo; quando esse limite superior for atingido, haverá um grande número de consultas lentas e tempos de espera (embora CPU, IO). MEM, o tráfego também pode ocorrer quando há recursos ociosos). Na verdade, mudar alguns parâmetros TCP vai aumentar esse limite superior, e talvez eu escreva suplementos mais adiante
|
Publicado em 26/11/2014 15:11:08
|
|
|
|
