Nicht genug Arbeitsspeicher
Dies ist sehr wahrscheinlich ein Speicherproblem, das möglicherweise durch andere Dinge verschlimmert oder ausgelöst wird, aber immer noch ein inhärentes Speicherproblem ist. Es gibt zwei andere (weniger wahrscheinliche) Möglichkeiten, die Sie zuerst überprüfen und beseitigen sollten (weil es einfach ist):
Einfach zu prüfende Möglichkeiten:
-
Möglicherweise haben Sie "Automatisches Schließen" aktiviert:Automatisches Schließen kann genau dieses Verhalten haben, es ist jedoch selten, dass es aktiviert ist. Um dies zu überprüfen, klicken Sie in SSMS mit der rechten Maustaste auf Ihre Anwendungsdatenbank, wählen Sie „Eigenschaften“ und dann den Bereich „Optionen“. Sehen Sie sich den Eintrag „Auto Close“ an und vergewissern Sie sich, dass er auf „False“ gesetzt ist. Überprüfen Sie auch tempdb.
-
SQL Agent-Aufträge können dies verursachen:Überprüfen Sie das Verlaufsprotokoll des Agenten, um festzustellen, ob während der Ereignisse ständig Aufträge ausgeführt wurden. Denken Sie daran, auch Wartungsjobs zu überprüfen, da Dinge wie die Neuerstellung von Indizes häufig als Leistungsprobleme genannt werden, während sie ausgeführt werden. Dies sind jetzt unwahrscheinliche Kandidaten, nur weil sie normalerweise nicht vom Profiler betroffen wären.
Warum es wie ein Speicherproblem aussieht:
Wenn diese nichts anzeigen, sollten Sie nach Speicherproblemen suchen. Ich vermute Speicher als Ursache in Ihrem Fall, weil:
-
Sie haben 1 GB Arbeitsspeicher:Obwohl dies technisch über dem Minimum für SQL Server liegt, liegt es weit unter der Empfehlung für SQL Server und weit unter dem, was meiner Erfahrung nach für die Produktion akzeptabel ist, selbst für einen leicht belasteten Server.
-
Sie führen IIS und SQL Server auf der gleichen Box aus:Dies ist an sich nicht empfehlenswert, zum großen Teil wegen der daraus resultierenden Konkurrenz um den Arbeitsspeicher, aber mit nur 1 GB Arbeitsspeicher führt dies zu IIS, der App, SQL Server, dem Das Betriebssystem und alle anderen Aufgaben und / oder Wartungsarbeiten kämpfen alle um sehr wenig Speicher. Die Art und Weise, wie Windows dies verwaltet, besteht darin, den aktiven Prozessen Speicher zu geben, indem es ihn aggressiv von den nicht aktiven Prozessen wegnimmt. Es kann viele Sekunden oder sogar Minuten dauern, bis ein großer Prozess wie SQL Server genügend Speicher zurückerhält, um in dieser Situation eine Anfrage vollständig bedienen zu können.
-
Profiler hat 90 % des Problems beseitigt:Dies ist ein großer Hinweis darauf, dass der Arbeitsspeicher wahrscheinlich das Problem ist, denn normalerweise haben Dinge wie Profiler genau diesen Effekt auf dieses spezielle Problem:Die Profiler-Aufgabe hält den SQL Server nur wenig bisschen aktiv die ganze Zeit. Häufig ist dies gerade genug Aktivität, um es entweder von der "Scavenger"-Liste des Betriebssystems fernzuhalten oder zumindest seine Auswirkungen etwas zu verringern.
So überprüfen Sie den Speicher als Übeltäter:
-
Schalten Sie den Profiler aus:Er hat einen Heisenberg-Effekt auf das Problem, also müssen Sie ihn ausschalten oder Sie können das Problem nicht zuverlässig erkennen.
-
Führen Sie einen Systemmonitor (perfmon.exe) von einem anderen Computer aus, der eine Remoteverbindung mit dem Leistungserfassungsdienst auf dem Computer herstellt, auf dem Ihr SQL Server und IIS ausgeführt werden. Sie können dies am einfachsten tun, indem Sie zuerst die drei Standardstatistiken entfernen (sie sind nur lokal) und dann die erforderlichen Statistiken hinzufügen (unten), aber stellen Sie sicher, dass Sie den Computernamen in der ersten Dropdown-Liste ändern, um eine Verbindung zu Ihrem SQL herzustellen Feld.
-
Senden Sie die gesammelten Daten in eine Datei, indem Sie ein "Zählerprotokoll" auf perfmon erstellen. Wenn Sie damit nicht vertraut sind, ist es wahrscheinlich am einfachsten, die Daten in einer tabulator- oder kommagetrennten Datei zu sammeln, die Sie zur Analyse mit Excel öffnen können.
-
Richten Sie Ihr Perfmon so ein, dass es in einer Datei gesammelt wird, und fügen Sie ihm die folgenden Zähler hinzu:
-- Prozessor\%Prozessorzeit[Gesamt]
-- PhysicalDisk\% Leerlaufzeit[für jede Festplatte ]
-- PhysicalDisk\Durchschn. Länge der Festplattenwarteschlange[für jede Festplatte ]
-- Speicher\Seiten/Sek.
-- Arbeitsspeicher\Seitenlesevorgänge/Sek.
-- Arbeitsspeicher\Verfügbare MBytes
-- Netzwerkschnittstelle\Bytes insgesamt/s[für jede verwendete Schnittstelle ]
-- Prozess\Prozessorzeit in %[siehe unten ]
-- Prozess\Seitenfehler/Sek. [siehe unten ]
-- Process\Working Set [siehe unten ]
-
Für die Prozessindikatoren (oben) möchten Sie den Prozess sqlserver.exe, alle IIS-Prozesse und alle stabilen Anwendungsprozesse einbeziehen. Beachten Sie, dass dies NUR für "stabile" Prozesse funktioniert. Prozesse, die bei Bedarf ständig neu erstellt werden, können auf diese Weise nicht erfasst werden, da es keine Möglichkeit gibt, sie zu spezifizieren, bevor sie existieren.
-
Führen Sie diese Sammlung während der Zeit, in der das Problem am häufigsten auftritt, in einer Datei aus. Stellen Sie das Erfassungsintervall auf etwas in der Nähe von 10-15 Sekunden ein. (Dies sammelt eine Menge Daten, aber Sie benötigen diese Auflösung, um die einzelnen Ereignisse herauszusuchen).
-
Nachdem Sie einen oder mehrere Vorfälle haben, stoppen Sie die Erfassung und öffnen Sie dann Ihre erfasste Datendatei mit Excel. Wahrscheinlich müssen Sie die Zeitstempelspalte neu formatieren, damit sie sinnvoll sichtbar ist und Stunden, Minuten und Sekunden anzeigt. Verwenden Sie Ihr IIS-Protokoll, um den genauen Zeitpunkt der Vorfälle zu ermitteln, und sehen Sie sich dann die Perfmon-Daten an, um zu sehen, was vor und nach dem Vorfall vor sich ging. Insbesondere möchten Sie sehen, ob der Arbeitssatz vorher klein und danach groß war, mit vielen Seitenfehlern dazwischen. Das ist das deutlichste Anzeichen für dieses Problem.
LÖSUNGEN:
Trennen Sie entweder IIS und SQL Server auf zwei verschiedene Boxen (bevorzugt) oder fügen Sie der Box mehr Arbeitsspeicher hinzu. Ich denke, dass 3-4 GB das Minimum sein sollten.
Was ist mit diesem seltsamen EF-Zeug?
Das Problem hier ist, dass es höchstwahrscheinlich entweder peripher ist oder nur zu Ihrem Hauptproblem beiträgt. Denken Sie daran, dass Profiler dafür gesorgt hat, dass 90 % Ihrer Vorfälle verschwinden. Was also bleibt, mag ein anderes Problem sein, oder es kann nur der extremste Erschwerer sein von dem Problem. Aufgrund seines Verhaltens würde ich vermuten, dass es entweder seinen Cache durchläuft oder es eine andere Hintergrundwartung der Anwendungsserverprozesse gibt.
