Problèmes de performances majeurs sur notre serveur SQL de production, comment puis-je résoudre ce problème?
Cette question est essentiellement la question de suivi de cette question:
Problème de performances étrange avec SQL Server 2016
Nous sommes maintenant devenus productifs avec ce système. Bien qu'une autre base de données d'application ait été ajoutée à ce serveur SQL depuis mon dernier message.
ce sont les statistiques du système:
- 128 Go RAM (mémoire maximale de 110 Go pour SQL Server)
- 4 cœurs à 2,6 GHz
- Connexion réseau de 10 Go
- Tout le stockage est basé sur SSD
- Les fichiers programme, les fichiers journaux, les fichiers de base de données et tempdb se trouvent sur des partitions distinctes du serveur
- Windows Server 2012 R2
- Version VMware HPE-ESXi-6.0.0-Update3-iso-600.9.7.0.17
- VMware Tools version 10.0.9, build 3917699
- Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64) 28 octobre 2016 18:17:30 Copyright (c) Microsoft Corporation Standard Edition (64 bits) sur Windows Server 2012 R2 Standard 6.3 (Build 9600:) (Hyperviseur)
Notre système présente maintenant des problèmes de performances majeurs. Utilisation très élevée du processeur et nombre de threads: 
Statistiques d'attente du moniteur d'activité (je sais que ce n'est pas très fiable)
Résultats de sp_blitzfirst:
Résultats de sp_configure:
Paramètres de serveur avancés (malheureusement seulement en allemand)
Le paramètre MAXDOP a été modifié par moi.
Je suis conscient que ce n'est probablement pas un problème avec le serveur SQL lui-même . C'est probablement un problème de virtualisation (vmware), lié au réseau (j'ai déjà testé cela) ou à l'application elle-même. Je veux juste le clouer encore plus loin.
Un ASYNC_NETWORK_IO élevé entraînerait-il un nombre élevé de threads pour le processus sqlserver? J'imagine que cela touche de nombreux travailleurs car les threads ne peuvent pas être fermés. Est-ce correct?
Je fournirai toutes les informations supplémentaires dont vous avez besoin. Merci d'avance pour ton aide!
MODIFIER:
Résultat de sp_Blitz @OutputType = ‘markdown’, @CheckServerInfo = 1
Priorité 1: Sauvegarde :
- Sauvegarde sur le même lecteur où résident les bases de données - 5 sauvegardes effectuées sur le lecteur E:\au cours des deux dernières semaines, où vivent également les fichiers de base de données. Cela représente un risque sérieux en cas de défaillance de cette baie.
Priorité 1: Fiabilité :
Dernier bon DBCC CHECKDB de plus de 2 semaines
babtec_prod - Dernier succès CHECKDB: 2017-08-20 00: 01: 01.513
D3PR - Dernier CHECKDB réussi: jamais.
DEMO77 - Dernier succès CHECKDB: 2016-02-23 20: 31: 38.590
FINP - Dernier succès CHECKDB: 2017-04-23 22: 01: 19.133
GridVis_EnMs - Dernier succès CHECKDB: 2017-05-18 22: 10: 48.120
master - Dernier CHECKDB réussi: jamais.
modèle
msdb
PROD77 - Dernier succès CHECKDB: 2016-02-23 21: 33: 24.343
Priorité 10: Performances :
Query Store Disabled - La nouvelle fonctionnalité SQL Server 2016 Query Store n'a pas été activée sur cette base de données.
babtec_prod
D3PR
DEMO77
FINP
GridVis_EnMs
Priorité 50: Événements DBCC :
DBCC DROPCLEANBUFFERS - L'utilisateur schorsch a exécuté DBCC DROPCLEANBUFFERS 1 fois entre le 21 septembre 2017 11:57 et le 21 septembre 2017 11:57. S'il s'agit d'une boîte de production, sachez que vous effacez toutes les données de la mémoire lorsque cela se produit. Quel genre de monstre ferait ça?
DBCC SHRINK% - L'utilisateur schorsch a exécuté 6 fois le fichier rétréci entre le 21 septembre 2017 23h51 et le 4 octobre 2017 9h02. Alors, essaient-ils de réparer la corruption ou de provoquer la corruption?
Événements globaux - 287 événements DBCC ont eu lieu entre le 19 septembre 2017 à 13 h 40 et le 4 octobre 2017 à 15 h 20. Cela n'inclut pas CHECKDB et d'autres événements DBCC généralement bénins.
Priorité 50: Performances :
- File Growths Slow PROD77 - 2 croissances ont pris plus de 15 secondes chacune. Envisagez de définir la croissance automatique du fichier sur un incrément plus petit.
Priorité 50: Fiabilité :
- Vérification de page non optimale babtec_prod - La base de données [babtec_prod] a TORN_PAGE_DETECTION pour la vérification de page. SQL Server peut avoir plus de difficulté à reconnaître et à récupérer d'une corruption de stockage. Envisagez plutôt d'utiliser CHECKSUM.
Priorité 100: Performances :
- De nombreux plans pour une seule requête - 3576 plans sont présents pour une seule requête dans le cache de plan - ce qui signifie que nous avons probablement des problèmes de paramétrage.
Priorité 110: Performances :
Tables actives sans index cluster
babtec_prod - La base de données [babtec_prod] contient des tas - des tables sans index cluster - qui sont activement interrogés.
D3PR - La base de données [D3PR] contient des tas - des tables sans index cluster - qui sont activement interrogés.
DEMO77 - La base de données [DEMO77] contient des tas - des tables sans index cluster - qui sont activement interrogés.
FINP - La base de données [FINP] contient des tas - des tables sans index cluster - qui sont activement interrogés.
GridVis_EnMs - La base de données [GridVis_EnMs] contient des tas - tables sans index cluster - qui sont activement interrogés.
PROD77 - La base de données [PROD77] contient des tas - des tables sans index cluster - qui sont activement interrogés.
Priorité 150: Performances :
Clés étrangères non approuvées
babtec_prod - La base de données [babtec_prod] contient des clés étrangères probablement désactivées, les données ont été modifiées, puis la clé a été réactivée. L'activation de la clé ne suffit pas pour que l'optimiseur utilise cette clé - nous devons modifier la table à l'aide du paramètre WITH CHECK CHECK CONSTRAINT.
D3PR - La base de données [D3PR] contient des clés étrangères probablement désactivées, les données ont été modifiées, puis la clé a été réactivée. L'activation de la clé ne suffit pas pour que l'optimiseur utilise cette clé - nous devons modifier la table à l'aide du paramètre WITH CHECK CHECK CONSTRAINT.
Tables inactives sans index cluster
D3PR - La base de données [D3PR] contient des tas - des tables sans index cluster - qui n'ont pas été interrogées depuis le dernier redémarrage. Il peut s'agir de tables de sauvegarde négligemment laissées.
GridVis_EnMs - La base de données [GridVis_EnMs] contient des tas - tables sans index cluster - qui n'ont pas été interrogés depuis le dernier redémarrage. Il peut s'agir de tables de sauvegarde négligemment laissées.
Déclencheurs sur les tables babtec_prod - La base de données [babtec_prod] a 26 déclencheurs.
Priorité 170: Configuration des fichiers :
Base de données système sur le lecteur C
master - La base de données master possède un fichier sur le lecteur C. Placer des bases de données système sur le lecteur C risque de faire planter le serveur lorsqu'il manque d'espace.
model - La base de données model contient un fichier sur le lecteur C. Placer des bases de données système sur le lecteur C risque de faire planter le serveur lorsqu'il manque d'espace.
msdb - La base de données msdb contient un fichier sur le lecteur C. Placer des bases de données système sur le lecteur C risque de faire planter le serveur lorsqu'il manque d'espace.
Priorité 170: Fiabilité :
Taille de fichier maximale définie
D3PR - Le fichier de base de données [D3PR] d3_data_01 a une taille de fichier maximale définie sur 61440 Mo. S'il manque d'espace, la base de données cessera de fonctionner même s'il y a peut-être de l'espace disque disponible.
D3PR - Le fichier de base de données [D3PR] d3_data_idx_01 a une taille de fichier maximale définie sur 61440 Mo. S'il manque d'espace, la base de données cessera de fonctionner même s'il y a peut-être de l'espace disque disponible.
D3PR - Le fichier de base de données [D3PR] d3_firm_01 a une taille de fichier maximale définie sur 61440 Mo. S'il manque d'espace, la base de données cessera de fonctionner même s'il y a peut-être de l'espace disque disponible.
D3PR - Le fichier de base de données [D3PR] d3_firm_idx_01 a une taille de fichier maximale définie sur 61440 Mo. S'il manque d'espace, la base de données cessera de fonctionner même s'il y a peut-être de l'espace disque disponible.
D3PR - Le fichier de base de données [D3PR] d3_log_01 a une taille de fichier maximale définie sur 61440 Mo. S'il manque d'espace, la base de données cessera de fonctionner même s'il y a peut-être de l'espace disque disponible.
D3PR - Le fichier de base de données [D3PR] d3_phys_01 a une taille de fichier maximale définie sur 61440 Mo. S'il manque d'espace, la base de données cessera de fonctionner même s'il y a peut-être de l'espace disque disponible.
D3PR - Le fichier de base de données [D3PR] d3_phys_idx_01 a une taille de fichier maximale définie sur 61440 Mo. S'il manque d'espace, la base de données cessera de fonctionner même s'il y a peut-être de l'espace disque disponible.
D3PR - Le fichier de base de données [D3PR] d3_sys_01 a une taille de fichier maximale définie sur 20480 Mo. S'il manque d'espace, la base de données cessera de fonctionner même s'il y a peut-être de l'espace disque disponible.
D3PR - Le fichier de base de données [D3PR] d3_usr_01 a une taille de fichier maximale définie sur 20480 Mo. S'il manque d'espace, la base de données cessera de fonctionner même s'il y a peut-être de l'espace disque disponible.
D3PR - Le fichier de base de données [D3PR] d3_wort_01 a une taille de fichier maximale définie sur 20480 Mo. S'il manque d'espace, la base de données cessera de fonctionner même s'il y a peut-être de l'espace disque disponible.
D3PR - Le fichier de base de données [D3PR] d3_wort_idx_01 a une taille de fichier maximale définie sur 20480 Mo. S'il manque d'espace, la base de données cessera de fonctionner même s'il y a peut-être de l'espace disque disponible.
Priorité 200: Information :
Compression de sauvegarde par défaut désactivée - Des sauvegardes complètes non compressées se sont produites récemment et la compression de sauvegarde n'est pas activée au niveau du serveur. La compression de sauvegarde est incluse avec SQL Server 2008R2 et plus récent, même dans l'édition Standard. Nous vous recommandons d'activer la compression de sauvegarde par défaut afin que les sauvegardes ad hoc soient compressées.
Le classement est Latin1_General_CS_AS FINP - Les différences de classement entre les bases de données utilisateur et tempdb peuvent provoquer des conflits, en particulier lors de la comparaison des valeurs de chaîne
Le classement est SQL_Latin1_General_CP1_CI_AS - Les différences de classement entre les bases de données utilisateur et tempdb peuvent provoquer des conflits, en particulier lors de la comparaison des valeurs de chaîne
DEMO77
PROD77
Serveur lié configuré - BWIN2\INFOR est configuré en tant que serveur lié. Vérifiez sa configuration de sécurité lors de sa connexion avec sa, car tout utilisateur qui l'interroge obtiendra des autorisations de niveau administrateur.
Priorité 200: Surveillance :
Travaux d'agent sans e-mails d'échec
Le travail syspolicy_purge_history n'a pas été configuré pour avertir un opérateur en cas d'échec.
Le travail upd_durchpreis_monatl n'a pas été configuré pour avertir un opérateur en cas d'échec.
La tâche upd_fertmengen_woche n'a pas été configurée pour avertir un opérateur en cas d'échec.
Le travail upd_liegezeit_monatl n'a pas été configuré pour avertir un opérateur en cas d'échec.
Le travail upd_vertreter_diff n'a pas été configuré pour avertir un opérateur en cas d'échec.
Le travail UPDATE_CONNECT_IK n'a pas été configuré pour avertir un opérateur en cas d'échec.
Le travail Wartung.Cleanup n'a pas été configuré pour avertir un opérateur en cas d'échec.
Le travail Wartung.DBCC Check DB n'a pas été configuré pour avertir un opérateur en cas d'échec.
La tâche Wartung.Index neu erstellen n'a pas été configurée pour avertir un opérateur en cas d'échec.
Le travail Wartung.Statistiken aktualisieren n'a pas été configuré pour avertir un opérateur en cas d'échec.
Le travail Wartung.Transactionlog Backup n'a pas été configuré pour avertir un opérateur en cas d'échec.
Le travail Wartung.Vollbackup SystemDB n'a pas été configuré pour avertir un opérateur en cas d'échec.
Le travail Wartung.Vollbackup UserDB n'a pas été configuré pour avertir un opérateur en cas d'échec.
Aucune alerte pour la corruption - les alertes de l'Agent SQL Server n'existent pas pour les erreurs 823, 824 et 825. Ces trois erreurs peuvent vous avertir d'une défaillance matérielle précoce. Les activer peut vous éviter beaucoup de chagrins.
Aucune alerte pour Sev 19-25 - Les alertes de l'Agent SQL Server n'existent pas pour les niveaux de gravité 19 à 25. Il s'agit d'erreurs SQL Server très graves. Le fait de savoir que cela se produit peut vous permettre de récupérer plus rapidement des erreurs.
Pas toutes les alertes configurées - Toutes les alertes de l'Agent SQL Server n'ont pas été configurées. Il s'agit d'un moyen gratuit et facile d'être informé de la corruption, des échecs de travail ou des pannes majeures avant même que les systèmes de surveillance ne le détectent.
Priorité 200: Configuration du serveur non par défaut :
Agent XPs - Cette option sp_configure a été modifiée. Sa valeur par défaut est 0 et elle a été définie sur 1.
Base de données XP de messagerie - Cette option sp_configure a été modifiée. Sa valeur par défaut est 0 et elle a été définie sur 1.
langue de texte intégral par défaut - Cette option sp_configure a été modifiée. Sa valeur par défaut est 1033 et elle a été définie sur 1031.
langue par défaut - Cette option sp_configure a été modifiée. Sa valeur par défaut est 0 et elle a été définie sur 1.
niveau d'accès filestream - Cette option sp_configure a été modifiée. Sa valeur par défaut est 0 et elle a été définie sur 1.
degré maximum de parallélisme - Cette option sp_configure a été modifiée. Sa valeur par défaut est 0 et elle a été définie sur 4.
max server memory (MB) - Cette option sp_configure a été modifiée. Sa valeur par défaut est 2147483647 et elle a été définie sur 115000.
mémoire minimale du serveur (Mo) - Cette option sp_configure a été modifiée. Sa valeur par défaut est 0 et elle a été définie sur 10000.
connexions d'administration distante - Cette option sp_configure a été modifiée. Sa valeur par défaut est 0 et elle a été définie sur 1.
Priorité 200: Performances :
seuil de coût pour le parallélisme - Défini sur 5, sa valeur par défaut. La modification de ce paramètre sp_configure peut réduire les attentes de CXPACKET.
Sauvegardes d'instantanés en cours - 9 sauvegardes d'apparence d'instantanés se sont produites au cours des deux dernières semaines, indiquant que IO peut être bloqué.
Priorité 210: Configuration de base de données non par défaut :
Lire l'isolement de l'instantané validé activé - Ce paramètre de base de données n'est pas la valeur par défaut.
D3PR
FINP
Déclencheurs récursifs activés - Ce paramètre de base de données n'est pas la valeur par défaut.
DEMO77
PROD77
Snapshot Isolation Enabled FINP - Ce paramètre de base de données n'est pas la valeur par défaut.
Priorité 240: Statistiques d'attente :
1 - ASYNC_NETWORK_IO - 225,9 heures d'attente, 143,5 minutes de temps d'attente moyen par heure, 0,2% d'attente de signal, 2146022 tâches en attente, temps d'attente moyen de 378,9 ms.
2 - CXPACKET - 43,1 heures d'attente, 27,4 minutes de temps d'attente moyen par heure, 1,5% d'attente de signal, 32608391 tâches en attente, 4,8 ms de temps d'attente moyen.
Priorité 250: Information :
SQL Server s'exécute sous un compte de service NT
J'exécute en tant que NT Service\MSSQL $ INFOR. J'aimerais avoir un compte de service Active Directory à la place.
J'exécute en tant que NT Service\SQLAgent $ INFOR. J'aimerais avoir un compte de service Active Directory à la place.
Priorité 250: Informations sur le serveur :
Contenu de la trace par défaut - La trace par défaut contient 760 heures de données entre le 3 septembre 2017 20h34 et le 5 octobre 2017 12h50. Les fichiers de trace par défaut se trouvent dans: C:\Program Files\Microsoft SQL Server\MSSQL13.INFOR\MSSQL\Log
Drive C Space - 21308,00 Mo gratuits sur le lecteur C
- Drive D Space - 280008,00 Mo gratuits sur le lecteur D
- Drive E Space - 281618,00 Mo gratuits sur le lecteur E
Drive F Space - 60193,00 Mo gratuits sur le lecteur F
Matériel - Processeurs logiques: 4. Mémoire physique: 128 Go.
Matériel - NUMA Config - Noeud: 0 État: EN LIGNE Planificateurs en ligne: 4 Planificateurs hors ligne: 0 Groupe de processeurs: 0 Nœud de mémoire: 0 Mémoire VAS réservée GB: 281
Dernier redémarrage du serveur - 1 octobre 2017 14:21
Nom du serveur - BWINPDB\INFOR
Prestations de service
Service: SQL Server (INFOR) s'exécute sous le compte de service NT Service\MSSQL $ INFOR. Dernière heure de démarrage: 1 oct. 2017 14:22. Type de démarrage: automatique, en cours d'exécution.
Service: SQL Server-Agent (INFOR) s'exécute sous le compte de service NT Service\SQLAgent $ INFOR. Dernier démarrage: non affiché. Type de démarrage: automatique, en cours d'exécution.
Dernier redémarrage de SQL Server - 1 octobre 2017 14:22
Service SQL Server - Version: 13.0.4001.0. Niveau de patch: SP1. Édition: Édition Standard (64 bits). AlwaysOn activé: 0. Statut de gestion AlwaysOn: 2
Serveur virtuel - Type: (HYPERVISOR)
Version Windows - Vous utilisez une version assez moderne de Windows: ère Server 2012R2, version 6.3
Priorité 254: Rundate :
- Journal du capitaine: starder quelque chose et quelque chose ...
MODIFIER:
J'ai déjà étudié le guide des meilleures pratiques concernant la configuration d'un serveur SQL avec VMware, et nous en avons défini la plupart en fonction de cet article. Cependant, l'hyperthreading n'est pas activé et NUMA n'est pas actif sur l'hôte vmware. SQL Server est cependant défini sur NUMA.
MODIFIER:
J'ai émis la RECONFIGURE après avoir défini le seuil de vente pour le parallélisme à 50, également mon paramètre MAXDOP de n'a pas été configuré.
J'ai également vérifié auprès de notre administrateur vmware, il semble que j'ai été mal informé. Nos processeurs sont réglés sur 2,6 GHz et non sur 4,6 GHz. J'ai corrigé ces informations ci-dessus.
MODIFIER:
Nous avons essayé de définir un réseau lié à cela vmwarekb et guide . Nous avons également ajouté 4 cœurs supplémentaires à la machine virtuelle. L'utilisation du processeur est restée la même.
Pour répondre à ma propre question. ASYNC_NETWORK_IO n'était pas vraiment le vrai problème. Nous avons résolu notre problème de performances en suivant ce guide pour les charges de travail sensibles à la latence:
J'ai marqué les paramètres que nous avons appliqués à notre système avec une couleur jaune ici:
Je pense que les paramètres avec le plus d'impact étaient la configuration numa et le réglage la sensibilité de latence à élevé . Ce qui à la fois requis pour allouer/réserver explicitement des cœurs de CPU physiques et RAM pour la VM.
Nous avons également ajouté plus de cœurs à la VM un besoin maintenant de mettre à niveau notre licence SQL Server de Standard à Enterprise.
Comme indiqué la dernière fois que vous avez posé cette question , votre attente principale est ASYNC_NETWORK_IO. SQL Server attend en attendant que la machine à l'autre extrémité du canal digère la prochaine ligne de résultats de requête.
J'ai obtenu cette information des résultats des statistiques d'attente de sp_Blitz (merci de les avoir collés dans):
1 - ASYNC_NETWORK_IO - 225,9 heures d'attente, 143,5 minutes de temps d'attente moyen par heure, 0,2% d'attente de signal, 2146022 tâches en attente, temps d'attente moyen de 378,9 ms.
Ne partez pas à dépanner les threads du processeur - ce n'est pas lié. Concentrez-vous sur votre type d'attente principal et sur les éléments susceptibles de provoquer ce type d'attente.
Pour résoudre ce problème davantage, exécutez sp_WhoIsActive ou sp_BlitzFirst (clause de non-responsabilité: je suis l'un des auteurs de cela) - les deux répertorieront les requêtes en cours d'exécution. Regardez la colonne d'informations sur les attentes, recherchez les requêtes en attente de ASYNC_NETWORK_IO et examinez les applications et serveurs à partir desquels elles s'exécutent.
De là, vous pouvez essayer:
- Vérifier si ces serveurs d'applications sont sous-alimentés (comme s'ils sont au maximum sur le processeur ou paginer sur le disque) et les régler
- Travailler avec les développeurs d'applications pour voir s'ils effectuent un traitement ligne par ligne sur les résultats (comme pour chaque ligne qui revient de SQL Server, l'application s'éteint et effectue un certain traitement avant de demander la ligne de résultats suivante)
- Travailler avec les développeurs d'applications pour sélectionner moins de données (comme moins de lignes ou moins de colonnes s'ils n'ont pas besoin de toutes les données - parfois, vous voyez cela lorsque les gens font accidentellement un SELECT * et ramènent plus de données que nécessaire, ou ils demandent toutes les rangées alors qu'elles n'ont vraiment besoin que des 1000 premiers)
Mise à jour avec sp_WhoIsActive - dans la capture d'écran sp_WhoIsActive que vous avez publiée, vous avez quelques requêtes en attente sur ASYNC_NETWORK_IO. Pour ceux-ci, reportez-vous aux instructions ci-dessus.
Dans le reste des requêtes, regardez la colonne "status" de sp_WhoIsActive - la majorité d'entre elles "dorment". Cela signifie qu'ils ne fonctionnent pas du tout - ils attendent que les applications à l'autre bout du canal envoient leur prochaine commande. Ils ont des transactions ouvertes (voir la colonne "open_tran_count") mais SQL Server ne peut rien faire pour accélérer une transaction en veille. Ces requêtes sont ouvertes depuis plus de quarante minutes (la première colonne de sp_WhoIsActive. Ils ne font plus rien! Vous devez obliger ces gens à valider leurs transactions et à fermer leurs connexions. Ce n'est pas un problème de réglage des performances.
Tout ce que nous voyons ici indique un scénario où nous attendons sur l'application.
Il semble que Windows signale la vitesse d'horloge de vos cœurs de processeur de 4,6 GHz à 2,6 GHz ... Je lancerais un outil comme CPU-Z pour vérifier la vitesse à laquelle ils s'exécutent, puis examiner la modification des paramètres d'alimentation dans Windows et le BIOS/OS de gestion pour désactiver les paramètres d'économie d'énergie susceptibles de limiter les cœurs à une vitesse inférieure.