Wir haben eine einzelne Instanz von SQL Server 2016 SP1, die in einer virtuellen VMware-Maschine ausgeführt wird. Es enthält 4 Datenbanken, jeweils für eine andere Anwendung. Diese Anwendungen befinden sich alle auf separaten virtuellen Servern. Keiner von ihnen ist noch in Produktion. Die Leute, die die Anwendungen testen, berichten jedoch über Leistungsprobleme.
Dies sind die Statistiken des Servers:
- 128 GB RAM (110 GB maximaler Speicher für SQL Server)
- 4 Kerne bei 4,6 GHz
- 10 GBit Netzwerkverbindung
- Der gesamte Speicher ist SSD-basiert
- Programmdateien, Protokolldateien, Datenbankdateien und Tempdb befinden sich auf separaten Partitionen des Servers
- asd
Die Benutzer führen einen Einzelbildzugriff über eine C ++ - basierte ERP-Anwendung durch.
Wenn ich den SQL Server mit Microsoft unter ostressVerwendung vieler kleiner oder großer Abfragen einem Stresstest unterziehe , erhalte ich maximale Leistung. Das Einzige, was drosselt, ist der Client, weil er nicht schnell genug antworten kann.
Aber wenn es kaum Benutzer gibt, tut der SQL Server kaum etwas. Die Leute müssen jedoch ewig warten, um irgendetwas in der Anwendung zu speichern.
Laut der Abfrage " Sag mir, wo es weh tut " von Paul Randal sind 50% aller Warteereignisse ASYNC_NETWORK_IO.
Dies kann entweder ein Netzwerkproblem oder ein Leistungsproblem mit dem Anwendungsserver oder -client sein. Keiner von beiden nutzt seine Ressourcen aus der Ferne mit maximaler Kapazität. Die meiste Zeit ist die CPU auf allen Rechnern (Client, Anwendungsserver, Datenbankserver) um die 26%.
Die Latenz der Netzwerkverbindung beträgt ca. 1-3ms. Die E / A des Datenbankservers erreicht während der normalen Verwendung mit der Anwendung eine Schreibgeschwindigkeit von maximal 20 MB / s (durchschnittlich 7 bis 9 MB / s). Wenn ich einen Stresstest durchführe, bekomme ich ungefähr 5 GB / s.
Die Puffer-Cache-Größe beträgt 60 GB für die Datenbank unseres ERP-Systems, 20 GB für unsere Finanzierungssoftware, 1 GB für Qualitätssicherungssoftware und 3 GB für das Dokumentenarchivierungssystem.
Ich habe dem SQL Server-Konto das Recht erteilt, die Instant File-Initialisierung zu verwenden . Das hat die Leistung nicht im Geringsten gesteigert.
Die Lebenserwartung einer Seite liegt bei ca. 15.000+ während des normalen Gebrauchs. Sinkt während des Endes des schweren Stresstests auf ca. 0,05k, was zu erwarten ist. Die Batches / Sek. Liegen je nach Arbeitsbelastung bei etwa 2-8.000.
Ich würde sagen, die ERP-App ist nur schlecht geschrieben, aber ich kann nicht, weil alle Anwendungen betroffen sind. Selbst bei minimaler Arbeitsbelastung.
Ich kann jedoch nicht genau sagen, was das verursacht. Gibt es Tipps, Hinweise, Anleitungen, Anwendungen, Best / Worst-Practices-Dokumente oder andere Aspekte, die Sie in Bezug auf dieses Problem im Hinterkopf haben?
Dies sind die Ergebnisse von sp_BlitzFirst:
Ich lief es 600 Sekunden. Ich habe es während einer hohen Auslastung der App gestartet. 1/3 der Zeit ist es ASYNC_NETWORK_IO. Getestet habe ich auch die Netzwerkverbindung mit NTttcp, PsPing, ipferf3, und pathping. Nichts Ungewöhnliches. Die Reaktionszeiten betragen maximal 3 ms, durchschnittlich 0,3 ms. Der Durchsatz liegt bei ca. 1000 MB / s.
Meine Untersuchung ergibt ASYNC_NETWORK_IOimmer die Nummer eins waitstat.
Wir haben das Ergebnis der Deaktivierung der Large-Receive-OffloadFunktion in VMware untersucht. Wir testen noch, aber die Ergebnisse scheinen inkonsistent zu sein. Unser erster 'Benchmark' ergab eine Dauer von 19 Minuten (Top-Ergebnis ist 13 Minuten, was nur erreicht wird, wenn die App auf der VM mit dem SQL Server selbst ausgeführt wird). Das zweite Ergebnis ist 28 Minuten, was wirklich schlecht ist.
Das erste Ergebnis unseres 'Benchmarks' war 19 Minuten. Was gut ist. Denn das Top-Ergebnis war 13 Minuten (was nur erreichbar ist, wenn die Anwendung auf der VM mit dem SQL Server selbst Benchmarks erstellt). Dies deutet stark auf ein Netzwerkproblem hin. Oder ein Problem mit der VMware-Konfiguration.
Ich habe momentan keine Ahnung, welche Methoden ich anwenden soll, um es auf den Flaschenhals zu bringen.
Die maximale Leistung mit der App ist nur erreichbar, wenn die App auf der VM mit dem SQL Server selbst ausgeführt wird. Wenn die App auf einer anderen VM oder einem virtuellen Desktop ausgeführt wird, verdreifacht sich die Dauer unseres Benchmarks (von 13 Minuten auf 40 Minuten oder mehr). Alle Endpunkte (VM von SQL Server, VM von App Server und Virtual Desktop) verwenden dieselbe physische Hardware. Wir haben alle anderen Endpunkte auf andere Hardware verschoben.
EDIT: Scheint, als ob das Problem zurück ist. Nachdem wir den Energiesparmodus von "Ausgeglichen" auf "Hochleistung" eingestellt hatten, haben wir die Reaktionszeiten erheblich verbessert. Aber heute habe ich wieder sp_BlitzFirst mit einem 300 Sekunden Sample gestartet. Das ist das Ergebnis:
Die Wartezeit für ASYNC_NETWORK_IO beträgt mehr Sekunden als die Sekunden, die sp_blitzfirst ausgeführt hat.