|
Conexiones de usuario SQLSERVER Las conexiones General StatisticsUser de la instancia SQL en el contador de rendimiento le corresponden También puedes consultar TCPv4Connections Established en el contador de rendimiento
En una máquina con solo el servicio SQLSERVER,Conexiones TCPV4 establecidas y conexiones de usuario MssqlEstos dos parámetros están básicamente sincronizados y se denominan el número de conexiones en el siguiente contenido de prueba
Este número de conexiones es limitado, similar al número máximo de límites de concurrencia. Cuando se alcanza este límite, las consultas dejarán de responder aunque haya recursos libres de CPU, IO y MEM (algunas, no todas, las consultas se ven afectadas)
El valor máximo de TCPV4 Connections Established & Mssql UserConnections depende de los siguientes factores
a. La complejidad de la sentencia de ejecución está relacionada: cuanto más compleja es la afirmación, menor será el número máximo de conexiones (este efecto es muy importante)
b. Está relacionado con la concurrencia de hilos de la solicitud,
10 procesos, cada proceso abre 5.000 hilos para solicitar,SELECT getdate()La declaración ya está abandonada cuando llega a unas 4000 (según tengo entendido, aunque muchos hilos no han solicitado recursos, el número de solicitudes es grande, lo que también tiene un impacto).
10 procesos, cada proceso abre 1000 hilos para solicitar, SELECT getdate()Los estados de estado pueden superar los 10.000.
c. Está relacionado con la frecuencia de las solicitudes de hilo
Si cada hilo ejecuta una consulta y pausa entre 0 y 10.000 milisegundos, ocupará menos conexiones que si no está suspendido
d. En la prueba, también se descubrió que algunas conexiones sin cerrar provocaban que el contador se inflara, algo que no se discutió
10 procesos, cada proceso abre 1000 hilos de solicitud, pausas aleatorias (de 0 a 10 segundos) tras cada consulta en el servidor. Los resultados de las pruebas son los siguientes:
Ejecución:SELECT * FROM [system]. [dbo]. [DBA_alert](esta consulta devuelve 200 líneas, y el número máximo de conexiones es 700 y el problema empieza a emitirse)
Cuando el número de conexiones alcanza 700, empiezan a reportarse algunos errores, y a las 12:00 aparecen numerosos errores, y el número de conexiones alrededor de 18:00 se queda atascado y deja de aumentar. Los errores y las conexiones lentas son abundantes
Ejecución:SELECT getdate()Tiempo de condena(El número máximo de conexiones es 3500 y comienza el problema)
Cuando el número de conexiones alcanza 3500, algunas empiezan a reportar errores, y la presión máxima alcanza alrededor de 11000, y el número de conexiones sigue aumentando lentamente. Errores y desconexiones lentas
La conclusión es: bajo condiciones de presión dadas: la más sencilla de realizarEl número máximo de conexiones puede ser de hasta 3500 cuando SELECT getdate() y ejecuta SELECT * FROM [sistema]. [dbo]. [DBA_alert], el número máximo de conexiones solo puede ser de hasta 700. El tiempo de espera de consulta ocurre cuando CPU, IO y MEM tienen un gran número de recursos inactivos.
En el entorno de producción, no se puede alcanzar la presión de 10*1000 hilos, pero SQL será más complejo que el entorno de prueba.
Número concurrenteEl cuello de botella no se debe al ancho de banda de mi ordenador o de la tarjeta de red del servidor
Para demostrar lo anterior. Hice las siguientes pruebas: ejecuto dbo.run2 en caso de gran concurrencia;
ALTER proc [dbo]. [run2]
como
Poner nocount en
Selecciona getdate()
declarar @i int
conjunto @i=0
mientras que @i<1000 Cuando este valor es 1000, el número máximo de conexiones es de aproximadamente 1300, y cuando este valor es 10, es normal alcanzar 5000.
Comienzo
INSERTAR EN [pubs]. [dbo]. [tb_test] ([nombre]) valores (newid())
conjunto @i=@i+1
fin
¡Ve
El número de ciclos de cambio no afectará al resultado de retorno, es decir, la presión sobre el tráfico de la tarjeta de red es la misma, pero uno se agota rápidamente y el otro siempre puede comprobarse, por lo que se puede eliminar el impacto del ancho de banda de las tarjetas en ambos lados.
Contenido de error cuando el número máximo de conexiones está bloqueado:
Netstat-An resulta cuando el número máximo de conexiones está bloqueado (fuertemente establecido):
Programa de prueba ejecutando diagrama cuando el número máximo de conexiones está detenido:
Cabe señalar:La conexión con errores o tiempos de espera no es uniforme y se concentrará en algunos procesos, es decir, algunos procesos siempre pueden funcionar con normalidad, y la otra parte reportará errores durante mucho tiempo (no tiene nada que ver con el orden de inicio de los procesos, tengo entendido que algunos procesos tienen recursos, pueden seguir funcionando normalmente, mientras que otros procesos en los hilos de los recursos originales están preemptados y no pueden solicitar nuevos recursos, y seguirán reportando errores repetidamente). Como se muestra en la figura anterior, el segundo y séptimo proceso empezaron a tener un gran número de tiempos de espera, y otros procesos continuaron funcionando. En el servidor, las consultas pueden parecer no afectadas o menos afectadas por algunas máquinas, y algunas máquinas se ven significativamente afectadas.
Conclusión: Aunque el límite superior de las conexiones de usuario SQLSERVER está relacionado con una serie de condiciones, aún es posible estimar y predecir el cuello de botella; cuando se alcanza este límite superior, habrá un gran número de consultas lentas y tiempos de espera (aunque CPU, IO). MEM, el tráfico también puede ocurrir cuando hay recursos inactivos). De hecho, cambiar algunos parámetros TCP aumentará este límite superior, y puede que escriba suplementos más adelante
|
Publicado en 26/11/2014 15:11:08
|
|
|
|
