Ich habe eine Site, auf der eine sehr IO-empfindliche Anwendung (Accredo Saturn) läuft. Es handelt sich um ein in Delphi geschriebenes Buchhaltungs-/CRM-Paket mit einer lokalen Flat-File-Datenbank.
Aus verschiedenen historischen Gründen lief es auf der Site auf einem Windows Server 2008 R2-Terminalserver unter Server 2012 R2 Hyper-V auf einem Proliant DL380 G9, wobei ihr DC ein alter DL380 G7 mit SBS 2011 war (Exchange läuft schon lange auf Office 365).
Ich habe sie jetzt auf einen neuen DL380 G10 mit Server 2019 aktualisiert. Der Host und der Domänencontroller laufen auf 6x 600 GB 10k SAS in RAID10 (Host auf seiner eigenen Partition, eine große Partition für den Rest) auf einem P408i-p, mit dem Remote-Desktop-Server auf 4x 480 GB SATA SSD für gemischte Nutzung in RAID10 auf einem P408i-a. Der Server hat 2x Xeon 4210 und 64 GB Speicher. Die Daten für diese Software befinden sich auf einer VHDX auf dem SSD-Array, das direkt auf dem Remote-Desktop-Server gemountet ist.
Sie haben 18 Benutzer, die alle den Remote-Desktop-Server für dieses Programm verwenden, wobei 8 Callcenter-Benutzer auch einen Unify-Telefonsystem-Agenten verwenden. Ein oder zwei verwenden Edge. Ich wollte es mit den Spezifikationen etwas übertreiben, da dieser Kunde pingelig ist, was die Geschwindigkeit angeht, und wie ich bereits erwähnte, ist die Software pingelig!
Der Kunde hat sich über langsame Geschwindigkeiten innerhalb der Software beschwert. Ich habe es getestet und festgestellt, dass ein Vorgang, der vorher 5 Sekunden dauerte, jetzt bis zu 15 Sekunden dauert. Die alte 2008 R2-VM auf derselben Hardware funktioniert wie immer, es scheint also fast etwas mit dem Gast zu tun zu haben.
Ich habe diskspd ohne angemeldete Benutzer ausgeführt (-c100b -b4K -o32 -F8 -T1b -s8b -W60 -d60 -Sh) und sehe auf beiden VMs ähnliche Lese-IOPS und Durchsätze, aber mit einigen großen Abweichungen bei den Threads auf der neuen 2019-VM. Ich sehe etwa 531,41 Mbit/s und 136.000 IOPS auf den Gästen, aber zwei Threads mit 1,9 Mbit/s auf der 2019-VM. Die alte VM liegt bei 520,44 Mbit/s, aber konstant bei etwa 72–76 pro Thread, mit Ausnahme eines Threads mit 3,75. Insgesamt waren es 133.000 IOPS. Das ist auf dem SSD-Array.
Im Vergleich dazu liefert mir das Bare-Metal-SSD-Array mit denselben Parametern 999 Mbit/s, konstant 124–125 Mbit/s pro Thread und insgesamt 255.000 IOPS.
Ich habe mich seit Tagen damit beschäftigt. Ich habe versucht, den Registrierungseintrag zu verwenden, um den IO-Load Balancer zu deaktivieren, aber ohne Erfolg – ich bin mir nicht sicher, ob das überhaupt für 2019 gilt. Ich habe sowohl feste als auch dynamische VHDXs ausprobiert – habe sogar das Datenvolumen zwischen den Servern ausgetauscht (es ist sein eigenes VHDX). Habe dynamischen und statischen Speicher ausprobiert. Habe versucht, NUMA zu aktivieren und zu deaktivieren.
Ich bin mit meinem Latein am Ende und habe einen frustrierten Kunden, der morgen sein Callcenter für das nächste Jahr auf der alten VM startet!
2008 R2 ist eine VM der Generation 1, Version 5, während 2019 eine VM der Generation 2, Version 9 ist.
Ich bin für alle Hinweise dankbar, wie man die Missions-IOPS zurückbekommt!
Dies ist mein erster Beitrag. Entschuldigen Sie also, wenn ich nicht genügend relevante oder spezifische Informationen angegeben habe.
Antwort1
auf 6x 600 GB 10k SAS im RAID10
Anstelle eines Raid 1 mit 2 Hochleistungs-SSDs, die Ihnen was bieten – 50-mal so viel IO?
Generell gilt: SSD besorgen.
Verwenden Sie darüber hinaus SSDs mit statischer Größe.
Viel mehr KÖNNEN Sie nicht tun – Ihre Zahlen klingen allerdings verrückt. 200.000+ IOPS sprechen für eine unglaublich schlechte Programmierung.
Antwort2
Dies ist kein Beweis dafür, dass das Leistungsproblem am Speicher liegt.
Analysieren Sie den langsamen Anwendungsworkflow im Detail.
Welche Codepfade werden benötigt? Profilieren Sie, wie viel Zeit jede Funktion benötigt.
Welche Datenbankabfragen werden durchgeführt?
Um wie viele Datensätze handelt es sich und in welcher Größe?
- Wie wird Parallelität gehandhabt, einschließlich datei- oder datenbankbasierter Sperren?
- Werden externe Ressourcen über das Netzwerk verwendet? Wie hoch ist die Latenzzeit hierzu?
- Wie sieht die Kommunikation mit dem Client über die Leitung aus? Der Client könnte in diesem Fall der Terminalserver sein.
Um so tiefgreifende Einblicke zu erhalten, benötigen Sie wahrscheinlich die Unterstützung des Softwareanbieters. Bestehen Sie auf detaillierten Profilen und Transparenz, wie Sie sie von einem Paket zur Überwachung der Anwendungsleistung erhalten würden.
Ressourcenbeschränkungen wie CPU, Speicher, IOPS und Netzwerkbandbreite können der Grund für langsame Vorgänge sein. Und das sind Messgrößen. Es ist jedoch auch möglich, dass der Stack dieser Anwendung auf diesem Betriebssystem nicht schneller wird, selbst wenn Sie Hardware darauf setzen. Die einzige Möglichkeit, dies herauszufinden, besteht darin, zu isolieren, was tatsächlich langsam ist.
Antwort3
Ich habe dies gerade bemerkt, als ich hierher kam, um ein anderes Problem zu untersuchen. Das Problem wurde behoben und lag an TSFairShare Disk. Durch das Deaktivieren wurde das Problem behoben – es stellte sich heraus, dass es bei vielen Anwendungen, die eine Datenbank auf Dateiebene verwenden, ein Problem darstellt.
Wir haben die Lösung in einem Microsoft Dynamics GP-Forum gefunden. Die Details des eigentlichen Fixes sind hier zusammengefasst -https://www.ryslander.com/disable-fair-sharing-in-windows-server/– für GP und die von uns verwendete Anwendung (Accredo) muss nur FSSDisk deaktiviert werden – die anderen haben wir in Ruhe gelassen.
Ich stelle fest, dass mit Server 2022 die Standardeinstellung wieder auf „Deaktiviert“ gesetzt wurde.