Wichtige Leistungsprobleme auf unserem SQL Server für die Produktion. Wie würde ich das beheben?

Diese Frage ist im Grunde eine Folgefrage zu dieser Frage:
Seltsames Leistungsproblem mit SQL Server 2016

Wir sind jetzt mit diesem System produktiv geworden. Obwohl diesem SQL Server seit meinem letzten Beitrag eine weitere Anwendungsdatenbank hinzugefügt wurde.

Dies sind die Systemstatistiken:

• 128 GB RAM (maximal 110 GB Speicher für SQL Server)
• 4 Kerne bei 2,6 GHz
• 10 GBit Netzwerkverbindung
• Der gesamte Speicher ist SSD-basiert
• Programmdateien, Protokolldateien, Datenbankdateien und Tempdb befinden sich auf separaten Partitionen des Servers
• Windows Server 2012 R2
• VMware-Version HPE-ESXi-6.0.0-Update3-iso-600.9.7.0.17
• VMware Tools Version 10.0.9, Build 3917699
• Microsoft SQL Server 2016 (SP1) (KB3182545) - 13.0.4001.0 (X64) 28. Oktober 2016 18:17:30 Copyright (c) Microsoft Corporation Standard Edition (64-Bit) unter Windows Server 2012 R2 Standard 6.3 (Build 9600 :) (Hypervisor)

Unser System hat jetzt große Leistungsprobleme. Sehr hohe CPU-Auslastung und Thread-Anzahl:

Warten Sie Statistiken des Aktivitätsmonitors (ich weiß, dass es nicht sehr zuverlässig ist)

Ergebnisse von sp_blitzfirst:

Ergebnisse von sp_configure:

Erweiterte Servereinstellungen (leider nur auf Deutsch)

Die MAXDOP-Einstellung wurde von mir geändert.

Mir ist bewusst, dass dies wahrscheinlich kein Problem mit dem SQL Server selbst ist . Es ist wahrscheinlich ein Problem mit der Virtualisierung (VMware), dem Netzwerk (ich habe dies bereits getestet) oder der Anwendung selbst. Ich möchte es nur noch weiter festnageln.

Würde eine hohe ASYNC_NETWORK_IO zu einer hohen Thread-Anzahl für den SQL Server-Prozess führen? Ich würde mir vorstellen, dass es viele Arbeiter beschäftigt, weil Threads nicht geschlossen werden können. Ist das richtig?

Ich werde alle zusätzlichen Informationen zur Verfügung stellen, die Sie benötigen. Danke im Voraus für deine Unterstützung!

BEARBEITEN:

Ergebnis von sp_Blitz @OutputType = ‘markdown’, @CheckServerInfo = 1

Priorität 1: Sicherung :

• Sichern auf demselben Laufwerk, auf dem sich Datenbanken befinden - 5 Sicherungen auf Laufwerk E: \ in den letzten zwei Wochen, auf denen auch Datenbankdateien gespeichert sind. Dies stellt ein ernstes Risiko dar, wenn dieses Array ausfällt.

Priorität 1: Zuverlässigkeit :

• Letzte gute DBCC CHECKDB über 2 Wochen alt

  • babtec_prod - Letzte erfolgreiche CHECKDB: 2017-08-20 00: 01: 01.513

  • D3PR - Letzte erfolgreiche CHECKDB: nie.

  • DEMO77 - Letzter erfolgreicher CHECKDB: 2016-02-23 20: 31: 38.590

  • FINP - Letzte erfolgreiche CHECKDB: 2017-04-23 22: 01: 19.133

  • GridVis_EnMs - Letzte erfolgreiche CHECKDB: 2017-05-18 22: 10: 48.120

  • master - Letzte erfolgreiche CHECKDB: nie.

  • Modell-

  • msdb

  • PROD77 - Letzte erfolgreiche CHECKDB: 2016-02-23 21: 33: 24.343

Priorität 10: Leistung :

• Abfragespeicher deaktiviert - Die neue SQL Server 2016-Abfragespeicherfunktion wurde in dieser Datenbank nicht aktiviert.

  • babtec_prod

  • D3PR

  • DEMO77

  • FINP

  • GridVis_EnMs

Priorität 50: DBCC-Ereignisse :

• DBCC DROPCLEANBUFFERS - Der Benutzer schorsch hat DBCC DROPCLEANBUFFERS zwischen dem 21. September 2017, 11:57 Uhr und dem 21. September 2017, 11:57 Uhr 1 Mal ausgeführt. Wenn es sich um eine Produktionsbox handelt, müssen Sie wissen, dass Sie in diesem Fall alle Daten aus dem Speicher löschen. Was für ein Monster würde das tun?

• DBCC SHRINK% - Der Benutzer schorsch hat zwischen dem 21. September 2017, 23:51 Uhr und dem 4. Oktober 2017, 9:02 Uhr 6-mal Dateischrumpfungen ausgeführt. Versuchen sie also, Korruption zu beheben oder Korruption zu verursachen?

• Gesamtveranstaltungen - 287 DBCC-Veranstaltungen fanden zwischen dem 19. September 2017 um 13:40 Uhr und dem 4. Oktober 2017 um 15:20 Uhr statt. Dies schließt CHECKDB und andere normalerweise gutartige DBCC-Ereignisse nicht ein.

Priorität 50: Leistung :

• Dateiwachstum langsam PROD77 - 2 Wachstum dauerte jeweils mehr als 15 Sekunden. Stellen Sie das automatische Wachstum der Datei auf ein kleineres Inkrement ein.

Priorität 50: Zuverlässigkeit :

• Seitenüberprüfung nicht optimal babtec_prod - Die Datenbank [babtec_prod] verfügt über TORN_PAGE_DETECTION zur Seitenüberprüfung. SQL Server hat möglicherweise Schwierigkeiten, Speicherbeschädigungen zu erkennen und wiederherzustellen. Verwenden Sie stattdessen CHECKSUM.

Priorität 100: Leistung :

• Viele Pläne für eine Abfrage - 3576 Pläne sind für eine einzelne Abfrage im Plan-Cache vorhanden - was bedeutet, dass wir wahrscheinlich Probleme mit der Parametrisierung haben.

Priorität 110: Leistung :

• Aktive Tabellen ohne Clustered-Indizes

  • babtec_prod - Die Datenbank [babtec_prod] enthält Heaps - Tabellen ohne Clustered-Index -, die aktiv abgefragt werden.

  • D3PR - Die [D3PR] -Datenbank enthält Heaps - Tabellen ohne Clustered-Index -, die aktiv abgefragt werden.

  • DEMO77 - Die [DEMO77] -Datenbank enthält Heaps - Tabellen ohne Clustered-Index -, die aktiv abgefragt werden.

  • FINP - Die [FINP] -Datenbank enthält Heaps - Tabellen ohne Clustered-Index - die aktiv abgefragt werden.

  • GridVis_EnMs - Die Datenbank [GridVis_EnMs] enthält Heaps - Tabellen ohne Clustered-Index -, die aktiv abgefragt werden.

  • PROD77 - Die [PROD77] -Datenbank enthält Heaps - Tabellen ohne Clustered-Index -, die aktiv abgefragt werden.

Priorität 150: Leistung :

• Fremdschlüssel nicht vertrauenswürdig

  • babtec_prod - Die Datenbank [babtec_prod] enthält Fremdschlüssel, die wahrscheinlich deaktiviert wurden, Daten wurden geändert und der Schlüssel wurde dann wieder aktiviert. Das einfache Aktivieren des Schlüssels reicht für den Optimierer nicht aus, um diesen Schlüssel zu verwenden. Wir müssen die Tabelle mit dem Parameter WITH CHECK CHECK CONSTRAINT ändern.

  • D3PR - Die [D3PR] -Datenbank enthält Fremdschlüssel, die wahrscheinlich deaktiviert wurden, Daten wurden geändert und dann wurde der Schlüssel wieder aktiviert. Das einfache Aktivieren des Schlüssels reicht für den Optimierer nicht aus, um diesen Schlüssel zu verwenden. Wir müssen die Tabelle mit dem Parameter WITH CHECK CHECK CONSTRAINT ändern.

• Inaktive Tabellen ohne Clustered-Indizes

  • D3PR - Die [D3PR] -Datenbank enthält Heaps - Tabellen ohne Clustered-Index -, die seit dem letzten Neustart nicht abgefragt wurden. Dies können Sicherungstabellen sein, die unachtsam zurückgelassen wurden.

  • GridVis_EnMs - Die Datenbank [GridVis_EnMs] enthält Heaps - Tabellen ohne Clustered-Index -, die seit dem letzten Neustart nicht abgefragt wurden. Dies können Sicherungstabellen sein, die unachtsam zurückgelassen wurden.

• Trigger in Tabellen babtec_prod - Die Datenbank [babtec_prod] enthält 26 Trigger.

Priorität 170: Dateikonfiguration :

• Systemdatenbank auf Laufwerk C.

  • master - Die Master-Datenbank verfügt über eine Datei auf dem Laufwerk C. Wenn Sie Systemdatenbanken auf das Laufwerk C stellen, besteht die Gefahr, dass der Server abstürzt, wenn nicht genügend Speicherplatz zur Verfügung steht.

  • Modell - Die Modelldatenbank verfügt über eine Datei auf dem Laufwerk C. Wenn Sie Systemdatenbanken auf das Laufwerk C stellen, besteht die Gefahr, dass der Server abstürzt, wenn nicht genügend Speicherplatz zur Verfügung steht.

  • msdb - Die msdb-Datenbank enthält eine Datei auf dem Laufwerk C. Wenn Sie Systemdatenbanken auf das Laufwerk C stellen, besteht die Gefahr, dass der Server abstürzt, wenn nicht genügend Speicherplatz zur Verfügung steht.

Priorität 170: Zuverlässigkeit :

• Max. Eingestellte Dateigröße

  • D3PR - Die [D3PR] -Datenbankdatei d3_data_01 hat eine maximale Dateigröße von 61440 MB. Wenn der Speicherplatz knapp wird, funktioniert die Datenbank nicht mehr, obwohl möglicherweise Speicherplatz verfügbar ist.

  • D3PR - Die [D3PR] -Datenbankdatei d3_data_idx_01 hat eine maximale Dateigröße von 61440 MB. Wenn der Speicherplatz knapp wird, funktioniert die Datenbank nicht mehr, obwohl möglicherweise Speicherplatz verfügbar ist.

  • D3PR - Die [D3PR] -Datenbankdatei d3_firm_01 hat eine maximale Dateigröße von 61440 MB. Wenn der Speicherplatz knapp wird, funktioniert die Datenbank nicht mehr, obwohl möglicherweise Speicherplatz verfügbar ist.

  • D3PR - Die [D3PR] -Datenbankdatei d3_firm_idx_01 hat eine maximale Dateigröße von 61440 MB. Wenn der Speicherplatz knapp wird, funktioniert die Datenbank nicht mehr, obwohl möglicherweise Speicherplatz verfügbar ist.

  • D3PR - Die [D3PR] -Datenbankdatei d3_log_01 hat eine maximale Dateigröße von 61440 MB. Wenn der Speicherplatz knapp wird, funktioniert die Datenbank nicht mehr, obwohl möglicherweise Speicherplatz verfügbar ist.

  • D3PR - Die [D3PR] -Datenbankdatei d3_phys_01 hat eine maximale Dateigröße von 61440 MB. Wenn der Speicherplatz knapp wird, funktioniert die Datenbank nicht mehr, obwohl möglicherweise Speicherplatz verfügbar ist.

  • D3PR - Die [D3PR] -Datenbankdatei d3_phys_idx_01 hat eine maximale Dateigröße von 61440 MB. Wenn der Speicherplatz knapp wird, funktioniert die Datenbank nicht mehr, obwohl möglicherweise Speicherplatz verfügbar ist.

  • D3PR - Die [D3PR] -Datenbankdatei d3_sys_01 hat eine maximale Dateigröße von 20480 MB. Wenn der Speicherplatz knapp wird, funktioniert die Datenbank nicht mehr, obwohl möglicherweise Speicherplatz verfügbar ist.

  • D3PR - Die [D3PR] -Datenbankdatei d3_usr_01 hat eine maximale Dateigröße von 20480 MB. Wenn der Speicherplatz knapp wird, funktioniert die Datenbank nicht mehr, obwohl möglicherweise Speicherplatz verfügbar ist.

  • D3PR - Die [D3PR] -Datenbankdatei d3_wort_01 hat eine maximale Dateigröße von 20480 MB. Wenn der Speicherplatz knapp wird, funktioniert die Datenbank nicht mehr, obwohl möglicherweise Speicherplatz verfügbar ist.

  • D3PR - Die [D3PR] -Datenbankdatei d3_wort_idx_01 hat eine maximale Dateigröße von 20480 MB. Wenn der Speicherplatz knapp wird, funktioniert die Datenbank nicht mehr, obwohl möglicherweise Speicherplatz verfügbar ist.

Priorität 200: Information :

• Standardeinstellung für Sicherungskomprimierung deaktiviert - Vor kurzem wurden nicht komprimierte vollständige Sicherungen durchgeführt, und die Sicherungskomprimierung ist auf Serverebene nicht aktiviert. Die Sicherungskomprimierung ist in SQL Server 2008R2 und höher enthalten, auch in der Standard Edition. Wir empfehlen, die Sicherungskomprimierung standardmäßig zu aktivieren, damit Ad-hoc-Sicherungen komprimiert werden.

• Sortierung ist Latin1_General_CS_AS FINP - Kollatierungsunterschiede zwischen Benutzerdatenbanken und Tempdb können zu Konflikten führen, insbesondere beim Vergleich von Zeichenfolgenwerten

• Sortierung ist SQL_Latin1_General_CP1_CI_AS - Kollatierungsunterschiede zwischen Benutzerdatenbanken und Tempdb können zu Konflikten führen, insbesondere beim Vergleich von Zeichenfolgenwerten

  • DEMO77

  • PROD77

• Verbindungsserver konfiguriert - BWIN2 \ INFOR ist als Verbindungsserver konfiguriert. Überprüfen Sie die Sicherheitskonfiguration, während eine Verbindung mit sa hergestellt wird, da jeder Benutzer, der sie abfragt, Berechtigungen auf Administratorebene erhält.

Priorität 200: Überwachung :

• Agent Jobs ohne Fehler E-Mails

  • Der Job syspolicy_purge_history wurde nicht eingerichtet, um einen Bediener zu benachrichtigen, wenn er fehlschlägt.

  • Der Job upd_durchpreis_monatl wurde nicht eingerichtet, um einen Bediener zu benachrichtigen, wenn er fehlschlägt.

  • Der Job upd_fertmengen_woche wurde nicht eingerichtet, um einen Bediener zu benachrichtigen, wenn er fehlschlägt.

  • Der Job upd_liegezeit_monatl wurde nicht eingerichtet, um einen Bediener zu benachrichtigen, wenn er fehlschlägt.

  • Der Job upd_vertreter_diff wurde nicht eingerichtet, um einen Bediener zu benachrichtigen, wenn er fehlschlägt.

  • Der Job UPDATE_CONNECT_IK wurde nicht eingerichtet, um einen Bediener zu benachrichtigen, wenn er fehlschlägt.

  • Der Job Ruhe.Cleanup wurde nicht eingerichtet, um einen Bediener zu benachrichtigen, wenn er fehlschlägt.

  • Der Job Sicherheits.DBCC Check DB wurde nicht eingerichtet, um einen Bediener zu benachrichtigen, wenn er fehlschlägt.

  • Der Job Überwachungs.Index neu erstellt wurde nicht eingerichtet, um einen Bediener zu benachrichtigen, wenn er fehlschlägt.

  • Der Job Überwachungs.Statistiken Aktualisierung wurde nicht eingerichtet, um einen Bediener zu benachrichtigen, wenn er fehlschlägt.

  • Der Job "Sicher.Transactionlog Backup" wurde nicht eingerichtet, um einen Bediener zu benachrichtigen, wenn er fehlschlägt.

  • Der Job Wartungs.Vollbackup SystemDB wurde nicht eingerichtet, um einen Bediener zu benachrichtigen, wenn er fehlschlägt.

  • Der Job Wartungs.Vollbackup UserDB wurde nicht eingerichtet, um einen Bediener zu benachrichtigen, wenn er fehlschlägt.

• Keine Warnungen wegen Beschädigung - SQL Server Agent-Warnungen für die Fehler 823, 824 und 825 sind nicht vorhanden. Diese drei Fehler können Sie über frühzeitige Hardwarefehler informieren. Wenn Sie sie aktivieren, können Sie viel Herzschmerz vermeiden.

• Keine Warnungen für Sev 19-25 - SQL Server Agent-Warnungen für die Schweregrade 19 bis 25 sind nicht vorhanden. Dies sind einige sehr schwerwiegende SQL Server-Fehler. Wenn Sie wissen, dass dies geschieht, können Sie Fehler möglicherweise schneller beheben.

• Nicht alle Warnungen konfiguriert - Nicht alle Warnungen des SQL Server-Agenten wurden konfiguriert. Dies ist eine kostenlose und einfache Möglichkeit, um über Korruption, Auftragsfehler oder größere Ausfälle informiert zu werden, noch bevor Überwachungssysteme diese erkennen.

Priorität 200: Nicht-Standard-Serverkonfiguration :

• Agent-XPs - Diese Option sp_configure wurde geändert. Der Standardwert ist 0 und wurde auf 1 gesetzt.

• Database Mail XPs - Diese Option sp_configure wurde geändert. Der Standardwert ist 0 und wurde auf 1 gesetzt.

• Standard-Volltextsprache - Diese Option sp_configure wurde geändert. Der Standardwert ist 1033 und wurde auf 1031 festgelegt.

• Standardsprache - Diese Option sp_configure wurde geändert. Der Standardwert ist 0 und wurde auf 1 gesetzt.

• Dateistream-Zugriffsebene - Diese Option sp_configure wurde geändert. Der Standardwert ist 0 und wurde auf 1 gesetzt.

• Maximaler Parallelitätsgrad - Diese Option sp_configure wurde geändert. Der Standardwert ist 0 und wurde auf 4 gesetzt.

• Maximaler Serverspeicher (MB) - Diese Option sp_configure wurde geändert. Der Standardwert ist 2147483647 und wurde auf 115000 festgelegt.

• min Serverspeicher (MB) - Diese Option sp_configure wurde geändert. Der Standardwert ist 0 und wurde auf 10000 festgelegt.

• Remote-Administratorverbindungen - Diese Option sp_configure wurde geändert. Der Standardwert ist 0 und wurde auf 1 gesetzt.

Priorität 200: Leistung :

• Kostenschwelle für Parallelität - Setzen Sie den Standardwert auf 5. Durch Ändern dieser Einstellung für sp_configure können die Wartezeiten für CXPACKET verringert werden.

• Snapshot-Backups aufgetreten - In den letzten zwei Wochen wurden 9 Snapshot-Backups erstellt, die darauf hinweisen, dass E / A möglicherweise einfrieren.

Priorität 210: Nicht standardmäßige Datenbankkonfiguration :

• Read Committed Snapshot Isolation Enabled - Diese Datenbankeinstellung ist nicht die Standardeinstellung.

  • D3PR

  • FINP

• Rekursive Trigger aktiviert - Diese Datenbankeinstellung ist nicht die Standardeinstellung.

  • DEMO77

  • PROD77

• Snapshot-Isolation aktiviert FINP - Diese Datenbankeinstellung ist nicht die Standardeinstellung.

Priorität 240: Wartestatistik :

• 1 - ASYNC_NETWORK_IO - 225,9 Stunden Wartezeit, 143,5 Minuten durchschnittliche Wartezeit pro Stunde, 0,2% Signalwartezeit, 2146022 Wartezeiten, 378,9 ms durchschnittliche Wartezeit.

• 2 - CXPACKET - 43,1 Stunden Wartezeit, 27,4 Minuten durchschnittliche Wartezeit pro Stunde, 1,5% Signalwartezeit, 32608391 Warteaufgaben, 4,8 ms durchschnittliche Wartezeit.

Priorität 250: Information :

• SQL Server wird unter einem NT-Dienstkonto ausgeführt

  • Ich verwende NT Service \ MSSQL $ INFOR. Ich wünschte, ich hätte stattdessen ein Active Directory-Dienstkonto.

  • Ich verwende NT Service \ SQLAgent $ INFOR. Ich wünschte, ich hätte stattdessen ein Active Directory-Dienstkonto.

Priorität 250: Serverinfo :

• Standard-Trace-Inhalt - Der Standard-Trace enthält zwischen dem 3. September 2017, 20:34 Uhr und dem 5. Oktober 2017, 12:50 Uhr 760 Stunden Daten. Die Standard-Trace-Dateien befinden sich in: C: \ Programme \ Microsoft SQL Server \ MSSQL13.INFOR \ MSSQL \ Log

• Laufwerk C Speicherplatz - 21308,00 MB frei auf Laufwerk C.

• Laufwerk D Speicherplatz - 280008,00 MB frei auf Laufwerk D.
• Laufwerk E Speicherplatz - 281618.00MB frei auf E-Laufwerk

• Laufwerk F Speicherplatz - 60193.00MB frei auf Laufwerk F.

• Hardware - Logische Prozessoren: 4. Physischer Speicher: 128 GB.

• Hardware - NUMA-Konfiguration - Knoten: 0 Status: ONLINE Online-Scheduler: 4 Offline-Scheduler: 0 Prozessorgruppe: 0 Speicherknoten: 0 Speicher VAS Reserviert GB: 281

• Letzter Neustart des Servers - 1. Oktober 2017 14:21 Uhr

• Servername - BWINPDB \ INFOR

• Dienstleistungen

  • Dienst: SQL Server (INFOR) wird unter dem Dienstkonto NT Service \ MSSQL $ INFOR ausgeführt. Letzte Startzeit: 1. Oktober 2017 14:22 Uhr. Starttyp: Automatisch, läuft gerade.

  • Dienst: SQL Server-Agent (INFOR) wird unter dem Dienstkonto NT Service \ SQLAgent $ INFOR ausgeführt. Letzte Startzeit: nicht angezeigt. Starttyp: Automatisch, läuft derzeit.

• Letzter Neustart von SQL Server - 1. Oktober 2017 14:22 Uhr

• SQL Server Service - Version: 13.0.4001.0. Patch Level: SP1. Edition: Standard Edition (64-Bit). AlwaysOn Enabled: 0. AlwaysOn Mgr Status: 2

• Virtueller Server - Typ: (HYPERVISOR)

• Windows-Version - Sie verwenden eine ziemlich moderne Version von Windows: Server 2012R2, Version 6.3

Priorität 254: Rundate :

• Kapitänsprotokoll: etwas und etwas stardieren ...

BEARBEITEN:

Ich habe diesen Leitfaden mit bewährten Methoden zum Einrichten von SQL Server mit VMware bereits studiert, und wir haben das meiste davon gemäß diesem Dokument festgelegt. Hyperthreading ist jedoch nicht aktiviert und NUMA ist auf dem VMware-Host nicht aktiv. SQL Server ist jedoch auf NUMA eingestellt.

BEARBEITEN:

Ich habe die RECONFIGURE ausgegeben, nachdem ich den Schwellenwert für Parallelität auf 50 gesetzt habe. Außerdem war meine MAXDOP-Einstellung von nicht konfiguriert.

Ich habe mich auch bei unserem VMware-Administrator erkundigt, anscheinend war ich falsch informiert. Unsere CPUs sind auf 2,6 GHz und nicht auf 4,6 GHz eingestellt. Ich habe diese Informationen oben korrigiert.

BEARBEITEN:

Wir haben versucht, ein Netzwerk gemäß dieser vmwarekb und Anleitung einzurichten . Wir haben der VM auch 4 weitere Kerne hinzugefügt. Die CPU-Auslastung blieb gleich.

Wie diskutiert das letzte Mal diese Frage gestellt , Ihre Top - Wartezeit ist ASYNC_NETWORK_IO. SQL Server wartet darauf, dass der Computer am anderen Ende der Pipe die nächste Zeile der Abfrageergebnisse verarbeitet.

Ich habe diese Informationen aus den Ergebnissen der Wartestatistiken von sp_Blitz erhalten (danke, dass Sie diese eingefügt haben):

1 - ASYNC_NETWORK_IO - 225,9 Stunden Wartezeit, 143,5 Minuten durchschnittliche Wartezeit pro Stunde, 0,2% Signalwartezeit, 2146022 Wartezeiten, 378,9 ms durchschnittliche Wartezeit.

Gehen Sie nicht zur Fehlerbehebung bei CPU-Threads über - das hat nichts damit zu tun. Konzentrieren Sie sich auf Ihren primären Wartetyp und auf Dinge, die diesen Wartetyp verursachen würden.

Um dies weiter zu beheben , führen Sie sp_WhoIsActive oder sp_BlitzFirst aus (Haftungsausschluss: Ich bin einer der Autoren davon). In beiden Fällen werden die aktuell ausgeführten Abfragen aufgelistet . Sehen Sie sich die Spalte mit den Warteinformationen an, suchen Sie die Abfragen, die auf ASYNC_NETWORK_IO warten, und sehen Sie sich die Apps und Server an, auf denen sie ausgeführt werden.

Von dort aus können Sie versuchen:

• Überprüfen Sie, ob diese App-Server nicht ausreichend ausgelastet sind (z. B. wenn die CPU maximal ausgelastet ist oder wenn Sie auf die Festplatte blättern), und optimieren Sie sie
• Arbeiten Sie mit den App-Entwicklern zusammen, um festzustellen, ob die Ergebnisse zeilenweise verarbeitet werden (wie bei jeder Zeile, die von SQL Server zurückkommt, wird die App deaktiviert und verarbeitet, bevor Sie nach der nächsten Ergebniszeile gefragt werden).
• Arbeiten Sie mit den App-Entwicklern zusammen, um weniger Daten auszuwählen (z. B. weniger Zeilen oder weniger Spalten, wenn sie nicht alle Daten benötigen - manchmal sehen Sie dies, wenn Leute versehentlich SELECT * ausführen und mehr Daten zurückbringen, als sie benötigen, oder nachfragen alle Zeilen, wenn sie wirklich nur die Top 1000 brauchen)

Update mit sp_WhoIsActive - In dem von Ihnen geposteten sp_WhoIsActive-Screenshot haben Sie einige Abfragen, die auf ASYNC_NETWORK_IO warten. Beziehen Sie sich für diese auf die obigen Anweisungen.

Schauen Sie sich im Rest der Abfragen die Spalte "Status" von sp_WhoIsActive an - die meisten von ihnen schlafen. Das heißt, sie arbeiten überhaupt nicht - sie warten darauf, dass die Apps am anderen Ende der Pipe ihren nächsten Befehl senden. Sie haben Transaktionen geöffnet (siehe Spalte "open_tran_count"), aber SQL Server kann nichts tun, um eine schlafende Transaktion zu beschleunigen. Diese Abfragen sind seit über vierzig Minuten geöffnet (die erste Spalte in sp_WhoIsActive. Sie tun einfach nichts mehr. Sie müssen diese Leute dazu bringen, ihre Transaktionen und ihre Verbindungen zu schließen. Dies ist kein Problem bei der Leistungsoptimierung.

Alles, was wir hier sehen, deutet auf ein Szenario hin, in dem wir auf die App warten.

Um meine eigene Frage zu beantworten. ASYNC_NETWORK_IO war eigentlich nicht das eigentliche Problem. Wir haben unser Leistungsproblem behoben, indem wir dieses Handbuch für latenzempfindliche Workloads befolgt haben:

Best Practices für die Leistungsoptimierung latenzempfindlicher Workloads in vSphere-VMs

Ich habe die Einstellungen, die wir auf unser System angewendet haben, hier mit gelber Farbe markiert:

Ich denke, die Einstellungen mit dem größten Einfluss waren die numa-Konfiguration und die Einstellung der Latenzempfindlichkeit auf hoch . Was beide erforderlich sind, um physische CPU-Kerne und RAM für die VM explizit zuzuweisen / zu reservieren.

Wir haben der VM auch weitere Kerne hinzugefügt und müssen jetzt unsere SQL Server-Lizenz von Standard auf Enterprise aktualisieren.

Es sieht so aus, als würde Windows die Taktrate Ihrer ca. 4,6-GHz-CPU-Kerne als 2,6 GHz angeben. Ich würde ein Tool wie CPU-Z ausführen, um zu überprüfen, mit welcher Geschwindigkeit sie tatsächlich ausgeführt werden, und dann die Energieeinstellungen ändern sowohl Windows als auch das BIOS / Management-Betriebssystem, um alle Energiespareinstellungen zu deaktivieren, die die Kerne möglicherweise auf eine niedrigere Geschwindigkeit drosseln.