Menor rendimiento en los servidores más nuevos.

Tenemos varios servidores db en producción, 4 de ellos con una configuración de hardware muy similar. Dell PowerEdge R620, la única diferencia es que los 2 más nuevos (comprados y configurados hace 3 meses) tienen un controlador RAID v710, 256 GB de RAM y la CPU es 2 Xeon E5-2680 física de 2,80 GHz. Los viejos (comprados y configurados hace aproximadamente 1 año) tienen un controlador RAID v700, 128 GB de RAM y se ejecutan en 2 físicos Xeon E5-2690 2.90GHz. El BIOS se actualiza, todos los controladores se actualizan a las últimas versiones, etc. Todos los SQL Server 2008R2 Enterprise (SP1) que se ejecutan se actualizan a la última CU y Windows 2012R2 Standard. Ambos se ejecutan en SSD 200 GB x5 RAID10. Solo hay una base de datos ejecutándose en cada uno de ellos, sincronizada mediante un trabajo que llama a un paquete SSIS. Nuestro administrador de sistemas ha realizado una gran cantidad de pruebas de rendimiento y estrés para garantizar que no tengamos fallas o configuraciones de hardware o fallas en la red. Como se esperaba, los más nuevos muestran mejores resultados de rendimiento. Hasta aquí todo bien.

El problema que tenemos se puede ver en la captura de pantalla de Kibana. Amarillo y naranja son los 2 servidores más nuevos (6,7 en tablas) y debajo de todos los otros servidores. Es perfectamente visible que esos 2 nuevos servidores tienen un tiempo de respuesta más lento. Y no solo eso, sino también esos 2 servidores tienen un poco menos de carga que los 2 anteriores (líneas azul claro y azul oscuro - 4,5 en las tablas).

Tenga un par de secuencias de comandos de monitoreo que recopilen información sobre los contadores de rendimiento. He cavado lo más posible con DMV y las herramientas de monitoreo de terceros, tengo mucha información a la mano. Pero debería haber (ofc) algo que me falta aquí, ya que no puedo encontrar una respuesta a este tiempo de respuesta más lento.

Los 2 servidores más nuevos están usando menos RAM, pero supongo que eso es esperado, en comparación con los otros más antiguos, ya que tienen una carga menor.

| Server Name| Mem_MB |    Mem_GB    | Server_RAM_GB | SQL_max_mem_GB| SQL_min_mem_GB |
|------------|--------|--------------|---------------|---------------|----------------|
|      4     |  41108 | 40.145263671 |     128       |      120      |      16        |
|      5     |  61272 | 59.836425781 |     128       |      120      |      16        |
|      6     |  34117 | 33.317626953 |     256       |      250      |      16        |
|      7     |  33764 | 32.972656250 |     256       |      250      |      16        |

Más configuración de RAM para todos los servidores es la siguiente:

| Server Name | Total_Page_File_In_MB | Available_Page_File_MB | Kernel_Paged_Pool_MB | Kernel_Nonpaged_Pool_MB |
|-------------|-----------------------|------------------------|----------------------|-------------------------|
| 4           | 180160                | 130042                 | 249                  | 98                      |
| 5           | 148416                | 77246                  | 249                  | 110                     |
| 6           | 301010                | 260453                 | 132                  | 99                      |
| 7           | 301010                | 260454                 | 143                  | 108                     |

La ejecución de la siguiente consulta en todos los servidores muestra parámetros de configuración idénticos:

SELECT * FROM master.sys.configurations

Podría seguir mostrando mucha más información, pero no estoy completamente seguro de lo que podría necesitarse. ¿Alguna pista sobre lo que debo verificar?

Leí un documento técnico conocido de MS Solución de problemas de rendimiento en SQL Server 2008 y tomé muchas consultas del DMV desde allí.

EDITAR A pedido:

EXEC sp_configure 'max server memory (MB)'

| Server Name | name                   | minimum | maximum    | config_value | run_value |
|-------------|------------------------|---------|------------|--------------|-----------|
| 4           | max server memory (MB) | 16      | 2147483647 | 120000       | 120000    |
| 5           | max server memory (MB) | 16      | 2147483647 | 120000       | 120000    |
| 6           | max server memory (MB) | 16      | 2147483647 | 250000       | 250000    |
| 7           | max server memory (MB) | 16      | 2147483647 | 250000       | 250000    |

En cuanto a maxdopnosotros hemos estado jugando con él y los resultados son:

 EXEC sp_configure 'max degree of parallelism'

| Server Name |            name           | minimum | maximum | config_value | run_value |
|:-----------:|:-------------------------:|:-------:|:-------:|:------------:|:---------:|
|      4      | max degree of parallelism |    0    |   1024  |       1      |     1     |
|      5      | max degree of parallelism |    0    |   1024  |       1      |     1     |
|      6      | max degree of parallelism |    0    |   1024  |       1      |     1     |
|      7      | max degree of parallelism |    0    |   1024  |       1      |     1     |

Esta imagen lo dice todo.

Gracias Kin por señalar su pregunta y respuestas relacionadas. He aprendido mucho en el proceso. Al analizar su pregunta detallada, pensé en hacer lo mismo, comparar los planes de ejecución de nuestra consulta más pesada ... ¡y listo! El problema era un trabajo que se suponía que debía ejecutarse ya tenía un par de semanas con el horario deshabilitado. Ahora debo comprobar por qué estaba deshabilitado y cuándo exactamente estaba deshabilitado. Todo está funcionando sin problemas ahora. La línea azul es un servidor que no recibe solicitudes debido a mantenimiento, no está muerto.