Articles

SQL: SEITENLEBENSERWARTUNG

Posted by admin

Symptome: SQL hat einen Rückgang der Seitenlebenserwartung festgestellt, der zu langsameren Reaktionen führte.

Auswirkung: Mittel

Langsame SQL-Antworten beeinträchtigen die Benutzererfahrung und führen zu einer schlechten Effizienz der Vorgänge in Ihrer Organisation.

Erwartetes Verhalten:

Je länger eine Seite im Pufferpool bleiben und aus dem Speicher gelesen werden kann, desto besser ist die Systemleistung. Wir empfehlen, den Schwellenwert auf 300 Sekunden für jeweils 4 GB Buffer Pool (BP)-Speicher festzulegen.

Mögliche Ursachen für anhaltend niedrige Page Life Expectancy (PLE)

Niedrige CPU-Leistungspriorität: Mittel
Handlungsempfehlung :
Kontinuierlich hohe Auslastung in Verbindung mit niedriger PLE kann auf die Notwendigkeit eines CPU-Upgrades oder das Hinzufügen mehrerer Prozessoren hinweisen. Siehe unsere Erklärung zur CPU-Auslastung hier
Alternativ kann eine hohe CPU-Auslastung auf eine schlecht abgestimmte Anwendung oder einen schlecht abgestimmten SQL-Code hinweisen. Die Optimierung der Anwendung kann die CPU-Auslastung senken.

Unzureichende RAM-Priorität: Medium
Überprüfen Sie die Menge an Gesamt-RAM, die SQL zugewiesen wurde (wobei immer noch genügend RAM für die Betriebssystemanforderungen vorhanden ist). Vergleichen Sie das Verhältnis von SQL-Speicher zu Datenbankgröße – basierend auf unserer Erfahrung ist ein Verhältnis von Gesamt-RAM von mehr als 20% der größten Datenbank optimal.
Empfohlene Aktion :
Wenn möglich, weisen Sie SQL mehr Arbeitsspeicher zu, oder fügen Sie dem Server alternativ physischen Arbeitsspeicher hinzu und erhöhen Sie die SQL-Speicherzuweisung.

Auslagerungsdatei belegt / langsam Priorität: Niedrig
Überprüfen Sie, was sonst noch ausgeführt wird, was die Geschwindigkeit des Festplattenzugriffs möglicherweise verlangsamt. Der Pufferpool tauscht Seiten auf die Festplatte aus, wenn Speicherplatz benötigt wird. Dieser Prozess hängt stark von der Effizienz der Daten-Lese- / Schreibaktionen auf der Festplatte und von der Nachfrage ab.
Empfohlene Maßnahme :
Um die Festplatten-E/A zu beschleunigen und die Latenz zu verringern, suchen Sie die Auslagerungsdatei auf dem schnellsten verfügbaren Laufwerk (oder führen Sie ein Upgrade auf effizientere Hardware durch). Reduzieren Sie auch den Wettbewerb um diese Ressource durch andere Operationen. AimBetter Resource Monitor bietet umfassende Statistiken über den gesamten Speicherplatz, den freien Speicherplatz und die Auslagerungsdateiaktivität.

Falsche Priorität der Pufferpoolzuweisung: Low
In SQL Server werden Daten in 8 KB Seiten gespeichert. Wenn Daten für die Eingabe / Ausgabe benötigt werden, wird die Seite zuerst von der Festplatte gelesen und im Speicher gespeichert. Der zugewiesene Bereich wird als Pufferpool bezeichnet. Sobald eine Seite in den Pool geladen ist, ist der gesamte nachfolgende Zugriff sehr schnell und effizient, während die Festplatten-E / A relativ langsam ist. Dem Pufferpool sollte so viel Speicher wie möglich zugewiesen werden, ohne das Betriebssystem zu verhungern.
Handlungsempfehlung :
Weisen Sie BP den optimalen Anteil des physischen Arbeitsspeichers zu, lassen Sie jedoch genügend Arbeitsspeicher für den Betrieb des Betriebssystems. Legen Sie in der Option Maximaler Serverspeicher auf der Seite ‚Serverspeicheroptionen‘ einen Wert fest, der genügend Speicher für das Betriebssystem selbst freilässt. Wir empfehlen etwa 4 GB weniger als die Gesamtmenge des installierten Arbeitsspeichers

Mögliche Ursachen oder vorübergehend niedrige Seitenlebenserwartung (PLE)

Index fehlt oder beschädigt Priorität: Hoch
Fehlende Indizes bedeuten, dass SQL Server vorschlägt, dass Ihre Abfrage mit einem Index schneller ausgeführt werden könnte. In 99% der Fälle ist die Beschädigung der Festplatte oder des Festplattentreibers / der Firmware.
Handlungsempfehlung :
Falls ein Index fehlt, wenden Sie sich an Ihr Systemdesignteam.
Im Falle beschädigter Indizes wenden Sie sich an Ihr Speicherverwaltungsteam oder an unsere Support-Experten. Eine mögliche Abhilfe in Fällen, in denen sich die Beschädigung wiederholt, besteht darin, die Datenbank auf eine neue Hardwarekonfiguration zu klonen.

Codierungsprobleme Priorität: Niedrig
Möglicherweise aufgrund von Problemen wie ineffizienten Abfrageplänen oder falschen Codierungsstandards.
Empfohlene Aktion :
Überprüfen Sie den von SQL verwendeten Plan, um festzustellen, ob er optimal war.
Untersuchen Sie die Datenbankabfragen, um festzustellen, ob die erforderlichen Datenabfragen beschädigt oder falsch sind.
Untersuchen Sie die Codierung, um zu sehen, ob die Effizienz verbessert werden kann.

Abfragen, die den Pufferpool sättigen Priorität: Niedrig
Diese Ursachen bleiben nicht über lange Zeiträume bestehen. Hauptursachen sind:

  • abrufen großer Speicherzuweisungen
  • Verschieben einer großen Anzahl von Seiten im Speicher durch neue
  • Ändern vieler Seiten, sodass sie auf die Festplatte geleert werden müssen
  • viele gleichzeitige (oder einige sehr große) Abfragen

Empfohlene Aktion :
In Fällen, in denen sie wieder auftreten oder eine Tendenz zeigen, in der Größenordnung zu erhöhen (niedrigere PLE), untersuchen Sie die anderen möglichen Ursachen unten.

DBCC CHECKDB laufende Priorität: Niedrig
CHECKDB ist sehr ressourcenintensiv – wahrscheinlich eines der ressourcenintensivsten Dinge, die SQL Server ausführt. Die Einführung dieses Prozesses als zusätzliche E / A-Last zusätzlich zur normalen SQL Server-Last bedeutet, dass sich die Festplattenköpfe ständig bewegen.
Handlungsempfehlung :
Wir empfehlen, alle wesentlichen CHECKDB-Prozesse zu einem Zeitpunkt minimaler SQL Server-Last oder alternativ auf Sicherungskopien der Datenbanken offline auszuführen.

Index-Rebuilds laufende Priorität: Niedrig
Ein Index-Rebuild-Vorgang erstellt immer einen neuen Index, was bedeutet, dass zusätzlicher Speicherplatz erforderlich ist, um den neuen Index zu erstellen, bevor der alte gelöscht wird.
Handlungsempfehlung :
Wenn es häufig auftritt, kann es durch Änderungen im Indexierungsverfahren korrigiert werden, beispielsweise durch Umschalten auf eine Strategie, bei der die Fragmentierung jede Nacht analysiert und nur die fragmentierten Indizes verarbeitet werden. Unsere Experten-Support-Team-Berater stehen zur Verfügung, um zu analysieren und zu unterstützen.

Hintergrund

Die Metrik für die Seitenlebenserwartung misst die durchschnittliche Anzahl der Sekunden, die Seiten im Pufferpool verbleiben. Es ist eng mit der Auslagerungsdateiverwendung verwandt – siehe hier.
Für eine optimale Leistung sollten Daten aus dem Speicher und nicht von der Festplatte gelesen werden, was viel langsamer ist. SQL erreicht dies durch die Verwendung von Speicherseiten, die die zuletzt aufgerufenen Daten speichern. Für die Speicherung dieser Seiten steht ein reservierter Speicherbereich (der Pufferpool) zur Verfügung. Wenn der Pufferpool voll ist und SQL neuen Speicherplatz benötigt, tauscht der Server die älteste Seite in die Auslagerungsdatei auf der Festplatte aus und liest die neuen Daten ein. Eine Erhöhung der Anzahl von Swaps zwischen Speicher und Festplatte wirkt sich direkt auf die Leistung aus.
Anhaltend niedrige PLE-Werte sind ein zuverlässiger Indikator für den Speicherdruck von SQL Server. Dieser Druck kann auf eine hohe Nachfrage oder auf eine ineffiziente physische und logische Datenorganisation zurückzuführen sein.
Wir empfehlen, den Schwellenwert auf 300 Sekunden für jeweils 4 GB Pufferpoolspeicher (BP) auf Ihrem Server festzulegen. Dies bedeutet, dass der Server eine bestimmte Seite im Speicher (nachdem ein Prozess auf die Seite verweist) mindestens 5 Minuten lang im Pufferpool belassen sollte, bevor sie auf die Festplatte geleert wird. Wenn der Pufferpool Seiten in weniger als 300 Sekunden löscht, liegt wahrscheinlich ein Problem vor.
Je mehr Speicher Ihr Server hat, desto mehr Lese- und Schreibvorgänge kann er ausführen. Ein Mangel an Systemspeicher kann zu hohen Lese- und Schreibvorgängen auf nicht zwischengespeicherten Festplatten führen. Das Hinzufügen von Arbeitsspeicher zu Ihrem Server kann dazu beitragen, den physischen Festplattenzugriff zu verringern.

Related Post

Leave A Comment