Warum sind regelmäßige Neustarts erforderlich, damit meine Instanz ordnungsgemäß funktioniert?

Wir haben einen Produktions-DB-Server für SQL 2005. Alles läuft eine Weile normal, aber nach ein paar Wochen sehen wir einen bemerkenswerten Leistungsabfall. Nur durch einen Neustart von SQL Server wird die normale Leistung wiederhergestellt.

Einige Hintergrundinformationen:

• Laufen über 1200 Datenbanken (meist Einzelmandant, einige Multi-Mandant). Bevor jemand Vorträge über den Umzug zu einem Mandanten hält, gibt es triftige Gründe, diese Struktur beizubehalten.
• RAM ist 16 GB. Nach dem Neustart dauert es nicht lange, bis SQL Server wieder mit 15 GB ausgelastet ist.
• Bei aktiven DB-Verbindungen handelt es sich um ca. 80 Verbindungen - was unserer Meinung nach recht gesund ist, wenn man bedenkt, dass pro Webserver und Prozess ein Verbindungspool vorhanden ist -, sodass wir kein Problem mit Verbindungslecks haben.

Wir haben einige Dinge in Zeiten außerhalb der Stoßzeiten ausprobiert: - Führen Sie DBCC DROPCLEANBUFFERS (mit einem CHECKPOINT) aus, um den Datencache zu leeren. Dies hat keine Auswirkung und löscht auch keine RAM-Auslastung. - Führen Sie FREEPROCCACHE und FREESYSTEMCACHE aus, um Abfragepläne und den gespeicherten Prozesscache zu löschen. Keine Wirkung.

Offensichtlich ist ein Neustart von SQL Server in einer aktiven Produktionsumgebung nicht ideal. Wir vermissen etwas. Hat sonst noch jemand das durchgemacht?

UPDATE: 28. April 2012 Kämpfe immer noch gegen dieses Problem. Ich habe den Speicher für SQL Server auf 10 GB reduziert, um Konflikte mit dem Betriebssystem auszuschließen. Ich nähere mich der Eingrenzung, brauche aber Hilfe für meinen nächsten Schritt.

Folgendes habe ich nach dem Neustart von SQL Server festgestellt: Die Auslagerungsdatei liegt zwischen 12,3 GB und 12,5 GB. Es wird tagelang so bleiben. Die Gesamtzahl der Server-Threads wird zwischen 850 und 930 liegen - auch tagelang stabil und konsistent (sqlserver liegt abhängig vom Datenverkehr konstant zwischen 55 und 85).

Dann gibt es "ein Ereignis". Ich habe keine Ahnung, was das Ereignis ist, ich kann es nicht in den Protokollen sehen, und ich kann an dem Wochentag oder der Uhrzeit, an dem es passiert, nichts Konsistentes sehen, aber die gesamte Auslagerungsdatei springt auf 14.1 oder 14.2 GB, und die Threads springen zwischen 1750 und 1785.

In diesem Fall sind über 900 dieser Threads sqlserver. Also gehe ich zu sp_who2, um zu sehen, woher diese Threads kommen ... und es gibt nur die ungefähr 80 verwendeten DB-Verbindungen.

Also ... hat jemand eine Idee, wie ich herausfinden kann, wo sich die restlichen 900 Threads auf dem SQL Server befinden und was sie tun?

UPDATE: 01. Juni 2012 Wir kämpfen immer noch um das Problem. Für alle, die dies noch lesen, wurde das Problem mit dem Hochspringen der Threads behoben. Dies wurde durch eine autodatierte ComVault-Sicherungssoftware verursacht. Es wurde ein Thread erstellt, der versucht, nicht mehr vorhandene Datenbanken zu sichern (es wurde eine Liste vorheriger Datenbanken geführt), anstatt nur die aktuellen Datenbanken zu sichern.

Aber - das Problem bleibt bestehen und wir müssen jede Woche neu starten, ein paar Tage geben oder nehmen. Arbeiten Sie mit dem Rackspace-Team zusammen, um herauszufinden, ob sie Licht ins Dunkel bringen können.

Sie sagen, dass alles in Ordnung ist und nach ein paar Wochen die Leistung sinkt. (Normalerweise behaupten die Leute, dass die Leistung schnell oder zu bestimmten Zeiten oder in scheinbar zufälligen Intervallen sinkt. Dies könnte eine schlechte E / A-Leistung oder Sperren von Stürmen oder CPU-intensiven Abfragen bedeuten, die zu ungewöhnlichen Zeiten ausgeführt werden, oder einen schwergewichtigen geplanten Job oder einen Mangel an Indizierung oder schlechte Statistiken, die zu CPU-intensiven Abfragen, Festplattenlesevorgängen oder anderem Material führen.) Wochen sind ungewöhnlich.

Meine Hypothese ist, dass eine andere Anwendung auf Ihrem Server Speicher verliert. Ich habe dies mit Virensoftware (dem beliebtesten Server-Software-Schurken aller DBAs) und Überwachungssoftware von Drittanbietern gesehen. Ich würde die Speicherauslastung von SQL Server im Laufe der Zeit überprüfen und die gesamte Speicherauslastung aller anderen Anwendungen auf der Box abrufen. Wenn für die Speichernutzung von SQL Server harte Grenzwerte festgelegt sind und das Auslagern nicht zulässig ist, werden möglicherweise andere Apps ausgelagert und beanspruchen die E / A-Kapazität.

Es ist nicht schwer zu suchen. Wenn Sie die Messdaten nicht bereits auf dem Server haben, starte ich Perfmon einfach und lasse es alle 30 oder 60 Minuten eine Stichprobe abrufen. Nach einigen Tagen kann es vorkommen, dass sich die Speichernutzung anderer Anwendungen nach oben schleicht.

Gibt es Fehlermeldungen im SQL Server-Protokoll, die besagen, dass "wesentliche Teile des SQL Servers ausgelagert wurden"? Das wäre auch ein großer Hinweis.

Lassen Sie mich Ihnen gratulieren, dass Sie 1200 DBs auf einer einzelnen Instanz von SQL Server mit nur 16 GB RAM ausführen können und nach ein paar Wochen reibungslosen Betriebs nur solche Probleme haben. Eine schöne Geschichte, die man im örtlichen PASS-Kapitel erzählen kann.

Jetzt zur Problembehandlung: Ihr RAM ist 16 GB für SQL und Betriebssystem. Ich gehe davon aus, dass Ihre maximale Speichereinstellung bei 15 GB oder max liegt. Dies kann dazu führen, dass der Pufferpool den gesamten Speicher belegt und das Betriebssystem verschluckt. Sie sagen, dass das Aufräumen des Pufferpools und der Caches keine Unterschiede aufweist und Ihr PLE über 300 liegt. Dies spricht für Engpässe im Speicher. Wie ist die CPU und IO auf dem Server (Angaben / Statistiken)?

Ausführen select * from sys.dm_exec_request where session_id>50 and session_id<>@@spidund welche Ressourcenkonflikte werden angezeigt (wait_type, wait_time, last_wait_type, wait_resource).

1200 Datenbanken, ein Betriebssystem und möglicherweise andere Dinge? Ja, ich denke, der Server selbst wird mehr als 1 GB RAM benötigen, um zu funktionieren, besonders wenn man bedenkt, dass wenn man 15 GB als maximale Speichereinstellung für SQL Server festlegt, er immer noch zusätzlichen Speicher außerhalb dieser 15 GB für Threads benötigt.

Ich würde SQL Server auf 14 GB reduzieren, um dem Server mehr Freiraum zu geben.

Ein Beispiel in "Professional SQL Server 2008-Interna und Fehlerbehebung" für Speicherplatz auf einem SQL Server 2008 x64-System mit einem Sicherungsdienstprogramm eines Drittanbieters mit 16 GB RAM:

• 2 GB für Windows
• 1 GB für Worker-Threads
• 1 GB für MPAs usw.
• 1 GB für das Sicherungsprogramm
• 11 GB für SQL Server

In diesem Buch wird gezeigt, wie Sie die maximale Anzahl von Threads ermitteln und berechnen können, wie viel Speicher sie belegen. Führen Sie dies aus (ändern Sie den Servertyp entsprechend Ihrem Server), um herauszufinden, wie viel Speicher Ihre Threads benötigen.

declare @servertype int

set @servertype=1
/*
1: x86 (32-bit)
2: x64 (64-bit)
3: IA64

*/

select max_workers_count *
    (
        case @servertype when 1 then .5
            when 2 then 2
            when 3 then 4
            else .5
        end
    )
from sys.dm_os_sys_info

Wenn der Datenbankspeicher gleichmäßig auf alle Datenbanken verteilt ist, stehen nur 12,8 Megabyte für jede Datenbank (15 * 1024) / 1200 = 12,8 zur Verfügung. Du brauchst mehr Speicher.

Sie müssen untersuchen, warum die Leistung nachlässt. Sehen Sie Sperren, Blockieren usw.? Wie sehen die Wartestatistiken aus?

Die DBCC-Befehle löschen nur die Speicherpuffer und geben den Speicher nicht an das Betriebssystem zurück.

Wissen Sie, dass SQL Server tatsächlich den Speicher belegt? Ich würde vorschlagen, die Perfmon-Sitzung einzurichten oder nach einem Neustart mit dem Sammeln von DMV-Informationen zu beginnen, um herauszufinden, was SQL Server tut und woran es arbeitet. Beachten Sie auch, ob Benutzer während der Erfassungszeit mehr als die normale Arbeit verrichten (z. B. Verarbeitung zum Monatsende usw.). Führen Sie SSRS, SSIS oder SSAS auf demselben Server aus?

Sie haben 1200 Datenbanken auf dem System. Was ist die größte Datenbank, die Sie haben?