Augmentation des attentes pendant le point de contrôle après la mise à niveau vers un meilleur stockage

Lorsque nous avons migré d'une baie 100% plus ancienne vers une baie 100% plus récente (fournisseur différent mais bien établi), nous avons commencé à voir les attentes augmenter dans SQL Sentry lors des points de contrôle.

Version: SQL Server 2012 Sp4

Sur notre ancien stockage, nos attentes étaient d'environ 2k avec des "pointes" à 2500 pendant un point de contrôle, avec le nouveau stockage, les pointes sont généralement de 10k avec des pics proches de 50k. La sentinelle nous pointe davantage vers les PAGEIOLATCHwatis. En faisant notre propre analyse, cela semble être une combinaison d' PAGEIOLATCH and PAGELATCHattentes. En utilisant Perfmon, nous pouvons généralement dire que plus nous vérifions de pages, plus nous attendons, mais nous ne vidons que 125 Mo pendant le point de contrôle. Notre charge de travail est principalement écrite (inserts / mises à jour principalement).

Le fournisseur de stockage nous a prouvé que la baie à connexion directe Fibre Channel répond sous 1 ms pendant ces événements de point de contrôle. Le HBA confirme également les numéros de la baie. Nous ne pensons pas non plus que ce soit un problème de mise en file d'attente HBA, car la profondeur de la file d'attente n'a jamais été supérieure à 8. Nous avons également essayé un HBA plus récent, en changeant le ZIO, l'accélération d'exécution et les paramètres de profondeur de file d'attente en vain. Nous avons également augmenté la mémoire du serveur de 500 Go à 1 To sans changement. Au cours du processus de point de contrôle, nous voyons 2 à 4 cœurs individuels (sur 16) atteindre 100%, mais le CPU global est d'environ 20%. Le BIOS est également configuré pour des performances élevées. Cependant, il est intéressant de noter que les processeurs sont généralement dans un état de sommeil C2 même si nous l'avons désactivé, nous recherchons donc toujours pourquoi l'état de sommeil dépasse C1.

Nous pouvons voir que presque toutes les attentes se trouvent sur des pages de données avec un PFS occasionnel de type page DCM. Les attentes se trouvent dans les bases de données utilisateur, pas dans tempdb. Nous voyons également que les attentes sont sur plusieurs pages de données, avec certains SPID en attente sur la même page. La conception de la base de données comporte quelques points chauds d'insertion, mais la même conception était en place avec l'ancien stockage.

En exécutant une boucle de cette requête 100 fois, nous avons pu détecter le nombre de SPID en attente sur le disque par rapport à la mémoire

SELECT
    [owt].[wait_type], count(*) as waitcount
FROM sys.dm_os_waiting_tasks [owt]
WHERE [owt].[wait_type] LIKE 'PAGE%'
group by [owt].[wait_type]
order by 1
GO 100

La "bonne" chose est que nous pouvons facilement reproduire le problème dans notre environnement de performances qui a le même tableau de modèles et des spécifications de serveur similaires. J'apprécierais toute réflexion sur où chercher ou comment réduire le problème. En ce moment, nos prochains tests incluent: un nouveau serveur avec une carte mère plus récente et plus de CPU; désactivation du serveur de données SIOS (même si cela était en place avec l'ancien stockage); marque HBA différente.

exec sp_Blitz @outputtype = 'markdown'

Priorité 5: Fiabilité : - Modules tiers dangereux - Sophos Limited - Protection contre le dépassement de tampon Sophos - SOPHOS ~ 2.DLL - un module tiers dangereux présumé est installé.

Priorité 200: Information : - Nœud de cluster - Il s'agit d'un nœud dans un cluster. - TraceFlag On - L'indicateur de trace 1117 est activé globalement. - L'indicateur de trace 1118 est activé globalement. - L'indicateur de trace 3226 est activé globalement.

Priorité 200: Licence : - Fonctions Enterprise Edition en cours d'utilisation * xxxxx - La base de données [xxxxxx] utilise la compression. Si cette base de données est restaurée sur un serveur Standard Edition, la restauration échouera sur les versions antérieures à 2016 SP1. * xxxxx - La base de données [xxxxxx] utilise le partitionnement. Si cette base de données est restaurée sur un serveur Standard Edition, la restauration échouera sur les versions antérieures à 2016 SP1.

Priorité 240: Statistiques d'attente : - Aucune attente significative détectée - Ce serveur est peut-être simplement inactif ou quelqu'un a peut-être effacé les statistiques d'attente récemment.

Priorité 250: Informations sur le serveur: - Matériel - Processeurs logiques: 16. Mémoire physique: 512 Go. - Matériel - Configuration NUMA - Noeud: 0 État: Planificateurs en ligne en ligne: 8 Planificateurs hors ligne: 0 Groupe de processeurs: 0 Noeud de mémoire: 0 Mémoire VAS réservée GB: 1177 - Noeud: 1 État: Planificateurs en ligne en ligne: 8 Planificateurs hors ligne: 0 Processeur Groupe: 0 Noeud de mémoire: 1 Mémoire VAS réservée Go: 0 - Plan d'alimentation - Votre serveur possède des processeurs à 3,50 GHz et est en mode d'alimentation haute performance - Dernier redémarrage du serveur - 4 juillet 2018 04h56 - Dernier redémarrage du serveur SQL - 5 juillet 2018 5:11 AM - Service SQL Server - Version: 11.0.7462.6. Niveau de patch: SP4. Edition: Enterprise Edition (64 bits). Groupes de disponibilité activés: 1. Statut du gestionnaire de groupes de disponibilité: 1 - Serveur virtuel - Type: (HYPERVISOR) - Version Windows - Vous utilisez une version assez moderne de Windows: ère Server 2012R2, version 6.3

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. - Sauvegarde par défaut de la compression - Cette option sp_configure a été modifiée. Sa valeur par défaut est 0 et elle a été définie sur 1. - seuil (s) de processus bloqué (s) - Cette option sp_configure a été modifiée. Sa valeur par défaut est 0 et elle a été définie sur 20. - seuil de coût pour le parallélisme - Cette option sp_configure a été modifiée. Sa valeur par défaut est 5 et elle a été définie sur 30. - Database Mail XPs - 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 8. - 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 496640. - 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 8196. - Optimiser pour les charges de travail ad hoc - Cette option sp_configure a été modifiée. Sa valeur par défaut est 0 et elle a été définie sur 1. - accès à distance - Cette option sp_configure a été modifiée. Sa valeur par défaut est 1 et elle a été définie sur 0. - 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. - Rechercher les processus de démarrage - Cette option sp_configure a été modifiée. Sa valeur par défaut est 0 et elle a été définie sur 1. - afficher les options avancées - Cette option sp_configure a été modifiée. Sa valeur par défaut est 0 et elle a été définie sur 1. - xp_cmdshell - Cette option sp_configure a été modifiée.

Hmm. Vous montrez des spids en attente pendant le point de contrôle, mais pas combien de temps d'attente en moyenne / dans l'ensemble (ce qui, honnêtement, serait tout ce qui m'importe). Faites une analyse différentielle des statistiques d'attente pour voir si la durée est préoccupante. De plus, quelles sont exactement les deux attentes dans votre graphique? Si vous obtenez beaucoup d'attentes d'allocation de mémoire avec 1 To de RAM en jeu, nous devons avoir une discussion différente. :-RÉ

La vitesse d'écriture de 125 Mo pendant le point de contrôle: est-ce que le point de contrôle JUST écrit ou TOUT? Dans les deux cas, il semble faible pour le stockage 100% flash. Avez-vous évalué ledit stockage pour différents modèles d'écriture et si oui, quels nombres avez-vous obtenus?

Nous ne savons pas pourquoi le comportement de notre serveur SQL a changé (et nous avons la preuve que cela s'est produit avant le commutateur de stockage), mais l'activation des points de contrôle indirects pour les bases de données utilisateur a résolu le problème pour nous.