SQL Server arbeitet langsam

Ich habe einen Microsoft SQL Server, der auf einem IBM Server mit 10 Kernen und 64 GB RAM ausgeführt wird.

Ich habe 100 bis 300 Benutzer, die gleichzeitig am Server arbeiten.

Benutzer beschweren sich über die Langsamkeit der Anwendung. Ich habe den Server überprüft und festgestellt, dass die CPU-Auslastung 6%, die RAM-Auslastung 4 GB und die Netzwerkauslastung bis zu 1 Mbit / s beträgt. Ich habe eine 4-Mbit / s-Standleitung.

Ich habe versucht , andere Informationen auf dem Server zu sammeln , wie Blockingund Wait Statistics:

Geben Sie hier die Bildbeschreibung ein

Die durchschnittliche Wartezeit für Ressourcen beträgt 40 Sekunden.

Ich kann die Ursache nicht interpretieren. Kann jemand einen Weg vorschlagen, um dies zu lösen?

Wenn weitere Informationen erforderlich sind, kann ich diese bereitstellen.

BEARBEITEN:

Wie vorgeschlagen habe ich die folgenden Elemente hinzugefügt:

Lebenserwartung der Seite 3

Geben Sie hier die Bildbeschreibung ein

E / A-Statistik Schnappschuss

Geben Sie hier die Bildbeschreibung ein

Warten Sie Statistiken

Geben Sie hier die Bildbeschreibung ein

Serverinformation

Geben Sie hier die Bildbeschreibung ein

Speicherstatus

Geben Sie hier die Bildbeschreibung ein

Abfrageausführungsliste

Geben Sie hier die Bildbeschreibung ein

sql-server sql-server-2008 performance

— Amritpal Singh
quelle

Antworten:

Nach den Diskussionen im Chat haben wir Folgendes festgestellt:

32-Bit-Enterprise-SQL-Server.
3,5 GB verwendeter Speicher (kein AWE / PAE).
2,1 GB Datenbank mit 1,3 GB Pufferpool.
Seitenlebenserwartung von 3 Sekunden.

Vorgeschlagene Korrekturen sind:

AWE / PAE als schnelle Lösung, damit die Datenbank in den Speicher passt.
Untersuchen Sie die häufig aufgerufenen, höchsten identifizierten E / A-Abfragen.
Erwägen Sie eine Neuerstellung auf 64 Bit.

— Mark Storey-Smith
quelle

Ich denke, das Hauptproblem ist, dass SQL Server nicht den gesamten Arbeitsspeicher verwendet (32-Bit-Fenster?). Sie können hier schauen . Sie sollten sicherstellen, dass der SQL Server viel mehr als 4 GB RAM verwendet (in Ihrem Fall bis zu 60 GB ( Empfehlungen )).

Nachdem Sie den Server für die Verwendung von RAM aktiviert haben und dies immer noch nicht ausreicht, können Sie wahrscheinlich einige (oder alle) der folgenden Schritte ausführen:

Tempdb optimieren (Dateispeicherort = unterschiedliche Festplatten- / Dateizahl = CPU-Kerne / 2)
Protokolldateien optimieren (separate Festplatte)
Verwenden Sie schreibgeschützte Dateigruppen (weniger Sperren).
Abhängig von den Datenträgern haben Sie mehr Dateien pro Dateigruppe erstellt und auf separaten Datenträgern abgelegt
Wenn dies das OLTP-System ist, setzen Sie Max. Parallelitätsgrad = 1

Seien Sie bei allen Servereinstellungen vorsichtig und überlegen Sie zweimal, bevor Sie sie anwenden.

— Jānis
quelle

Der letzte Rat ist eigentlich ein Nicht-Rat. Wer hat gesagt, dass Parallelität schlecht ist und deaktiviert werden muss?!

— Marian

@Marian Paralelismus nicht schlecht an sich. Es gibt jedoch bestimmte Situationen, in denen die Konfiguration von MAXDOP auf 1 sehr hilfreich ist. Von Frage habe ich viele CXPACKET-Wartezeiten gesehen, so dass ich misstrauisch gegenüber dieser Einstellung bin.

— Jānis

@ Jãnis, Große cxpacket-Wartezeiten in Kombination mit hohem pageiolatch_xx können auf große oder viele Tabellen- / Clustered-Index-Scans hinweisen. in diesem Fall brauchbare Erklärung. Seien Sie vorsichtig, die meiste Zeit, in der Cxpackets wartet, verbirgt sich die wahre Ursache des Problems.

— Edward Dortland

@ Jānis: Genau davor hatte ich Angst. Viele CXPacket-Wartezeiten sind nicht so schlimm, wie es sich anhört :-). Normalerweise sollten Sie diesen Wartetyp ignorieren, es sei denn, es liegt eine Situation wie die folgende vor: Parallele Parallelität : D. Einige Infos: Hände weg von Maxdop , Beeil dich und warte , hör auf zu warten .

— Marian