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 de RAM (110 Go de mémoire max 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 SQL Server 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!

ÉDITER:

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

• 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é des réductions de fichiers 6 fois 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 généraux - 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: Performance :

• File Growths Slow PROD77 - 2 croissances ont pris plus de 15 secondes chacune. Pensez à 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 après une corruption du stockage. Envisagez plutôt d'utiliser CHECKSUM.

Priorité 100: Performance :

• 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 - des tables sans index cluster - qui sont activement interrogés.

  • PROD77 - La base de données [PROD77] contient des tas - tables sans index cluster - qui sont activement interrogés.

Priorité 150: Performance :

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

  • 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: informationnelle :

• 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 averti 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 de 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é maximal 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: Performance :

• 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, ce qui indique que les E / S peuvent se bloquer.

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

• 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: Remboursement :

• Journal du capitaine: starder quelque chose et quelque chose ...

ÉDITER:

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.

ÉDITER:

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.

ÉDITER:

Nous avons essayé de définir un réseau lié à ce 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.

Comme indiqué la dernière fois que vous avez posé cette question , votre attente principale est ASYNC_NETWORK_IO. SQL Server attend que la machine à l'autre bout 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é: j'en suis l'un des auteurs) - les deux répertoriant les requêtes en cours d'exécution. Regardez la colonne des informations d'attente, 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 quand ils n'ont vraiment besoin que des 1000 premiers)

Mettre à 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. Elles ne font tout simplement plus rien. Vous devez obliger ces personnes à 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.

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:

Meilleures pratiques pour l'optimisation des performances des charges de travail sensibles à la latence dans les machines virtuelles vSphere

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 ont été la configuration numa et la mise en latence de sensibilité à haute . Ce qui était nécessaire pour allouer / réserver explicitement des cœurs de processeur physiques et de la RAM pour la machine virtuelle.

Nous avons également ajouté plus de cœurs à la machine virtuelle et nous devons maintenant mettre à niveau notre licence SQL Server de Standard à Enterprise.

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 à la fois 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.