Hemos encontrado algunos problemas de rendimiento en nuestro entorno de producción.
descubrimos que cuando las sesiones activas superan los 25, el uso de la CPU alcanza el 100% y tarda mucho en disminuir.
El ambiente que tenemos:
Producto Microsoft SQL Server Enterprise Edition 9.3 (sp2)
CPU 2 (Xeon 2.13)
Memoria 7G
instantánea de la sesión detalle1
Sesiones activas 25
Transacciones activas 496
Sesiones ociosas 289
Transacciones bloqueadas 29
instantánea de detalle de la sesión2
Sesiones activas 59
Transacciones activas 885
Sesiones ociosas 267
Transacciones bloqueadas 49
Me gustaría saber:
si las 2CPU pueden manejar bien 25 sesiones activas (500 transacciones activas) .PS: hemos probado que sin solicitud de concurrencia, una transacción, que lee / escribe 5 tablas, toma aproximadamente 1 segundo en el nivel de aplicación.
si las transacciones bloqueadas requieren más uso de CPU. PS: las transacciones bloqueadas se deben principalmente a bloqueos en 2 tablas.
¿Cuál es la solución: agregar CPU o aplicación de ajuste (Java / Hibernate) para acortar esta transacción y disminuir los bloques en la mesa?
Respuestas:
Sus opciones para tener una buena imagen de la situación cuando todo está arrastrándose:
Y buena suerte investigando los problemas :-).
fuente
Su problema es muy probablemente el bajo rendimiento de la consulta causado por
Los bloqueos / bloqueos provienen de una indexación deficiente debido a todo el tiempo dedicado a escanear tablas de extremo a extremo. La CPU es irrelevante aquí.
Como solución rápida, verifique los índices faltantes utilizando la información de este artículo: http://blogs.msdn.com/b/bartd/archive/2007/07/19/are-you-using-sql-s-missing- index-dmvs.aspx
fuente
Estoy de acuerdo con GBN y Marian.
Para responder a su pregunta con respecto a las 2 CPU que manejan 25 solicitudes: Tengo un sistema de 2 CPU que admite alrededor de 750 conexiones de usuario y un promedio de solicitudes de lotes de 4K por segundo. Varios elementos son importantes para mí: diseño, administración y ajuste. Si comienza con un diseño deficiente de su aplicación y base de datos, fallará en la carga (piense en la escala).
CPU alta puede indicar presión de memoria. Menciona que solo hay 7 GB de memoria disponibles para SQL Server. Si tiene índices de bajo rendimiento (demasiados índices, índices incorrectos o ningún índice), esto hará que el sistema coloque más páginas de la base de datos en la memoria para varias solicitudes, si hay índices apropiados. Advierto que volverse loco creando índices, ya que los incorrectos también lo perjudicarán, ya que cada uno tiene el potencial de requerir una actualización en el curso de una operación de actualización de fila (Crear-Actualizar-Eliminar).
Además, el uso de los DMV de índice perdido requiere el uso de lo que sabe de su aplicación y base de datos y no solo la implementación de cada índice recomendado. Verificaría las entradas del blog de Kimberly Tripp con respecto a los índices aquí . Después de la sección Índice, mirar las otras categorías puede ser útil para su situación.
Si su actualización de Java / Hibernate de 5 tablas en una sola transacción está haciendo las actualizaciones a través de múltiples viajes de ida y vuelta a la base de datos, entonces se está quedando abierto a la contienda (solicitudes CRUD bloqueadas). El problema empeora si la aplicación no puede regresar a la base de datos de manera oportuna. Mientras está en la aplicación, la transacción activa asociada podría bloquear el procesamiento de otras solicitudes y causar tiempos de espera de solicitudes.
Agregue los dos problemas anteriores juntos y comenzará a tener un desagradable caso de dolores de cabeza por rendimiento.
Reducir la cantidad de viajes de ida y vuelta de la base de datos dentro del contexto de una sola transacción sería algo muy bueno. Quizás un procedimiento almacenado ayudaría.
El resto requerirá trabajo para poder escalar su aplicación. También puede considerar la memoria, pero eso debería ocurrir después de que se realice una revisión de diseño y rendimiento y se implementen los cambios necesarios, ya que agregar memoria de inmediato enmascarará sus problemas.
Siga absolutamente las sugerencias que Marian ha esbozado.
¡Diría que te has encontrado un desafío maravilloso y te deseo un gran éxito!
fuente
En cuanto a la solución, primero debe asegurarse de que su principal problema sea la CPU. Intente leer este problema para encontrar la fuente de sus problemas y obtener la solución adecuada. Finalmente, si puede hacer que su transacción sea lo más pequeña posible, hágalo.
fuente
Mis primeros pensamientos son reducir la cantidad de transacciones y reducir la cantidad de bloqueo. ¿Puedes separar algunas de las transacciones en varios bits? ¿Puedes sacar algunas de las consultas de las transacciones? Como Alex_l mencionó, la transacción más pequeña posible es ideal aquí.
Estoy de acuerdo con gbn, agregar índices también podría ayudar.
Otra idea es que también echaría un vistazo a tus cerraduras. ¿Está eliminando bloqueos a nivel de tabla cuando solo está actualizando una sola fila? Puede considerar sugerir un bloqueo de nivel de fila para SQL Server. Eso resolvería muchos problemas. (De acuerdo, si tienes 5 mesas, probablemente ese no sea el caso, sino solo un pensamiento).
Finalmente, echaría un vistazo a las tablas que estás usando. Si todos están bloqueando en una tabla en particular, ¿puede mover la lógica de esa tabla al final de su transacción? Si puede reducir el tiempo que mantiene un bloqueo en esa tabla de alta demanda, podría ayudar.
fuente