Server+Switch 10Gb, Arbeitsstationen 1Gb, SQL-DB langsam

Moin René,

dein geplantes vorgehen hört sich erst mal gut an, deine JumboFrames sollten aber eigneltich keine Änderung bewirken. Datenbankkommunikation passiert nach meiner Erfahrung her immer sehr kleinteilig.

Auch ein Anruf bei einem Netzwerkprofi halte ich für den falschen Ansatz. Euer Netzwerk läuft ansonsten ja flüssig. Ruf den Hersteller des ERP Systems an und lass dich von ihm Beraten was es noch für Performance tweeks gibt und was normalerweise die Systeme ausbremst.

Immer wieder gern gesehen, Virenscanner die sich jeden Netzwerkverkehr eines "bösen" Systems anschaut der auf eine Datenbank zugreift. Falls vorhanden, hier mal entsprechende Ausnahmen einrichten.

vG
PJM

Moin,

welche SQL- Version läuft bei Dir?
Hängt eine Firewall zwischen SQL und Clients? Evtl. IPS/IDS hier aktiv?
Welche AV Lösung läuft auf dem Server und den Clients? Sind hier die korrekten Ausnahmen für den SQL gesetzt?

Gruß Looser

Es ist sogar denkbar, dass die Jumbo-Frames ursächlich sind, für deine Probleme. Die Jumbo-Frames gehören deaktiviert, außer du hast converged Traffic für FCoE oder iSCSI laufen. Es produziert in deinem Fall lediglich Overhead in Form fast leerer Frames. Das kompensiert deine Hardware bis zu einem gewissen punkt, bringt aber dem SQL Server gar nichts.

Dass die Interhost-Kommunikation schneller ist als die übers Netzwerk ist auch klar. 1:5 ist aber nicht normal.

Bezüglich der langsamen Datenbank und dem ERP dass die DB nutzt. Weißt du denn wie die Clients genau mit der Datenbank kommunizieren? Die Clients werden doch nicht direkt mit der DB reden?

Auf einem Hyper-V sollte außer der Hyper-V Rolle (oder irgendwie noch Desktop Experience bei VDI) nichts laufen, gar nichts, außer Treiber oder eventuell noch Monitoring Software. Sicherlich kein DBMS.

Wie gesagt meine Theorie wäre das Netzwerktraffic zum Hypervisor direkt eine andere Priorität hat als zu einer VM. Aber selbst wenn man das irgendwie ändern oder ergründen könnte so würde ich das nie produktiv nutzen. Neben der Performance ergeben sich ja auch noch andere Probleme:
- Das Setup wird von keinem Hersteller unterstützt.
- Die Lizenz erlaubt das nicht (ja, jegliche Software ist eine "Rolle").
- Die Sicherheit des Hypervisors wird gefährdet.

Hallo,

wie @fisi-pjm bereits schrieb, haben Jumbo-Frames keinen Einfluss auf Client-Server-Kommunikation eines SQL-Systems. Jumbo-Frames bringen nur einen Vorteil, wenn man große Dateien im Netz transportiert (zB. Backup, Kopieren von Videos). SQL-Abfragen in einem Client-Server-System gehören bestimmt nicht dazu!

Einen Server als Hyper-V mit 64 GB RAM und 3 VMs plus einem DB-Server halte ich für vollkommen unterdimensioniert!

Ich betreibe einen Windows ERP-Server (MS-SQL-DB) für 10 User auf einem Blech mit 12C (24T) und 128GB RAM. Der läuft, obwohl sich die Nutzer immer noch "beschweren", dass bestimmte Funktionen im ERP-System "langsam" sind.

SQL-DBs sind dafür bekannt, dass sie sehr RAM-hungrig sind.

Und wie bereits geschrieben: ein Hypervisor ist ein Hypervisor und nichts sonst!!! Bei einem VMware-Host kommt doch auch keiner darauf, noch Libre-Office zu installieren (unabhängig davon, dass dies gar nicht geht).

Also beim Hersteller nachfragen, wie ein optimaler Server für das System aussieht und entsprechend umsetzen. Egal ob als VM oder als Blech.

Jürgen

Gucke ich mich beim Hersteller der DB-Engine um, dann finde ich dort als Headline:


Das wirft wieder die Frage auf, wie die Clients mit der DB reden. Dieses Tool kennst Du? https://docs.microsoft.com/en-us/sysinternals/downloads/tcpview

Hallo,

ein ERP-System als Client-Server-Konstrukt besteht in der Regel aus 3 Komponenten:

- dem Client auf dem Destop-PC des Users
- dem Anwendungs-Server des ERP-Systems
- dem DB-Server

Nur der Anwendungs-Server kommuniziert mit dem DB-Server (wenn man beide auf einem Server installiert, ist das eine interne Kommunikation auf dem Server ohne Beteiligung von Netzwerk und Firewall). Der Client kommuniziert nur mit dem Anwendungs-Server (Firewall).

Um welches ERP-System handelt es sich denn? Ich glaube nicht, dass der ERP-Client (nicht DB-Client!!) direkt mit der DB kommuniziert.

Jürgen

Gut, dann gucke mal bitte, was genau in dem Moment passiert, wenn die Client-Anwendung warten muss und im Vergleich dazu direkt auf der Hardware schneller geht. Ich weiß jetzt nicht, was genau angestoßen wurde um 10 oder 50 Sekunden zu warten aber selbst di 10 Sekunden hören sich viel an. Es gibt auch sicherlich irgendwo in der Software eine Art Performance-Audit-Tool. Vermutlich auch für die Clients.

Wie @chiefteddy erklärt hat, geht für Sachverständige die Suche Richtung Performance der Kommunikation des Anwendungsservers mit den Clients.

Kommunizierst Du über Named Pipes oder TCP/IP ?

Ich lese und verstehe den Satz:
https://isential.de/index.php/hidden-menu/alles-auf-einer-seite/49-techn ...

Dass der Anwendungsserver die Clients per SMB-Freigabe bedient. Kannst ja mal gucken, ob es Freigaben gibt und wie viele Verbindungen die Clienst dazu aufbauen.

TCP Path MTU Discovery ist dir sicher ein Begriff??
https://de.wikipedia.org/wiki/Path_MTU_Discovery
https://www.elektronik-kompendium.de/sites/net/2012221.htm
Ist also ein Standard bei v4 und v6 deshalb juckt es den Drucker nicht. Jumbos solltest du bei 10G und höher also immer eingeschaltet lassen.

Ich kann es mir nicht vorstellen, weder 1996 noch im Jahr 2022. Ich leite zufällig eine Softwarenentwicklung habe 1,5 Flure mit Nerds sitzen und mir fällt spontan keine Software ein die so funktioniert, jedenfalls nicht im ERP Bereich.

Jetzt schreiben wir hier hin und her und ein Powershellabfrage hätte dich nur Sekunden deines Lebens gekostet und wir hätten Gewissheit.

Du könntest einmal vielleicht bei einem Client mit Wireshark mitlesen, was der sich mit dem Server erzählt.
Dann sieht man zumindest, ob es ein Netzwerkproblem ist (wenn viele Retransmissions kommen) oder ob der Server einfach irre lange darüber nachdenkt, was der Client macht.
Ein möglicher Flaschenhals ist z.B., wenn der Client sich oft ab- und anmeldet, weil der Server dann auch normalerweise jedes mal im DNS nach dem PTR der verbindenen IP fragt.
Wenn die bei den Clients nicht auflösbar ist, kann das zu jeweils 2-3 Sekunden Wartezeit führen.
Oder der Client verbindet sich zu einem Hostname, der auch auf eine IPv6-Link-Local-Adresse auflöst, die aber, wenn der Server in einem anderen Segment steht, nicht erreichbar ist und muss dann immer erst in einen Timeout laufen. Oder der Client will per IPv6 verbinden, das wird aber in der Server-Firewall blockiert, weil da die Freigabe nur für IPv4 vorgenommen wurde.

Deshalb: Mal mit Wireshark schauen, aber ein grundsätzliches Problem mit Jumbo Frames sehe ich da aktuell nicht.



Frames haben keine fixe Größe, sie werden lediglich auf die maximale Größe begrenzt, die übertragen werden kann. Wenn Jumbo-Frames aktiviert sind, wird die maximal übertragbare Größe für den Payload erhöht - in dem Fall auf 9014 Bytes.
Wenn nur 500 Bytes übertragen werden müssen, wird das Paket halt nur 500 Bytes + 18 Bytes Header groß.

Unsere SQL-Server (allerdings MySQL, aber da tut sich ja vom Prinzip nichts) profitieren auf jeden Fall von größeren Frames, die durchschnittliche Frame-Größe beträgt hier knapp 6000 Bytes.

Hallo,

mal 2 andere Ansätze:

1. Bei VMware wird der Datenverkehr der VMs, des Host (Management) und im Cluster die Kommunikation zw. den Hosts sauber getrennt und kann auf unterschiedliche NICs gelegt werden.
Ich kenne mich bei Hyper-V nicht so aus, aber kann hier auch Management (Kommunikation zum Host) und Kommunikation zu den VMs auf getrennte NICs gelegt werden?
Wenn JA, dann lege doch die Kommunikation zum Host und damit zur DB auf die 2. freie 10G-NIC und schaue, ob es besser wird.

2. Ich hatte mal eine Lösung, bei der die DB, der Anwendungs-Server und ein Terminal-Server mit dem entsprechendem ERP-Client auf einem - entsprechend leistungsfähigen - Blech zusammengefasst war. Damit hatte ich quasi eine Einzelplatz-Installation (alles - DB, Applikation und Client - auf einer Maschine). Der Zugriff für die 5 Benutzer erfolgte über RDP. Dh., die gesamte ERP-Kommunikation verließ nicht der Server.

Jürgen

PS: Bei Win 2022 Server ist die Core-Installation als Hyper-V-Host nicht mehr Kosten-/Lizenz-frei! Ich hoffe, ihr habt daran gedacht. Host + DC + File-Server macht 3 Lizenzen. Aber ihr habt ja eh keine Core-Host-Installation.

Ja, größere Rahmen erkauft man sich aber mit unzähligen Nachteilen. Außerdem geht es im dem Fall um ein Client OS, das keinen nutzen im Gesamtbetrieb ziehen kann. In erster Linie geht erst mal nur die Latenz hoch und es ist unklar wie viel die Hardware davon kompensieren kann.

Unzählige Nachteile durch Jumbo-Frames? Seit 10+ Jahren fährt unser komplettes Büro-Netzwerk, da wo es möglich ist, auf Jumbo-Frames und bisher sind uns keine Nachteile begegnet.
Auch und vor allem die Clients profitieren davon, weil das Kopieren von Daten auf die Datenserver deutlich schneller ist und tatsächlich den Gigabit-Anschluss der Clients ausreizen kann.

Ja, unzählige Nachteile. Google z. B. mal "jumbo frames latency" oder die anderen Nachteile. https://docs.lib.purdue.edu/cstech/1770/

Es hat an einem Client mit gemischten Traffic in der Regel nichts zu suchen. Auch mit Blick auf CRC32 ist das unsinnig und bringt nur solange etwas, wie die Hardware das auffängt oder Treiber das tolerieren. Außerdem ist bis jetzt unklar ob das Setup latenzkritische Anforderungen hat. Daher sind auch so Einwürfe wie "Path MTU Discovery" total hohl, weil davon UDP Verbindungen profitieren und weniger TCP.

Hier noch ein paar Nachteile die für einen Windows Client sofort eintreten und nur deshalb oft nicht direkt auffallen weil die NIC des Cleint und die Leistung des Switchports das im gewissen Umfang kompensieren: https://superuser.com/questions/715590/why-do-jumbo-frames-hurt-latency

Nach dem was ich gelesen habe, gehe ich davon aus, dass der Anwendungsserver per SMB die Clients beblobbt und somit ist JF ein Faktor der Probleme machen kann besonders, wenn die IO eine Gewisse Anzahl pro Sekunde erreichen oder überschreiten. Leider warten wir hier noch auf Input seitens des TO.

Moin,

• meine Erfahrung mit "Uralt-ERPs", die es schon zu MSDOS/Win3-Zeiten gab und die mit der Zeit "moderner" wurden ist, daß sie ihre "Altlasten" behalten. In diesem Fall würde meine Kirstallkugel sagen, da gibt es Probleme mit dem SMB-Zugriff-.

• Weiterhin sind 64GB für einen SQL-Server heutzutage "nichts". Übrigens solltest Du auch pürüfen, ob da nicht noch ein SQL-Server-Express drauf läuft. Wenn man statt dem Standard den Express nimmt, hat man auch die "Handbremse" angezogen.

• Weiterhin habe ich bei Datenbankanwendungen oft beobachtet, daß der Zugriff "lokal" immer deutlich schneller ist, als über das Netzwerk, insbesodnere, bei "historischen" Systemen (s.o.) die SMB verwenden. Von daher ist Faktor 5 nicht ungewöhnlich. Es gibt sogar einige Kunden mit solcher Schrottsoftware, die ich auf Termin-Server-Betrieb umgestellt habe, weil nur da ein vernünftiges Arbeiten möglich war.

Mein Ansatz zur Lösungsfindung wäre:

• SQL-Server definitiv in VM verschieben, weil das die Handhabung deutlich erleichtert und der Performance i.d.R. keine Abbruch tut, wenn man es richtig macht (RAM-Ausbau nicht vergessen!).

• Eine Client in eine VM stecken und auf demselben Server laufen lassen Dann ist ersmal die physikalische Struktur außen vor und Du weißt, ob es an der Software oder an der Netzwerkinfrastruktur hängt.

• Wireshark anwerfen und alle mitprotokollieren.

• Defender (oder andere AV-Software) testweise deaktiveren.

lks

Das betrifft aber nur die spezielle Hyper-V Core Edition. Wenn du eine Standard oder Datacenter Lizenz für deine VMs hast darfst du nach wie vor einen Hyper-V als Basis betreiben. Nur darf halt nichts anderes darauf gehosted werden.

Ich zitiere aus der verlinkten Studie:

Und auch die Systemlast kommt gut weg - siehe Abbildung 2 auf Seite 7.
Da steigt der Durchsatz, glechzeitig sinkt die Zahl benötigter CPU-Cycles und Instruktionen.

Und die Antwortzeit-Unterschiede der getesteten Dienste? Tja, die wurden durch einen TCP-Algorithmus (Nagle) verursacht, der in den meisten Anwendungen ohnehin ausgeschaltet ist. Dieser Algorithmus wurde schon zu Zeiten von Telnet und VNC deaktiviert, da das Sammeln von kleinen Daten, um die bestmögliche Ausnutzung der Paketgröße zu erreichen, bemerkbare Latenz erzeugt. Und das passiert auch bei 1500 Bytes-Frames
Deshalb sagt das Conclusio des Paper auch:



Die angesprochenen Probleme aus superuser.com:


Um das mal in Perspektive zu setzen: Die Bit time bei Gigabit beträgt ~4 µs, bei 9k Datenübertragung dauert das also 7.372 µs = 7,3 ms.
Bei 1,5k sind es demzufolge 1,2 ms.
Den Interpacket-Gap (mindestens 96ns bei Gigabit) habe ich da nicht hineingerechnet, dieser ist aber durchaus relevant, wenn die Paketrate entsprechend hoch ist.

Ja, sicher, da ist ein deutlicher Latenzunterschied. Aber in der Praxis ist das wenig relevant, da du latenzsensitive Anwendungen ohnehin schon auf VLAN-Layer priorisierst.
Wenn wir das auf 10G umrechnen, was heuer für Verbindungen zwischen Switches durchaus als Standard bezeichnet werden darf, kannst du das Komma um eine Stelle nach links verschieben - und schon ist das Problem unterhalb einer Millisekunde.
Ich gebe zu, dass bei 1G-Netzen, die eine dauerhafte Auslastung mit Full-Sized frames haben, deutliche Latenzunterschiede geben, bei 10G ist das aber bereits unterhalb der für Windows-Nutzer darstellbaren Schwelle.
Und es erklärt m.M.n. unmöglich derart krasse Unterschiede in der Ausführungszeit, wie der TO sie beschreibt.


Das liegt daran, dass bei TCP die MSS in den Paketheadern steht und ein Router diese Werte ggf. an die für ihn transportierbaren Größen anpassen soll (MSS Clamping). Da tritt dieses Problem also prinzipbedingt nicht auf.


In der Theorie mag das alles problematisch sein, aber in der Theorie kann auch ein eingerissener Fingernagel zu einem qualvollen Tod führen, wenn wirklich alle Umstände ungünstig sind.
Den theoretisch beschriebenen Problemen steht hier aber ein seit über 10 Jahren problemlos funktionierendes Netz mit Jumbo-Frames gegenüber. Von daher halte ich mich damit zurück, Jumbo-Frames per se zu verteufeln und die Problemursache ausschließlich dort zu suchen.

Ich sagte ja, bis zu einem gewissen Grad kompensiert die Hardware das Problem.
Dennoch ist es nicht zu kalkulieren, weil zu viele verschiedene Verbindungen aufgebaut werden, die immer wenn sie einen Router passieren, den Vorteil verlieren und draus grundsätzlich ein Nachteil werden kann. Bestimmte Protokolle, SIP z. B. haben mehrfach Nachteile...

Wenn die kommunizierenden Geräte die selbe Layer-2 Domaine nutzen und das Forwarding großer Frames beschleunigt wird, dann kann da das klappen. Dennoch macht ein Windows 10 für meinen Geschmack so viele unterschiedlichen Traffic, dass das Ganze eher eine Hoffnung ist und keine Gewissheit.
Und es ist auch nicht ohne Grund nicht best practice.

Hallo,


Wie soll sie denn sonst funktionieren? Ich kann dir spontan mehrere (ERP) Warenwirtschaftsysteme und Finanzbuchhaltungs-Software nennen, die so funktionieren. Die Client-Applikation redet direkt über TCP mit der Datenbank. Das funktioniert doch immer so. Wie denn auch sonst?

cu,
ipzipzap

Moin...
das ist blödsinn...
oh... das wird ne lange liste!
Gupta (SQLBase) ist kein MS SQL...
was für 10G Nics hast du den da verbaut? Treiber aktuell und Richtig eingestellt?
und da liegt dein Problem... hast du mal mit Iperf3 gemessen?
hast du deine TCP verbindungen optimiert... je nach treiber und hardware / Software ist das nötig


Frank

Hallo @ipzipzap,

das ist nicht immer so! Eigentlich ist das die Ausnahme.

Die Struktur ist in der Regel Client --> Applikations-Server --> DB-Server

Das simpelste Merkmal dafür ist, wenn während der Installation der Software auf dem Server ein DB-User eingerichtet werden muss.
Im anderen Fall müsste für jeden Benutzer, der auf die DB zugreifen soll, im DB-Management (und nicht in der Applikation) ein eigener Account mit Usernamen und Passwort eingerichtet werden.

Üblicherweise greift nur die Applikation mit dem dafür eingerichteten System-Account auf die DB zu.
Der Client meldet sich bei der Applikation mit seinem Account an und erhält die hinterlegten Recht (zB in welcher Tabelle darf er was) und die Applikation holt die Daten bzw. schreibt die Daten dann mit dem System-Account von/in die DB.
Der User kommuniziert nur mit der Applikation, nicht mit der DB.

Das ist eigentlich bei allen Client-Server-Applikationen so.

Jürgen

Das sollte so sein, aber trotzdem stolpert immer mal wieder über Software von unfähigen Programmieren, die das anders machen.

lks

Hallo @temuco

wenn das nicht gewünscht ist, müssen die 5 Hanseln eben damit leben!

Auf einem Virtualisierungs-Host läuft keine andere Applikation! Punkt und Aus!

Und schon gar nicht eine DB-Applikation. Das ist ein absolutes no go!

Der Hersteller des ERP-Systems wird eine Anforderungsliste für einen entsprechenden Server herausgegeben habe - mit den Mindest-Anforderungen und der empfohlenen Ausstattung. Und die hat man bereitzustellen. Egal ob als separates Blech oder als VM. Punkt!

Warum betreibt ihr denn einen File-Server für "ein paar Word- und Excel-Dokumente". Da ist ein kleines NAS mit 2 Platten deutlich preiswerter und sparsamer bei der Energie.
Ein AD wird immer redundant ausgelegt! Dh., du brauchst also 2 Domänen-Controller. (Wenn dein DC Updates installiert und neu bootet, gibt´s keine Anmeldung und keine Namensauflösung DNS, keine IPs DHCP usw.)


Kann man, sollte man aber aus guten Gründen nicht machen. Wenn man sich nicht an die anerkannten Regel hält, muss man mit seinem Murks leben.
Zum Glück muss dein Konstrukt nicht zum TüV. Da würde es gnadenlos durchfallen.

Jürgen

Ja, dann ist aber der embedded Webservice noch im Rennen.

Moin
Das kann ich so unterstreichen.
Auch bei kleinen Firmen muss man auf die Vorgaben des Herstellers achten und diese umsetzen.
Zusätzlich verstößt der TO ja auch gegen die Lizenzbediengungen von MS, so er nur eine Standard-Lizenz des Windows-Servers hat.
Der Server läuft doch sowieso schon, warum jetzt noch ein NAS daneben stellen?
Unfug!
In solchen Umgebungen benötigt man nicht wirklich 2 DCs. Ich würde sogar die Fileserver-Rolle auf den DC packen. Der hat beim TO eh nix zu tun.
Wann installieren denn deine Server Updates, während der Regelarbeitszeit der User?

An den TO:
Ich würde auch zuerst mal mit dem Hersteller der ERP-Lösung sprechen, an welcher Stelle Optimierungen möglich sind.
Mehr RAM gehört definitiv in den Server.

Meine Rede.

Seh ich nicht so, der Zugriff lokal läuft ja, scheint also kein RAM Thema zu sein. Klar ist der RAM generell bissel unterdimensioniert, aber Ursächlich für das Performanceproblem ist er glaub ich nicht.

Gruß
PJM

Hallo @groscho,

du bist Herr über deine Netzwerke und kannst dort machen, was du willst.

Mir ist Redundanz wichtig und ich will nicht immer bei Wartungsarbeiten an Servern Spät- oder Nachtschichten machen bzw. das Wochenende dran geben.
Das ist mir alle mal einen 2. DC wert.


Wie lautet der Spruch: Ein DC ist ein DC und nur ein DC.

Ausgangspunkt für meinen Kommentar war die Bemerkung des TO:


Ein NAS ist energetisch deutlich sparsamer als ein File-Server oder ein Virtualisierungs-Host.
Das NAS kann die Funktion des DC übernehmen.
Der Server wird frei und kann als dedizierter ERP-Server eingesetzt werden.

Und sie da: viele Probleme lösen sich in Luft auf.

Aber einfach einen Server aus dem Einsteiger-Bedarf zu beschaffen (ist ´n Server, war aber billig) ohne vorher ein konkretes Anforderungsprofil zu haben und die Ausstattung danach auszuwählen, führt fast immer zu Problemen.

Und mein obiges Konzept wäre unter Berücksichtigung der (wahren) Lizenz-Kosten sicher auch nicht teurer.

Jürgen

Davon wird er nicht wahrer. Natürlich wäre es wünschenswert, einen DC nur als DC zu nutzen. Aber dann hat man allein für die redundanten DCs zwei Lizenzen "verballert". Nicht immer ist es nötig den doppelt vorzuhalten und bei gerniger Auslastung (Kleinbetrieb mit wenig Datenverkehr zum Server) kann es durchaus wirtschaftlicher sein, da auch noch File und print mit draufzupacken. Das muß man im einzelfall entscheiden.

lks

Mir sind das meine Kunden schon wert.
Ich kann mir auch nicht vorstellen, dass man in KMU mit 5-10 Clients alle Server-Funktionen redundant hat.
Wenn man dann nur von 9-17 Uhr patcht, gibt es sicherlich Ausfälle.
Als nächstes kommst du vielleicht noch mit dem Märchen, dass es ohne DC auf Blech nicht geht.
Was für ein unsinniger Spruch. Wer hat den ausgegraben?

Das früheste Zitat hier im Forum, das ich per google gefunden habe ist hier:

Cache Restriktion bei DC deaktivieren

@psannz hat diesen Spruch öfter verwendet.

lks

Hallo @groscho.


Ich glaube, andersrum wird ein Schuh draus: Wochenend-Zuschlag 200%, Spät-/Nachtschicht 100% Aufschlag


Kommt darauf an: Ist der Virtualisierungs-Host Mitglied der Domäne? Man sollte da schon mal nachdenken!


Übrigens: Ich weiß schon, warum ich um Windows-Server einen großen Bogen mache und sie nur dort einsetze, wo die Applikation es zwingend fordert.
Bei meinem System lizensiere ich die USER, nicht die Server (M$ verlangt ja für beides Geld)

Jürgen

Wieso kommst du darauf, dass ich das zu den von dir angegebenen Konditionen mache?
Evenuell hat man dafür ja sogar Verträge...
Nichtmal das ist ein Problem. Habe ich bei mir und einigen anderen im Einsatz.
Aber das weiß man natürlich nur, wenn man sich damit auch richtig beschäftigt und nicht nur Sprüche in Foren bringt.

Hallo @goscho,


Sind doch übliche Konditionen (wir sind im Kälte-Klima-Bereich unterwegs und bieten 24h/7d-Service - ich kenne also die Preise für Einsätze am WE oder abends).

Außerdem wäre mir der Einsatz meiner Freizeit das Wert.

Bei deiner Preisgestaltung kannst du ja machen, was du willst. Darüber brauchen wir nicht diskutieren.


Das ich M$ im Backend nicht mag, heißt ja nicht, dass ich das nicht einsetze oder davon keine Ahnung habe.

Und ich habe nie behauptet, dass bestimmte Konstellationen nicht funktioniere (M$ hat mit dem SBS ja lange Zeit auch ein eigenes Produkt dafür im Angebot). Aber nicht alles was prinzipiell funktioniert, ist "best practice".

Und ich habe dem TO (und dir) eine Lösung skizziert, die deutlich preiswerter und näher an "best practice" ist.

Das man einen ERP-Server mit SQL-DB nicht gleichzeitig als Virtualisierungs-Host nutzt - darüber sind wir uns doch wohl hoffentlich einig.

Und damit ist diese fruchtlose Diskussion für mich beendet.

Jürgen

Moin,
da es hier nicht um Lizenzen oder Design geht will ich mal nur zur Technik vermuten.
- Möglicherweise teilen sich Raidc. und Netzwk. die 8x Lanes ein IO Test Client zu Server kann helfen
- vielleicht mal mit dem Hardware offload an und wieder aus ob es einen Effekt hat.
- 10G Adapter haben RDMA von Haus aus an aber manchmal macht es nicht was es soll
VG aus Bremen

Moin...

als erstes würde ich mal die grundlagen des netzwerks prüfen, also mal sehen was Iperf3 so dazu sagt!
nööö, so pauschal kann das nicht gesagt werden! natürlich gibbet fälle wo das zutrifft- aber eher selten!

ISEntial hatten wir mal in HH bei einem Kunden, war aber nur auf einem TS zu gebrauchen.. ist aber über 10 Jahre her...
das der DB server nicht auf den Hyper-V host geschraubt hört, ist wohl klar...

Frank

Hallo,

ich kenne speziell diesen SQL-Server nicht, bin eher auf SQL Server von MS "zu Hause".

Da ich Datenbankentwickler bin, möchte ich das Thema mal auf die Datenbank selbst bringen.
Meiner Erfahrung aus den letzten Jahrzehnten mit DB-Performance nach ist das Netzwerk in den allermeisten Fällen NICHT das Problem einer schlechten DB-Performance. Wenn das Netzwerk ein Problem wäre, dann hat man in den meisten Fällen generell eine schlechte Netzwerk-Performance, nicht nur mit einer DB.

Zu den Kommentaren oben:


Nein, das ist lediglich der Standard bei Internet-Datenbanken, weil man den DB-Server komplett vom Client trennen will.
In Desktop-Datenbanken, die komplett im lokalen Netzwerk laufen, ist der Standard, daß der Client direkt mit der DB kommuniziert, so auch hier.


Das ist auch oft der Fall, allerdings wird i.d.R. eine Gruppe eingerichtet, der eine/mehrere Rollen zugewiesen sind. Die Rollen bekommen die Rechtezuordnung, die Gruppen die Rollenzuordnung. Die User sind in den Gruppen, die Gruppen und User i.d.R. AD-Gruppen und AD-User, damit komplett durch IT-Admins regelbar, während Developer sich um die Rollen und ihre Rechte kümmern.
Es gibt auch andere Modelle (unsicherer), bei denen ein Client einen Standardbenutzer mit hinterlegten Kennwort im Client-Code verwendet.

Zurück zur DB-Performance:
Die optimale Performance erreicht man natürlich, wenn der Client direkt mit der DB kommuniziert, daher ist das auch der Standard für netzwerklokale DB-Anwendungen.

Wie oben aber schon richtig bemerkt wurde: Wenn so eine Software schon so lange existiert, werden "alte Gewohnheiten" aber oft beibehalten, weil Neuentwicklung halt viel kostet. Vor 30 Jahren gab es noch kein .NET und eine der weitverbreitetsten Clients war Access (später auch und gerade mit DB-Server als Backend), und die Gewohnheit des Access-Programmierers war und ist leider heute immer noch sehr oft, alles im Client zu machen. Das hat sich mit .NET leider nicht verändert, und das heißt, man lädt alles in Recordsets (die in .NET anders heißen) und verarbeitet die Daten dann lokal, schlimmstenfalls auch noch per Programmcode (Schleife durch ein Recordset, um x Datensätze zu verändern und solcher Unsinn).
Die Einführung von LINQ in .NET hat das Problem hier eher noch verschärft, weil es dazu verleitet, "SQL" im Programmcode zu machen, obwohl es nur so etwa wie SQL aussieht und gar nichts damit zu tun hat.
Wer also früher einen Access-Client programmiert hat, findet sich in .NET schnell wieder und kann alles gleichermaßen schlecht portieren. .NET ist dabei offlineorientiert, lädt die Daten also und kappt dann die Verbinung, während Access voll online orientiert ist und mit Netzwerkabbrüchen nicht zurechtkommt.

Beiden gemeinsam ist aber, wenn man es so macht, kommt fast immer schlechte Performance mit der DB dabei heraus.
Eine DB performant zu bekommen heißt, die Vorteile des Backend-DB-Servers auch voll auszunutzen. Also nicht die Daten von zwei Tabellen auf den Client zu laden, damit dieser dann die benötigten Teile ausfiltert, sondern etwa eine View auf dem Server zu hinterlegen, der möglichst ALLE Berechnungen dort ausführt und nur die benötigten Daten an den Client schickt. Im besten Fall ist der Client komplett "dumm" und schickt nur Anfragen an den Server und lädt dann die Daten herunter, macht lokal damit aber sonst nichts, außer anzeigen und ggf. neue Eingaben zu tätigen.

Der zweite große Performanceproblem-Grund ist sehr oft, daß schlecht oder gar nicht indiziert wurde. Wenn, wie oben beschrieben, vieles auf dem Client passiert, kann der Server da auch nicht viel mit Caches oder Logs gegensteuern, in der Folge bremst man jede Datenbank voll herunter, weil man sie nicht richtig nutzt.

Die dritte große Performancebremse ist natürlich der Server selbst: Viel Speicher ist nötig, wenn viele Clients mit großen Datenmengen arbeiten - bei 5 würde ich mir da keine großen Sorgen machen, wenn man nicht gleich in jeder Tabelle Millionen von Datensätzen verarbeiten muß.
Wenn allerdings auf dem gleichen Server noch HyperV, diverse VMs, der DC und ein Fileserver laufen, muß man natürlich auch die RAM-Dimensionen entsprechend einrichten. Die DB-Server machen das nicht von alleine, hier muß man i.d.R. bei solchen Konstellationen dem DB-Server eine feste Größe an RAM-Speicher dauerhaft zuteilen, damit das nicht dynamisch passiert und streckenweise von anderen Ressourcen "geklaut" wird, was für das Betriebssystem viel Arbeit bedeutet. Wenn man zuviele riesige Datenmengen verwendet, wird ohnehin auch Temp-Festplattenplatz zur temporären Auslagerung verwendet (also nicht das, was das BS sowieso macht, sondern was die Abfrage-Engine der DB mit eigenen Temp-Dateien macht, um eine Abfrage abarbeiten zu können).

Da Du ja schon festgestellt hast, daß die Verarbeitung auf dem Server schneller läuft, ist das Netzwerk meist das erste, was beschuldigt wird. Dabei sollte man aber auch berücksichtigen, daß Clients, die auf dem DB-Server installiert werden, sehr oft per Default Shared Memory als Protokoll einsetzen, also quasi direkt im gleichen RAM wie der DB-Server mit den Daten arbeiten kann, was naturgemäß schneller geht, als Daten über ein Netzwerk zu ziehen. Das Netzwerk hat hier also keine Schuld, wenn das so ist.
Alternativ könnte man aber auch darüber nachdenken, den Client direkt auf dem Server als Terminal Server Lösung zu installieren und lokal nur aufzurufen.
Windows Server kennt dazu "RemoteApps", die intern wie eine RDP-Sitzung funktionieren, aber nur die Fenster der Anwendung dem entfernten Client zur Verfügung stellen, ohne eine komplette Desktop-Umgebung zu benötigen. Der Vorteil ist, daß jeder Client von überall her darauf zugreifen kann - per VPN auch in sicherer Umgebung aus dem Internet heraus - bei stets gleichbleibender bester Performance. Für den entfernten Client sieht eine solche Anwendung aus, als sei sie lokal installiert, da man keinen eigenen Desktop dazu startet. Man merkt den Unterschied maximal an einer eventuell zusätzlichen Serveranmeldung (die man bei AD aber sicherlich auch von der lokalen AD-Anmeldung "weiterreichen" kann).

Mein Job ist es, sehr oft "klassische" DB-Clients, oft von Laien programmiert, zu optimieren oder neu zu programmieren. Ich kann daher aus Erfahrung sagen, daß in SEHR vielen DB-Anwendungen, auch solchen, die aus Systemhäusern kommen, falsch mit den Datenbanken umgegangen wird und entsprechend schlechte Performance dabei herauskommt.

Ein erster Ansatz ist auf jeden Fall, die Kommunikation zwischen Client und Server zu überwachen und mit den Tätigkeiten im Client abzugleichen, um zu sehen, was hier passiert, optimal natürlich, wenn man dazu auch Zugriff auf den Sourcecode des Clients hat. Oft kann man an der Kommunikation schon erkennen, wie der Client mit der DB umgeht. Wireshark wurde oben ja schon genannt, ist aber eher schwierig für den Zweck, weil es da um Netzwerkpakete geht. SQL Server von MS hat hierzu den SQL Server Profiler, der speziell den Datenbankverkehr mitschneidet und für den Zweck viel besser/viel einfacher ist. Ich weiß nicht, wie es bei Deiner Backend-Datenbank ist, da ich diese, wie gesagt, nicht kenne, aber möglicherweise hat der Hersteller hier auch ein solches Tool oder es gibt sowas von Drittherstellern.

Fazit: Laß das Netzwerk erst mal außen vor und prüfe, was Client und Server miteinander "quatschen", und je nachdem, was sich ergibt, kann man hier viel mehr optimieren. Wenn Du DB affin bist, lohnt es sich auch, mal die Tabellen auf Indizierung hin zu prüfen. Nicht selten erlebt, daß "DB-Programmierer" überhaupt keinen Index auf keiner Tabelle erstellt haben. Minimum sollte ein Primary Key auf jeder Tabelle sein und einen oder mehrere Indizes auf weitere Felder oder Feldkombinationen, je nachdem, was abgefragt wird.

Gruß

Christian

Hallo @Bitsqueezer

die Server-Applikationen, die ich kenne und mit denen ich gearbeitet habe, waren genau so strukturiert, wie ich es beschrieben habe. Egal ob es ERP-Systeme, Backup-Programme, DMS-Systeme oä. waren.

Die Probleme, die du dann als Optimierungsmöglichkeiten beschrieben hast, beschreiben genau, wie man es NICHT machen soll. Wenn du als Datenbank-Programmierer schreibst, dass dies heute in vielen Fällen die "Normalität" darstellt, dann frage ich mich ehrlich, was die Informatiker in ihrem Studium eigentlich lernen???

Die Fehler beim Design der DB-Applikation sind doch Anfänger-Fehler, die eigentlich keiner machen dürfte, der sich auch nur rudimentär mit DB-Programmierung beschäftigt hat!

Wenn das wirklich so ist, wie du es beschreibst (was ich nicht bezweifle), bekomme ich das kalte Grauen.

Ich habe nicht Informatik studiert. Ich bin ein klassischer "Quereinsteiger" und komme aus der Industrie-Automatisierung. Aber selbst mir ist bekannt, dass man erst die DB-Struktur optimiert (Stichwort Normalform) bevor man an die eigentliche Umsetzung geht. Und das man eine DB indiziert, gehört doch zu den Grundfunktionen.

Als ich angefangen habe, mich mit DBs zu beschäftigen, war ISDN (zur Erinnerung: 64k) ein HighSpeed Internetanschluss. Da kam niemand auf die Idee, die halbe DB auf den Client zu transferieren um die Verarbeitung der Daten dann dort zu machen. Da wurden schlanke SQL-Abfragen an den Server geschickt und der lieferte nur die Antworten aus. Anders wäre es auch gar nicht gegangen.

Aber hier zeigt sich wieder, nach immer mehr (Hardware-) Power und Bandbreite schreien statt mal etwas Geist in die Code-Optimierung zu stecken.

Ansonsten stimme ich deiner Analyse zu.

Jürgen

PS: Der Vorschlag mit dem Terminal-Server kam von mir schon zu Beginn der Diskussion.

Ein Problem ist, daß die meisten, die DB-programmierung machen, möglicherweise studierte Leute sind, aber oft nicht aus der Informatik. SAP z.B. hat zu meiner Studienzeit sehr viele "fachfremde" Programmierer angestellt (Theologen, Politologen, etc.). Da kontne man sich nur die Haare raufen, was die sich dabei denken.

Ein Anderes ist, selbst wenn die Leute aus der Informatik gekommen sind und mit Elan alles ordentlich machen wollten, haben sie vorhandene Strukturen vorgefunden und per ordre-di-mufti dazu angehalten, die Altlasten am laufen zu halten. Und die heutigen Kindergartenentwicklungsmethoden wie agile Softwareentwicklung tun ihr ürbiges dazu.

lks

Hallo,

@chiefteddy:

Das habe ich nicht angezweifelt, ist ja DEINE Erfahrungswelt, entspricht aber nicht den üblichen netzwerklokalen Datenbanken.
Es gibt Applikationsserver natürlich auch dort, aber sind dann eher Datenbanken aus Systemhäusern mit entsprechender Architektur. Die meisten Firmen, in denen ich bisher gearbeitet habe, haben dagegen sehr oft "selbstprogrammierte" Anwendungen, deren Design alles andere als professionell und nicht selten "unter dem Radar" der lokalen IT gebaut sind, und die an irgendeinem Punkt dann nicht mehr weiterkommen, was dann meist mein Einsatzort ist.
Du wärst überrascht, in wievielen geschäftlich genutzten Datenbanken genau die oben beschriebenen Probleme die Ursachen für schlechte Performance sind.


Keine Ahnung, was Du meinst mit "wie man es nicht machen soll".
Was das Thema Informatiker angeht: Ich bin selbst auch keiner, aber seit rd. 30 Jahren mit vielen Arten von Datenbanken beschäftigt, kann Dir also nicht sagen, was Informatiker lernen...
Und: Tatsächlich sind es eher weniger Informatiker, die Datenbanken für Firmen erstellen. Informatiker sind eher in der Forschung o. Ä. zu finden, wo es um komplizierte Algorithmen geht. Für das Design/die Entwicklung einer Feld-Wald-Wiesendatenbank eines Unternehmens findet man sie eher selten... ;)


Jo...aber nur in der Theorie... ;)
Es gibt etliche Möglichkeiten, eine DB zu designen, ebenso Indizes zu setzen, und ebenso ist Normalisierung auch nicht für alle Beispiele die korrekte Methode. Die Welt der DB ist tatsächlich viel Grau und wenig Schwarz/Weiß. Es gibt nie DIE Lösung und man kann auch in professionellen DB nicht selten noch viel optimieren. Daher gilt es, alles zu prüfen, wenn man ein Problem lösen will, und darauf habe ich oben hingewiesen mit ein paar Punkten, die die meiste Performance bringen. Einfach davon auszugehen, daß ein "Profi" alles schon optimal gebaut hat, ist falsch. Wir sind alle nur Menschen und keiner schafft es, eine 100% "korrekte" DB zu bauen nach allen Regeln der DB-Theorie. Alleine schon wg. problematischen Anforderungen von Kunden.


Naja, in meinem Fall waren es eher Modems oder "Kirschbaumlink" zwischen 2 PCs... :D
Aber um zum Punkt zu kommen: Die Datenmengen seit damals haben sich aber auch rasant geändert. Früher wurde eine DB aufs letzte Bit größenmäßig geplant und alles, was ging, herausgelassen. Heute gehen bei einer einzelnen Anfrage auch mal ein paar Gigabyte über das Netz - weil die DB bzw. die Frontend-Anwendung ggf. schlecht programmiert wurde. Daher hier der Rat an René, einfach mal zu prüfen, was denn bei den problematischen Anfragen tatsächlich passiert im Hintergrund - nur so bekommt man heraus, wo Optimierungspotential besteht. Und wenn möglich, die DB-Struktur auch auf mögliche Designfehler (wie Indizes etc.) zu prüfen, da dies tatsächlich oft schon den Unterschied von Minuten zu Sekunden ausmacht.

Schon mal gut zu hören, daß es im vorliegenden Fall viele Stored Procedures gibt, die die Geschäftslogik auf dem Server erledigen, das gibt Anlass zur Hoffnung, daß die DB zumindest gut designt ist.

Dennoch kann man sich auch in SPs (Stored Procedures) schnell ein Performancegrab schaufeln, wenn sie nicht datenbankkonform gebaut wurden. Ich habe bei Kunden schon oft ganze Kaskaden von verschachtelten SPs gesehen, die Daten hin und herreichen und bis hin zur Einzelzeilenverarbeitung die ganze Performance in die Knie zwingen. Das ist die typische Programmiererdenke: Wiederverwendbarer Code in kleinste Einheiten aufteilen - das ist in der Anwendungsprogrammierung völlig richtig und OK, in der DB dagegen genau falsch, bei der man eine Set-Based-Denke entwickeln muß und keine Modulprogrammierung oder Schleifenverarbeitung etc. Es geht manchmal nicht anders, aber das sollte die große Ausnahme sein.

Soll heißen: Geschäftslogik auf DB-Server ist i.d.R. die beste Option - aber SPs bedeuten nicht automatisch, daß sie die Performance richtig nutzen. Ein einziges LIKE kann durch falsch gesetzte (oder weil nicht anders machbar) Wildcards die ganze Performance in die Knie zwingen, weil vorhandene Indizes nicht verwendet werden können - usw. Es gibt etliche Fehlerquellen für schlechte Performance in einer DB-Anwendung, für die in den allermeisten Fällen weder das Netzwerk, noch die Serverhardware, noch die Software des DB-Servers schuld ist, sondern einfach grauslige Programmierung/DB-Design/Abfragen uvm.

Übrigens, René, würde ich an Deiner Stelle auch mal Serverlogs checken, schlechte Programmierung kann ebenfalls bedeuten, daß es einen Lock (bis hin zum Deadlock) gegeben hat, der schlicht Anwender 2 auf Anwender 1 warten läßt, weil dieser die Datenquellen während laufender Abfragen für andere Benutzer gesperrt hält. Um nur eine mögliche Ursache zu nennen. Somit läuft die DB dann besser, wenn gerade nur einer damit arbeitet...;)

Gruß

Christian

Wenn es das denn nun war bitte dann auch deinen Thread hier als erledigt schliessen!

Sofern dann noch Test Feedbacks kommen...?!

Hattest du doch schon *gacker*


Im Ernst: Hast du auf dem Switch Flow-Control aktiviert? Das können unmanaged Switches regelmäßig nicht, deshalb verursacht es bei denen keine Probleme.
Falls es aktiviert ist: Flow-Control ist ein Attavismus, den man früher gebraucht hat, als es noch gemischte Umgebungen mit Halb- und Vollduplex gegeben hat. Mittlerweile schaltet man Flow-Control immer aus — am Switch und auf der NIC.

Wenn's das denn nun war bitte deinen Thread dann hier auch als erledigt schliessen!

Machen ist wie wollen nur krasser