Pas assez de mémoire
Il s'agit très probablement d'un problème de mémoire, peut-être aggravé ou déclenché par d'autres choses, mais toujours intrinsèquement un problème de mémoire. il y a deux autres possibilités (moins probables), que vous devriez d'abord vérifier et éliminer (car c'est facile à faire) :
Possibilités faciles à vérifier :
-
Vous avez peut-être activé la "fermeture automatique" :la fermeture automatique peut avoir exactement ce comportement, mais il est rare qu'elle soit activée. Pour vérifier cela, dans SSMS faites un clic droit sur votre base de données d'application, sélectionnez "Propriétés", puis sélectionnez le volet "Options". Regardez l'entrée "Fermeture automatique" et assurez-vous qu'elle est définie sur Faux. Vérifiez également tempdb.
-
Les travaux de l'agent SQL peuvent en être la cause :consultez le journal d'historique de l'agent pour voir s'il y a eu des travaux en cours d'exécution pendant les événements. N'oubliez pas de vérifier également les tâches de maintenance, car des éléments tels que la reconstruction des index sont fréquemment cités comme des problèmes de performances pendant leur exécution. Ce sont des candidats peu probables maintenant, uniquement parce qu'ils ne seraient normalement pas affectés par le profileur.
Pourquoi cela ressemble à un problème de mémoire :
Si ceux-ci ne montrent rien, alors vous devriez vérifier les problèmes de mémoire. Je soupçonne la mémoire d'être la cause dans votre cas parce que :
-
Vous disposez de 1 Go de mémoire :bien que cela soit techniquement supérieur au minimum pour SQL Server, il est bien en-dessous de ce qui est recommandé pour SQL Server, et bien en-dessous de ce qui, d'après mon expérience, est acceptable pour la production, même pour un serveur peu chargé.
-
Vous exécutez IIS et SQL Server sur le même boîtier :ce n'est pas recommandé en soi, en grande partie à cause de la contention de mémoire qui en résulte, mais avec seulement 1 Go de mémoire, il en résulte IIS, l'application, SQL Server, le Le système d'exploitation et toutes les autres tâches et/ou maintenance se battent tous pour très peu de mémoire. La façon dont Windows gère cela est de donner de la mémoire aux processus actifs en la retirant agressivement des processus non actifs. Cela peut prendre plusieurs secondes, voire plusieurs minutes, à un processus volumineux tel que SQL Server pour récupérer suffisamment de mémoire pour pouvoir traiter complètement une requête dans cette situation.
-
Le profileur a fait disparaître 90 % du problème :c'est un indice important que la mémoire est probablement le problème, car généralement, des choses comme le profileur ont exactement cet effet sur ce problème particulier :la tâche du profileur garde le serveur SQL juste un peu peu actif tout le temps. Souvent, c'est juste assez d'activité pour le garder hors de la liste des "récupérateurs" du système d'exploitation, ou au moins pour réduire quelque peu son impact.
Comment vérifier la mémoire en tant que coupable :
-
Éteignez le profileur :il a un effet Heisenberg sur le problème, vous devez donc l'éteindre ou vous ne pourrez pas voir le problème de manière fiable.
-
Exécutez un moniteur système (perfmon.exe) à partir d'un autre boîtier, qui se connecte à distance au service de collecte de performances sur le boîtier sur lequel votre serveur SQL et IIS sont exécutés. vous pouvez le faire plus facilement en supprimant d'abord les trois statistiques par défaut (elles sont locales uniquement), puis en ajoutant les statistiques nécessaires (ci-dessous), mais assurez-vous de changer le nom de l'ordinateur dans le premier menu déroulant pour vous connecter à votre SQL boîte.
-
Envoyez les données collectées dans un fichier en créant un "Counter Log" sur perfmon. Si vous n'êtes pas familier avec cela, la chose la plus simple à faire est probablement de collecter les données dans un fichier séparé par des onglets ou des virgules que vous pouvez ouvrir avec Excel pour les analyser.
-
Configurez votre perfmon pour qu'il collecte dans un fichier et ajoutez-y les compteurs suivants :
-- Processeur\%Temps du processeur[Total]
-- PhysicalDisk\% Idle Time[pour chaque disque ]
-- Disque physique\Moy. Longueur de la file d'attente du disque[pour chaque disque ]
-- Mémoire\Pages/sec
-- Mémoire\Lectures de pages/s
-- Mémoire\Mo disponibles
-- Network Interface\Bytes Total/sec[pour chaque interface utilisée ]
-- Process\% Processor Time[voir ci-dessous ]
-- Process\Page Faults/sec[voir ci-dessous ]
-- Process\Working Set [voir ci-dessous ]
-
Pour les compteurs de processus (ci-dessus), vous souhaitez inclure le processus sqlserver.exe, tous les processus IIS et tous les processus d'application stables. Notez que cela fonctionnera UNIQUEMENT pour les processus "stables". Les processus qui sont continuellement recréés selon les besoins ne peuvent pas être capturés de cette façon car il n'y a aucun moyen de les spécifier avant qu'ils n'existent.
-
Exécutez cette collecte dans un fichier pendant la période où le problème se produit le plus fréquemment. Réglez l'intervalle de collecte sur quelque chose de proche de 10-15 secondes. (cela collecte beaucoup de données, mais vous aurez besoin de cette résolution pour sélectionner les événements distincts).
-
Après un ou plusieurs incidents, arrêtez la collecte puis ouvrez votre fichier de données collectées avec Excel. Vous devrez probablement reformater la colonne d'horodatage pour qu'elle soit utilement visible et affiche les heures, les minutes et les secondes. Utilisez votre journal IIS pour trouver l'heure exacte des incidents, puis examinez les données perfmon pour voir ce qui se passait avant et après l'incident. En particulier, vous voulez voir si son ensemble de travail était petit avant et grand après, avec beaucoup de défauts de page entre les deux. C'est le signe le plus clair de ce problème.
SOLUTION :
Séparez IIS et SQL Server sur deux boîtes différentes (de préférence) ou ajoutez plus de mémoire à la boîte. Je pense que 3-4 Go devrait être un minimum.
Qu'en est-il de ce truc EF bizarre ?
Le problème ici est qu'il est très probablement soit périphérique, soit seulement contributif à votre problème principal. N'oubliez pas que Profiler a fait disparaître 90 % de vos incidents, donc ce qui reste, peut être un problème différent, ou ce n'est peut-être que l'aggravateur le plus extrême du problème. En raison de son comportement, je suppose qu'il est soit en train de faire un cycle de son cache, soit qu'il existe une autre maintenance en arrière-plan des processus du serveur d'applications.
