sql >> Base de Datos >  >> RDS >> Sqlserver

Ayuda para solucionar problemas de SqlException:el tiempo de espera expiró en la conexión, en una situación sin carga

Memoria insuficiente

Es muy probable que se trate de un problema de memoria, quizás agravado o desencadenado por otras cosas, pero sigue siendo inherentemente un problema de memoria. hay otras dos posibilidades (menos probables), que debe verificar y eliminar primero (porque es fácil hacerlo):

Posibilidades fáciles de comprobar:

  1. Es posible que tenga activado el "Cierre automático":El cierre automático puede tener exactamente este comportamiento, sin embargo, es raro que esté activado. Para verificar esto, en SSMS, haga clic con el botón derecho en la base de datos de su aplicación, seleccione "Propiedades" y luego seleccione el panel "Opciones". Mire la entrada "Cierre automático" y asegúrese de que esté configurada en Falso. Compruebe tempdb también.

  2. Los trabajos del Agente SQL pueden estar causándolo:Verifique el registro del historial del agente para ver si hubo algún trabajo ejecutándose constantemente durante los eventos. Recuerde verificar también los trabajos de mantenimiento, ya que cosas como la reconstrucción de índices se citan con frecuencia como problemas de rendimiento mientras se ejecutan. Estos son candidatos poco probables ahora, solo porque normalmente no se verían afectados por Profiler.

Por qué parece un problema de memoria:

Si esos no muestran nada, entonces debe verificar si hay problemas de memoria. Sospecho que la memoria es la causa en su caso porque:

  • Tiene 1 GB de memoria:aunque técnicamente está por encima del mínimo para SQL Server, está muy por debajo de lo recomendado para SQL Server y muy por debajo de lo que, según mi experiencia, es aceptable para producción, incluso para un servidor con poca carga.

  • Está ejecutando IIS y SQL Server en la misma caja:esto no se recomienda por sí solo, en gran parte debido a la disputa por la memoria que resulta, pero con solo 1 GB de memoria da como resultado IIS, la aplicación, SQL Server, el El sistema operativo y cualquier otra tarea y/o mantenimiento luchan por muy poca memoria. La forma en que Windows maneja esto es otorgar memoria a los procesos activos al quitársela agresivamente a los procesos no activos. Un proceso grande como SQL Server puede tardar varios segundos, o incluso minutos, en recuperar suficiente memoria para poder atender completamente una solicitud en esta situación.

  • Profiler hizo que el 90 % del problema desapareciera:esta es una gran pista de que la memoria es probablemente el problema, porque, por lo general, cosas como Profiler tienen exactamente este efecto en este problema en particular:la tarea Profiler mantiene el servidor SQL solo un poco poco activo todo el tiempo. Con frecuencia, esta es actividad suficiente para mantenerlo fuera de la lista de "buscadores" del sistema operativo, o al menos reduce un poco su impacto.

Cómo comprobar la memoria como culpable:

  1. Apague el generador de perfiles:tiene un efecto Heisenberg en el problema, por lo que debe apagarlo o no podrá ver el problema de manera confiable.

  2. Ejecute un Monitor del sistema (perfmon.exe) desde otro cuadro, que se conecta de forma remota al servicio de recopilación de rendimiento en el cuadro en el que se ejecutan SQL Server e IIS. puede hacer esto más fácilmente eliminando primero las tres estadísticas predeterminadas (solo son locales) y luego agregando las estadísticas necesarias (a continuación), pero asegúrese de cambiar el nombre de la computadora en el primer menú desplegable para conectarse a su SQL caja.

  3. Envíe los datos recopilados a un archivo creando un "Registro de contador" en perfmon. Si no está familiarizado con esto, lo más fácil es probablemente recopilar los datos en un archivo separado por tabulaciones o comas que puede abrir con Excel para analizar.

  4. Configure su perfmon para recopilar en un archivo y agregue los siguientes contadores:

    -- Procesador\%Tiempo del procesador[Total]

    -- Disco físico\% de tiempo de inactividad [para cada disco ]

    -- Disco físico\Avg. Longitud de cola de disco [para cada disco ]

    -- Memoria\Páginas/seg

    -- Memoria\Lecturas de página/seg

    -- Memoria\MBytes disponibles

    -- Interfaz de red\Bytes totales/seg[para cada interfaz en uso ]

    -- Proceso\% Tiempo de procesador[ver más abajo ]

    -- Proceso\Errores de página/seg[ver más abajo ]

    -- Proceso\Conjunto de trabajo [ver más abajo ]

  5. Para los contadores de procesos (arriba), desea incluir el proceso sqlserver.exe, cualquier proceso de IIS y cualquier proceso de aplicación estable. Tenga en cuenta que esto SOLO funcionará para procesos "estables". Los procesos que se recrean continuamente según sea necesario no se pueden capturar de esta manera porque no hay forma de especificarlos antes de que existan.

  6. Ejecute esta recopilación en un archivo durante el tiempo en que se produzca el problema con mayor frecuencia. Establezca el intervalo de recopilación en algo cercano a 10-15 segundos. (esto recopila una gran cantidad de datos, pero necesitará esta resolución para seleccionar los eventos separados).

  7. Después de tener uno o más incidentes, detenga la recopilación y luego abra su archivo de datos recopilados con Excel. Probablemente tendrá que volver a formatear la columna de marca de tiempo para que sea útilmente visible y muestre las horas, los minutos y los segundos. Utilice su registro de IIS para encontrar la hora exacta de los incidentes, luego mire los datos de perfmon para ver qué estaba pasando antes y después del incidente. En particular, desea ver si su conjunto de trabajo era pequeño antes y grande después, con muchas fallas de página en el medio. Esa es la señal más clara de este problema.

SOLUCIONES:

Separe IIS y SQL Server en dos cajas diferentes (preferido) o agregue más memoria a la caja. Creo que 3-4 GB deberían ser un mínimo.

¿Qué pasa con esas cosas raras de EF?

El problema aquí es que lo más probable es que sea periférico o solo contribuya a su problema principal. Recuerde que Profiler hizo que el 90 % de sus incidentes desaparecieran, así que lo que queda, puede ser un problema diferente, o puede ser solo el agravante más extremo. del problema. Debido a su comportamiento, supongo que está ciclando su caché o hay algún otro mantenimiento en segundo plano de los procesos del servidor de aplicaciones.