none
Laufender Datenverkehr zwischen Applikationsserver und Datenbankserver, Hardware zur Beschleunigung

    Frage

  • Ich habe eine Datenbankanwendung (bin nicht der Programmierer davon) und möchte diese auf einem neuen Server beschleunigen.

    Läuft auf einem Server mit Windows Server 2012 R2 in zwei VMs. 2x Intel Xeon E5-2630v2 2,6 GHz, 6 Cores.

    VM mit Applikationsserver: 4 vCPUs

    VM mit Datenbankserver: 2 vCPUs (habe da auch schon mit vier vCPUs getestet, Sizing sagt 2 CPUs)

    Bei einer bestimmten Abfrage wartet man 20 Minuten bis zum Ergebnis. Auslastung CPU am Applikationsserver vielleicht 10%, CPU am Datenbankserver ca. 25%, eher weniger und 2,x MBit/s Senden und 1,x MBit/s Empfangen am Datenbankserver und das die ganze Zeit. Ab und an auch mal ein wenig mehr.

    Was meint Ihr, wie wurde hier die Abfrage programmiert? An der Art der Programmierung kann nur der Hersteller was ändern, würde aber gerne mal wissen auf was das hindeutet und wo man hier ansetzen muss? Kürzere Latenzzeit des Netzwerks würde hier helfen?

    So dann habe ich die beiden VMs auf zwei physische Rechner (leider nur Desktoprechner) portiert. Einer war mit 3,3 GHz i5 Prozessor bestückt, der andere mit einem i7-4790k (4 GHz Basistakt). Beide Rechner mit 1 GBit/s Netzwerk verbunden. Antwortzeit der Abfrage: 7:30 Minuten. Datenbankserver sendet mit 5 Mbit/s und Empfang 3 MBit/s während der ganzen Zeit.

    Dann die beiden VMs auf dem 4 GHz i7 betrieben. Hier ist die Antwortzeit 2:48. CPU beim Datenbankserver 25%, Senden 15 MBit/s, Empfangen 8 Mbit/s. Mit der Antwortzeit könnte man leben.

    Zum Schluss noch in die VM mit dem Applikationsserver die Datenbank installiert, Antwortzeit dann 2:20.

    Kann man anhand des Datenverkehrs und der Auslastung eine Aussage treffen wie das der Hersteller der Applikation gelöst hat? Viele sehr kleine Abfragen die permanent über die Leitung gehen?

    Was ist primär der Schlüssel für mehr Performance? Schnellerer Prozessor?

    Und da beide VMs auf einem Hostserver dann als VM laufen und die Anbindung über vSwitch auch von der Prozessorleistung abhängen muss einfach der schnellste bezahlbare Prozessor gekauft werden? So Richtung Intel Xeon Gold 6128 3,4 GHz, 6C, 19,25 MB Cache, 115W oder noch besser.

    Bei meinen eigenen Anwendungen habe ich noch kein Netzwerkverkehr und Auslastung des Datenbankservers im Detail angesehen. Optimierungen habe ich über SQL-Abfragen gestaltet. Hier bei der Anwendung kann ich aber nichts an der Applikation verändern und hoffe das mir jemand Tipps gibt auf was das hindeutet und wo man zur Beschleunigung ansetzen sollte.

    BTW: Da ich zuerst gedacht habe im Hyper-V Forum Hilfe zu bekommen habe ich da einiges zum Test mit netio geschrieben. Denke mal, ich verlinke nur und schreibe hier nicht das ganze nochmal hin?

    https://social.technet.microsoft.com/Forums/de-DE/12b916be-a812-4314-ad72-b2550521007c/applikation-und-datenbank-in-zwei-vms-kurze-antwortzeiten-realisieren?forum=virtualisierung





    • Bearbeitet ITProFromGermany Samstag, 25. Mai 2019 22:23 Verlinkung zur Frage im Hyper-V Forum
    Samstag, 25. Mai 2019 22:21

Alle Antworten

  • Hi,

    ganz ehrlich? Mann kann hierzu leider rein gar nichts sagen.

    Auf das Ergebnis einer Abfrage kann man 20 ms, 20 s oder auch mal 20 m warten. Es ist, ohne die Datenbankstruktur und die jeweilige Abfrage zu kennen, nicht möglich, irgendeine Aussage über Optimierungsmöglichkeiten zu nennen.

    Auch deine Messungen des Netzwerkdurchsatzes helfen da nicht. Es mag korrekt sein, dass zwischen Anwendung und DB Server tausende Abfragen abgesetzt werden, muss es aber nicht. Auch hier muss man zwingend die Anwendung und die Datenbank sowie das, was die beiden untereinander austauschen, kennen.

    ---

    Daher kann man dir nur eine allgemeine Hilfestellung geben.

    Am Datenbankserver kann man per SSMS mittels SQL Server Profiler oder (bei neueren Versionen) Extended Events sehen, was genau am Datenbankserver ankommt. Das wäre zumindest mal ein Ansatz. (Geht auch von einem anderen PC aus, man benötigt nur die passenden Rechte)

    Um Latenzprobleme zu vermeiden, ist es sinnvoll, die Anzahl der Anfragen/Antworten auf ein Minimum zu reduzieren.

    Latenzen spielen, insbesondere bei Anwendungen, die hunderte oder gar tausende Anfragen an den DB Server stellen, natürlich eine große Rolle. Wenn man bspw. 200 Anfragen für eine Aufgabe stellt, macht es einen extremen Unterschied, ob die Latenz nun 0,1 ms (20 ms Verlust durch Latenz) oder 10 ms (2.000 ms = 2 s Verlust durch Latenz) beträgt.

    Schnellerer Prozessor bedeutet nicht, dass auch nur irgendwas schneller läuft. Es gibt so viele mögliche Sachen, die einen Flaschenhals darstellen können. Plattenzugriffe, Speicherzugriffe, nicht ausreichendes RAM, CPU Belastung, Abfrageaufbau, fehlende und/oder falsch aufgebaute/kontraproduktive Indizes, falsche/veraltete Statistiken, usw.

    ---

    Letzendlich muss man sowas selbst sehen und vor allen Dingen hinter die Kulissen schauen können, um Optimierungsmöglichkeiten aufzuzeigen.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET (2001-2018)
    https://www.asp-solutions.de/ - IT Beratung, Softwareentwicklung, Remotesupport

    Sonntag, 26. Mai 2019 07:24
    Moderator
  • Nun, einige Hilfsmittel gibt es schon.
    Stichwort "Query Performance Monitor".
    Den SQL der laufenden Abfrage kann man ermitteln und eine Queryanlayse betreiben.
    And dem SQLselber kann man nichts ändern.
    Durch das Erstellen von Indizes kann man durchaus schnellere Abfragen erreichen.

    Nun kann es aber aiuch sein, darauf deuetet sowohl dei 10% der App als auch dei 25% des DB-Servers, dass nicht eine einzige Abfrage sonderen derer viele stattfinden, so dass die Zeit durch dei Summe der Abfragen zustande kommt.

    Auch diese kann man per Performancemonitor feststellen, wie viele Abfragen in dieser Zeit stattgefunden haben.
    Da wird sich eine Optimierung dann tatsächlich nur durch Änderung der Programmierung erreichen.

    Das ist ein typisches Szenario, wenn Anwendungen mit wenigen Testdaten entwickelt werden und dann in Produktion gehen.

    Stärkere Hardware ist nur dann von Nöten, wenn es eine einzige langdauernde Abfrage ist und der SQL-Server durch mehr CPU's und auch durch parallele Abfrage über mehrere CPU's optimierbar ist.
    https://www.mssqltips.com/sqlservertip/4939/how-to-force-a-parallel-execution-plan-in-sql-server-2016/
    https://blogs.msdn.microsoft.com/sqlserverstorageengine/2016/02/28/columnstore-index-scan-and-parallelism/

    Und wenn das nicht funktioniert hilft ggf. das Einrichten von Clustern umd die Daten auf mehrere Server zu verteilen und dadurch eine Parallelisierung zu erreichen.
    https://www.mssqltips.com/sqlservertip/1541/getting-started-with-sql-server-clustering/

    Sonntag, 26. Mai 2019 10:26
  • Und wenn das nicht funktioniert hilft ggf. das Einrichten von Clustern umd die Daten auf mehrere Server zu verteilen und dadurch eine Parallelisierung zu erreichen.

    https://www.mssqltips.com/sqlservertip/1541/getting-started-with-sql-server-clustering/

    SQL Clustering ist strikt Hochverfügbarkeit und nicht Lastverteilung, da die Instanz mit einer bestimmten Datenbank ja nur einmal existiert und immer nur auf einem Knoten aktiv ist.

    Mit einer Database Availability Group kann man ggfls. mehr erreichen, aber in der Regel nicht ohne die Datenbank-Struktur anzufassen (was bei einer 3rd Party-Applikation kaum machbar ist).


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Sonntag, 26. Mai 2019 10:31
  • Moin,

    wie ich bereits im anderen Thread angedeutet habe (ggfls. ist es nicht deutlich geworden ;-) ), musst Du erst mal feststellen, wo das Problem tatsächlich liegt. Deine Empirik hört sich absolut nicht danach an, dass die Übertragung von Abfragen und Ergebnissen zwischen Applikationsserver und SQL Server der Flaschenhals ist.

    Da die Applikation gewissermaßen eine Black Box ist, der SQL Server hingegen ein Standard-Produkt wo Du naturgemäß auch den Einblick in den Quellcode hast (Datenbankstruktur plus tatsächlicher SQL-Quellcode von Views und Stored Procedures), würde ich dort mit dem Troubleshooting anfangen:

    • Performance Counters (SQL hat auch solche fürs Netzwerk)
    • Wait States
    • Profiler und Query Optimizes

    Du wirst zumindest feststellen können, ob SQL zu lange für die Verarbeitung der Anfragen benötigt und welche Ressource dafür zuständig ist. Und tatsächlich wird man dann, je nach Parallelisierungsgrad, auch sehen, ob ein schnellerer Prozessor oder eher einer mit mehr Kernen (und somit auch mehr vCPUs pro VM, ohne dass es zu Overcommitment kommt) mehr Sinn macht.

    Wenn Du SQL zuverlässig ausschließen kannst, musst Du auf dem Applikationsserver schauen, welche Diagnose-Möglichkeiten da zur Verfügung stehen.

    Und bei Virtualisierung: Immer akribisch darauf achten, dass das Power Management in der Hardware auf "Static High Performance" gestellt ist und die C-States abgeschaltet sind.


    Evgenij Smirnov

    http://evgenij.smirnov.de


    Sonntag, 26. Mai 2019 10:40
  • Dann sollte man sich da mal Gedanken über Load Balancing machen:
    https://blog.dbi-services.com/sql-server-2016-availability-groups-and-load-balancing-features/

    Ich finde, dies würde diese Art der Performance Probleme lösen, wenn denn die Application eben nicht mehrere 100 Abfragen hintereinander für eine Sitzung macht.
    Dies ist Applikationsdesign.

    Sonntag, 26. Mai 2019 11:44
  • Es handelt sich um ein ERP.

    Die vorherige Version ist schon ein wenig alt und läuft mittlerweile in einer VM, 32bit Betriebssystem, zwei CPUs und 4 GB RAM. Mehr vCPUs sind für die Betriebssystemversion nicht empfohlen und da halte ich mich lieber dran. Bei Mehrbenutzerzugriff wird es da schnell eng. Wenn aber nur eine Person eine bestimmte Abfrage aufruft dauert dies 5 Minuten und das ist jetzt meine Referenz die das neue System unterbieten soll.

    Nun wurde auf die aktuelle ERP-Version migriert und der Client ist in Java programmiert. Applikationsserver wahrscheinlich auch, kann ich jetzt aber nur vermuten. Datenbank ist jetzt Microsoft SQL Server und nicht mehr Oracle wie bei der vorherigen Version. Laut Aussage des Herstellers des ERP wäre das kein Problem, ob man da aber jetzt schon alles optimiert hat?

    Bei einer Menge Abfragen wurde schon nachgebessert, man optimiert also an den Abfragen, erreichte aber nicht die Antwortzeiten von der vorherigen Version und beharrt darauf das wir erst einmal ein neuen Server kaufen sollen. Bevor wir das Sizing nicht einhalten können (was RAM angeht) wäre das unsere Schuld. Wenn ich im Taskmanager bei RAM aber nur x MB sehe und der Rest der 32 GB frei sind halte ich das nicht für die Ursache, habe ich ja auch mal ausprobiert indem alle anderen VMs gestoppt wurden. RAM ist erst später ein Thema wenn mal alle User da arbeiten.

    Dann gab es ein Angebot für ein 2.1 GHz Xeon-Prozessor neuster Bauart. Unser Hostserver für Virtualisierung hat 2,6 GHz, aber nicht aktuelles Modell und DDR3 anstatt DDR4. Auf einer Benchmarkseite habe ich gesehen das der Singlethreaddurchsatz vergleichbar zu unserem Prozessor liegt, mit steigender Core-Nutzung wird es dann besser weil er mehr Cores hat. Aber da kam mir die Befürchtung das mehr Cores nichts nützen, wenn die Anwendung bei einer einzelnen ERP-Abfrage überhaupt kein Multiprozessing nutzt. Sicherlich auch nur geschätzt, da ich nicht weiß wie die Programmierung läuft.

    Dann habe ich mich mal mit einer Abfrage im ERP beschäftigt, die ich schnell nachvollziehen kann. Anzeige von xxxx Artikel. Dauert im alten System ca. 2 Sekunden. Im neuen 9 Sekunden. Und ich sehe dabei wie auch bei der Abfrage die ich im Startposting beschrieben habe das in den 9 Sekunden dauerhaft Datenverkehr zwischen Applikationsserver und Datenbankserver vorhanden ist. Als ich das gemeldet habe, kam die Antwort das man in der nächsten Version das beschleunigen wird.

    Wahrscheinlich kommt dann pro zurückgelieferten Artikel weitere Abfragen anderer Tabellen wie z.B. Lagermenge, Dokumente die mit dem Artikel verknüpft wurden usw. Und das ganze nicht in einer SQL-Abfrage mit verknüpften Tabellen oder Unterabfragen, dann dürfte ja das Ergebnis in einem Rutsch kommen. Und persönlich habe ich mich nie mit ORM-Frameworks wie Hibernate beschäftigt, weiß ohnehin nicht ob man sowas nutzt und nutze auch C# anstatt Java.

    Aber ich glaube ich motiviere mich jetzt echt mal und versuche herauszufinden was da für Abfragen kommen. Auch wenn ich da kein Einfluss auf Änderung habe. Kann ich ja zuerst mal bei einer meiner Anwendungen ausprobieren, da weiß ich was ich über SQL für Abfragen nutze.

    Wie hier jemand richtig geschrieben hat: Entwickelt man das mit kleiner Anzahl von Demodaten ist das schnell. Hat man dann viele Daten steigt die Antwortzeit nicht linear, wenn man pro Artkel x weitere Abfragen abschickt. Der Hersteller fragte nämlich schon mal ob er unsere Datenbank haben kann und als das verneint wurde fragte man nach der Anzahl Datensätze die unsere Stücklisten haben. Und selbst ist mir das auch schon passiert, wahnsinnig stolz auf eine Abfrage und dann gemerkt das die bei mehr Daten ihr 42 als Ergebnis erst in 100000 Jahren liefern wird, ;-)

    Das mit den Energieoptionen ist ein gutes Hinweis. Da der Taskmanager immer gleichmässig den Basistakt anzeigt denke ich das da nichts langsamer wird wie das hier bei meinem Notebook passiert. Da ändert sich laufend die angezeigte Frequenz. Sollte ich aber echt mal überprüfen.

    Rechnerleistung habe ich mit 7-ZIP v19.00 gemessen, wollte wissen ob da vielleicht irgendwas komplett daneben liegt. Sah Okay aus, i7 Spitzenreiter, 2,6 GHz Prozessor vom Server ungefähr mit meinem privaten Notebook mit 2,2 GHz vergleichbar. Innerhalb der VMs sank die Performance. Bei meinem Notebook deutlich, bei Windows Server als Betriebssystem unter 10%. Und klar, schon mit installiertem Hyper-V hat man auf dem Host eine Virtualisierung.

    Ich werde wohl dem ERP-Hersteller fragen ob man diesen Prozessor für ausreichend hält:

    2x Intel Xeon Gold 6128 3,4 GHz, 6C, 19,25 MB Cache, 115W

    Und VM mit Applikationsserver und VM mit Datenbankserver auf der selben Maschine, damit diese per virtuellen Switch mit maximaler Netzwerkperformance angebunden sind.

    Weitere Verbesserungen sind nur durch Anpassungen am ERP zu realisieren.


    Sonntag, 26. Mai 2019 13:01
  • Am 26.05.2019 schrieb ITProFromGermany:

    Es handelt sich um ein ERP.

    Evtl. holst Du dir jemanden ins Haus, der sich mit dir hinsetzt und
    das analysiert, was am SQL ankommt. Wie die anderen schon geschrieben
    hatten, fehlende und/oder falsch positionierte  Indizies, nicht
    aktualisierte Statistiken, zu wenig TEMP-DBs und noch vieles andere
    mehr. Mit einem kompetenten DL kann man in 1 oder 2 Tagen sicherlich
    Verbesserungspotential finden.

    Servus
    Winfried


    WSUS Package Publisher:
    https://github.com/DCourtel/Wsus_Package_Publisher
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren:
    https://github.com/JochenKalmbach/communitybridge
    GP-PACK - PRIVACY AND TELEMETRIE: http://www.gp-pack.com/

    Sonntag, 26. Mai 2019 13:47
  • Hallo ITProFromGermany,

    Zu Deiner Aussage:

    "Ich werde wohl dem ERP-Hersteller fragen ob man diesen Prozessor für ausreichend hält: 2x Intel Xeon Gold 6128 3,4 GHz, 6C, 19,25 MB Cache, 115W. Und VM mit Applikationsserver und VM mit Datenbankserver auf der selben Maschine, damit diese per virtuellen Switch mit maximaler Netzwerkperformance angebunden sind."

    Schau Dir mal diesen Link an:

    https://www.mssqltips.com/sqlservertip/4801/sql-server-does-not-use-all-assigned-cpus-on-vm/

    und prüfe das mal mit dem Skript:

    -- Check Available CPUs with a SQL Server Query
    -- https://www.mssqltips.com/sqlservertip/4801/sql-server-does-not-use-all-assigned-cpus-on-vm/
    
    SELECT scheduler_id, cpu_id, status, is_online 
    FROM sys.dm_os_schedulers 
    GO
    
    -- Multi Server Query to Check All Servers
    ---------------------------------------------------------------------------------------------------------------
    -- CPU VISIABLE ONLINE CHECK
    ----------------------------------------------------------------------------------------------------------------
    DECLARE @OnlineCpuCount int
    DECLARE @LogicalCpuCount int
    
    SELECT @OnlineCpuCount = COUNT(*) FROM sys.dm_os_schedulers WHERE status = 'VISIBLE ONLINE'
    SELECT @LogicalCpuCount = cpu_count FROM sys.dm_os_sys_info 
    
    SELECT @LogicalCpuCount AS 'ASSIGNED ONLINE CPU #', @OnlineCpuCount AS 'VISIBLE ONLINE CPU #',
       CASE 
         WHEN @OnlineCpuCount < @LogicalCpuCount 
         THEN 'You are not using all CPU assigned to O/S! If it is VM, review your VM configuration to make sure you are not maxout Socket'
         ELSE 'You are using all CPUs assigned to O/S. GOOD!' 
       END as 'CPU Usage Desc'
    ----------------------------------------------------------------------------------------------------------------
    GO

    Aber wie bereits ausgeführt wurde, sind die Ursachen und damit die Lösung sehr vielfältig.

    Schönen Abend.


    • Bearbeitet Joerg_x Sonntag, 26. Mai 2019 20:47
    Sonntag, 26. Mai 2019 20:47
  • Die schnellste Hardware bringt nichts, wenn 100te SQL's nacheinander zur Ausführunggebraucht werden.
    Wenn die Ausführung eines SQL's angenommene 50 ms dauert und die Anwendung 20 Minuten steht, entspräche dies 2400 Abfragen!

    Montag, 27. Mai 2019 07:24
  • Hallo ITProFromGermany

    "Nun wurde auf die aktuelle ERP-Version migriert und der Client ist in Java programmiert. Applikationsserver wahrscheinlich auch, kann ich jetzt aber nur vermuten. Datenbank ist jetzt Microsoft SQL Server und nicht mehr Oracle wie bei der vorherigen Version. Laut Aussage des Herstellers des ERP wäre das kein Problem, ob man da aber jetzt schon alles optimiert hat?"

    Neben den von Anderen bereits genannten Punkten solltest Du folgendes bedenken. ORACLE verfügt "by default" über "OPTIMISTIC LOCKING". Das bedeutet, dass ein lesender Prozess nicht von einem schreibenden Prozess blockiert wird.

    Wenn es sich bei Eurem System um ein hochfrequentes System handelt, dann kann es sehr wohl vorkommen, dass eine Abfrage, die normalerweise in wenigen Sekunden ausgeführt wird, plötzlich langsamer wird, da auf die Ressource(n) gewartet werden muss.

    Aus meinen bisherigen Erfahrungen ist aber die CPU, RAM, etc. nicht das Problem. Probleme mit Hardware zu erschlagen, ist kontraproduktiv, da Du damit die Symptome zwar bekämpft, aber die Ursache nicht löst.

    Aus Deinen bisherigen Ausführungen kann man eigentlich überhaupt keine Empfehlungen geben. Zunächst einmal würde ich die Wait Stats analysieren:

    Der nächste Schritt wäre eine gezielte Analyse der Abfrage, die Du als langsam beschreibst:

    • Verwendet die Abfragen Parameter?
    • Welche Indexe werden verwendet?
    • Sind Statistiken aktuell?
    • ...

    Mache bitte mal folgendes:

    • Führe die lang laufende Abfrage auf dem SQL Server aus und poste mal den Code der Abfrage. Dazu kannst Du das folgende Skript verwenden (ev. werden mehrere Prozesse angezeigt; aber am Code solltest Du erkennen können, um welche Abfrage es sich handelt)
    SELECT	T.text,
    	Q.query_plan,
    	R.status,
    	R.blocking_session_id,
    	R.wait_type,
    	R.wait_time,
    	R.last_wait_type
    FROM	sys.dm_exec_requests AS R
    	CROSS APPLY sys.dm_exec_sql_text (R.sql_handle) AS T
    	CROSS APPLY sys.dm_exec_query_plan(R.plan_handle) AS Q
    WHERE	R.session_id <> @@SPID;

    Mit Hilfe der obigen Abfrage erhältst Du den Text und den geschätzten Ausführungsplan. Einfach mal auf den Ausführungsplan klicken und dann das Ergebnis hier verlinken, indem Du den XML-Code auf dieser Seite einfügst:

    Den daraus erstellten Link stellst Du hier bitte noch mal ein. Dann kann man etwas mehr sagen!

    PS: 

    "Bei einer Menge Abfragen wurde schon nachgebessert, man optimiert also an den Abfragen, erreichte aber nicht die Antwortzeiten von der vorherigen Version und beharrt darauf das wir erst einmal ein neuen Server kaufen sollen. Bevor wir das Sizing nicht einhalten können (was RAM angeht) wäre das unsere Schuld."

    Diesen Mist höre ich immer wieder von Kunden, wenn es darum geht, Verantwortung von sich zu weisen. Solange Du - wie Du ja geschrieben hast - ausreichend RAM zur Verfügung hast, solltest Du dich nicht auf solche Diskussionen einlassen sondern mit fundierten Ergebnissen den Hersteller in die Defensive drängen. Aus meinen bisherigen Erfahrungen knicken Vendoren immer dann ein, wenn man sachlich und belegbar deren Aussagen ad absurdum führt! Notfalls lasst Euch einen Experten ins Haus kommen, wie Winfried bereits erwähnt hat.


    Uwe Ricken (Blog | Twitter)
    Microsoft Certiied Master - SQL Server 2008
    Microsoft Certified Solution Master - CHARTER Data Platform
    Microsoft Certified Solution Expert - Data Platform
    db Berater GmbH
    Microsoft SQL Server Blog (german only)

    Montag, 17. Juni 2019 09:55