Baisse des performances sur les serveurs les plus récents


8

Nous avons plusieurs serveurs db en production, 4 d'entre eux avec une configuration matérielle très similaire. Dell PowerEdge R620, la seule différence est que les 2 plus récents (achetés et configurés il y a 3 mois) ont un contrôleur RAID v710, 256 Go de RAM et le processeur est 2 Xeon E5-2680 2,80 GHz physiques. Les anciens (achetés et configurés il y a environ 1 an) ont un contrôleur RAID v700, 128 Go de RAM et fonctionnant avec 2 physiques Xeon E5-2690 2,90 GHz. Le BIOS est mis à jour, tous les pilotes mis à jour vers les dernières versions, etc. Tous les exécutants SQL Server 2008R2 Enterprise (SP1) sont mis à jour pour la dernière CU et Windows 2012R2 Standard. Tous deux fonctionnant sur 200 Go SSD x5 RAID10. Il n'y a qu'une seule base de données en cours d'exécution sur chacun d'eux, synchronisée à l'aide d'un travail qui appelle un package SSIS. Notre administrateur système a exécuté beaucoup de tests de performance et de stress pour s'assurer que nous n'avons pas de configuration ou d'échec de matériel ou de réseau. Comme prévu, les plus récents affichent de meilleurs résultats de performance. Jusqu'ici tout va bien.

Le problème que nous avons peut être vu sur la capture d'écran de Kibana. Le jaune et l'orange sont les 2 serveurs les plus récents (6,7 sur les tables) et en dessous de tous les autres serveurs. Est parfaitement visible que ces 2 nouveaux serveurs ont un temps de réponse plus lent. Et non seulement cela, mais aussi ces 2 serveurs ont un peu moins de charge que les 2 plus anciens (lignes bleu clair et bleu foncé - 4,5 sur les tables).

entrez la description de l'image ici Avoir quelques scripts de surveillance rassemblant des informations sur les compteurs de performances. J'ai creusé autant que possible avec les DMV et les troisièmes outils de surveillance, j'ai beaucoup d'informations à portée de main. Mais il devrait y avoir (ofc) quelque chose qui me manque ici car je ne trouve pas de réponse à ce temps de réponse plus lent.

Les 2 serveurs les plus récents utilisent moins de RAM, mais je suppose que c'est prévu, par rapport aux autres plus anciens car ceux-ci ont une charge inférieure.

| 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        |

La configuration RAM supplémentaire pour tous les serveurs est la suivante:

| 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                     |

L'exécution de la requête suivante sur tous les serveurs affiche des paramètres de configuration identiques:

SELECT * FROM master.sys.configurations

Je pourrais continuer à montrer beaucoup plus d'informations mais je ne suis pas sûr de ce qui pourrait être nécessaire. Un indice sur ce que je devrais vérifier?

J'ai lu un livre blanc connu de MS Dépannage des problèmes de performances dans SQL Server 2008 et pris beaucoup de requêtes DMV à partir de là.

MODIFIER Sur demande:

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    |

Quant à maxdopnous avons joué avec et les résultats sont les suivants:

 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     |

Les commentaires ne sont pas pour une discussion approfondie; cette conversation a été déplacée vers le chat .
Paul White 9

Réponses:


1

Cette image dit tout.

entrez la description de l'image ici

Merci Kin d'avoir signalé votre question et les réponses associées. J'ai beaucoup appris au cours du processus. En examinant votre question détaillée, j'ai pensé à faire de même, en comparant les plans d'exécution de notre requête la plus lourde ... et le tour est joué !! Le problème était un travail qui devait être exécuté il y a déjà quelques semaines avec un horaire désactivé. Maintenant, je dois vérifier pourquoi il a été désactivé et quand exactement il a été désactivé. Tout se passe bien maintenant. La ligne bleue est un serveur ne recevant pas de demandes en raison de la maintenance, n'est pas mort.

entrez la description de l'image ici

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.