1 votos

¿Cómo puedo determinar por qué db acceso parece ser lenta con un servidor de db pero no otro utilizando el mismo sitio?

Tenemos una instalación con dos servidores web y un servidor de DB en el reino unido y Australia. Estos servidores están con Rackspace y los servidores web conectarse a la base de datos de los servidores a través de direcciones IP privadas en ambas circunstancias. El mismo sitio web en los respectivos servidores web en cada región conectados a sus respectivas regionales DB server parece generar muy distintas

Cualquier interacción entre los respectivos servidor web y servidor de db parece ser significativamente más lento a Australia en el servidor que en el reino unido. Que, obviamente, por el disparo de la acción desde un navegador en sus respectivos lugares.

El Australiano servidor de DB es ligeramente diferente, tiene un procesador más rápido y más memoria. Yo trabajo como un .NET developer así que no estoy realmente seguro de cómo determinar cuál es el problema. ¿Cómo puedo determinar lo que está pasando aquí y tratar de averiguar por qué DB acceso parece ser mucho más lento en el lado de Australia que el reino unido lado?

Hay otra diferencia, el Australiano DB se está ejecutando el servidor de IIS para un clásico de la página asp que se carga/uploads recursos de un viejo clásico de sitio asp. Este no parece ser el uso de memoria o potencia de la CPU y rara vez se utiliza, así que no veo cómo podría ser el problema. Lo que realmente me gustaría es una manera de ver donde la desaceleración del/los tiempos se están produciendo en el proceso desde el servidor web. ¿Cuál es la mejor manera de hacer esto?

editar - Lo que he notado es que en el analizador de SQL de los mismos eventos en el Australia DB parecen desencadenar mucho mayor la duración de la Auditoría de cierre de sesión. Tan lejos como puedo reunir esto sólo significa que los eventos que ocurren durante el inicio de sesión para el servidor SQL está tomando más tiempo. No estoy seguro de si cualquier cosa puede ser determinado a partir de este.

1voto

Rob Pearson Puntos 93

Aquí sería de las primeras cosas que me gustaría hacer en su situación:

  1. Descargar y ejecutar el Blitz de diagnóstico de la secuencia de comandos de Brent Ozar. Preste especial atención a los temas de alta prioridad, pero asegúrese de mirar a través de todo el informe.
  2. Yo iría a comprobar la cantidad de RAM asignada a SQL en cada servidor. De forma predeterminada, SQL tiene un número ilimitado de asignación de memoria RAM. El límite de memoria debe tener un tope máximo a 4 gb menos de RAM total en el sistema. Y el más otras cosas que se ejecuta en los servidores, el más grande de la propagación debe ser de entre SQL de la memoria de max y el sistema de cantidad instalada. El objetivo aquí es para asegurarse de que el sistema operativo no está escaso de RAM para apoyar las tareas que se le pide a la computadora. El sistema operativo no puede de manera eficiente interfaz entre el hardware y el SQL si es la memoria RAM de hambre.
  3. Descargar el Microsoft SysInternals Suite y el fuego de Process Explorer. Buscar cuellos de botella de rendimiento utilizando sus monitores de recursos, particularmente de disco I/O.
  4. También de Sysinternals Suite, uso TCPView para comprobar cómo muchas de las conexiones de su servidor de DB tiene activo. Si el número está en los cientos, probablemente será necesario prestar atención a por qué es esto y asegurarse de que nada se quede atascado.
  5. Finalmente, después de lo fácil que es verificada, romper el analizador de SQL y empezar a buscar consultas lentas y otros problemas. https://www.red-gate.com/simple-talk/sql/performance/how-to-identify-slow-running-queries-with-sql-profiler/

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: