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

temuco
Goto Top
Guten Morgen,

ich habe eine Frage an die Experten, in der Hoffnung, ihr gebt mir ein paar Denkanstöße.

Gegeben ist ein Server mit Windows 2022. Direkt auf der Maschine laufen der Hyper-V mit drei Maschinen (DC, File-Server, Linux) und eine SQL-Datenbank von Gupta (SQLBase).

Die Maschine ist relativ aktuell und besteht im Groben aus folgenden Komponenten:

ASUS SERVER P12R-E/10G-2T
CPU Intel Xeon E-2356G/3.2 GHz
64 GB RAM, 2x DDR4 32GB, PC3200, ECC/UB
RAID10 inkl. Spare Drive, 5 ESSD 2.5" 1.92TB Samsung PM1643a SAS3
BC MegaRAID 9560-8i PCIe x8 SAS

Angebunden ist die Maschine über einen der zwei 10GB-Netzwerkcontroller an einen HPE Aruba-Switch 1960 24G 2XT 2XF JL806A ebenfalls an einen der 10GB-Ports. Der 10GB-Link steht und er arbeitet fehlerfrei.

Die Arbeitsstationen haben alle folgende Eigenschaften:

CPU Core i7-1165G7 (bis zu 4.7 GHz)
16 GB SO DDR4-RAM,
SSD 500GB M.2 NVME SSD
WLAN, 1x LAN 10/100/1000
Windows 11 Pro

Angebunden sind alle Arbeitsstationen über LAN mit 1Gbit/s.

Gestern stellten wir fest, dass die Arbeitsstationen verhältnismäßig langsam auf die SQL-Datenbank zugreifen. Hierbei handelt es sich um ein ERP-System, welches die Geschäftslogik lokal abwickelt. D. h. es werden u. U. viele Daten abgerufen. Dabei kommunizieren die ERP-Clients über TCP mit dem Datenbankserver.

Für die ersten Tests haben wir uns einen ERP-Bericht ausgesucht und die Ausführungszeit gemessen:

An den Arbeitsstationen braucht der Bericht 50 Sekunden.
Direkt auf dem Server braucht der Bericht dagegen 10 Sekunden.
Auf dem virtuellen File-Server braucht der Bericht ebenfalls 10 Sekunden.

Also auf dem Server (virtuell oder direkt auf der Maschine) läuft das ERP-System fünfmal schneller als auf einer Arbeitsstation.

Im Netzwerk sind sowohl beim Switch als auch beim Server und den Arbeitsstationen die „Jumbo Frames“ bzw. „Jumbo-Pakete“ mit einem Wert von 9014 Byte eingestellt, was bei der Übertragung von großen Dateien im Netzwerk zu einem spürbaren Boost führte.

Nun meine Fragen:

Ist es bekannt, dass TCP-Anwendungen (in unserem Fall die SQL-Datenbank) Probleme mit Jumbo-Pakets haben? Wenn es so wäre: Warum ist die Ausführung auf dem Server (Maschine oder virtuell) fünfmal schneller? Hier kommunizieren die ERP-Clients ebenfalls über TCP mit der Datenbank .

Wir haben einige Netzwerkdrucker, die keine Jumbo-Pakets kennen – die funktionieren aber wie gewohnt. Kann das zu diesen Problemen führen?

Wir werden diese Jumbo-Pakets testhalber abschalten und zum Standard zurückkehren, um dann die Geschwindigkeit des ERP-Systems zu untersuchen. Sollte das aber nichts bringen, wie sollen wir am besten vorgehen?

Ich weiß es 😉 – einen Netzwerkspezialisten konsultieren. Wir möchten aber an diesem Netzwerk etwas lernen und freuen uns auf eure Vorschläge.

Danke + LG

René

Content-Key: 3015030524

Url: https://administrator.de/contentid/3015030524

Ausgedruckt am: 03.07.2022 um 18:07 Uhr

Mitglied: ukulele-7
ukulele-7 08.06.2022 um 08:34:14 Uhr
Goto Top
Warum läuft eine SQL DB direkt im Hypervisor? Das gehört auf eine VM oder auf eine dedizierte Hardware. Auch die Windows Lizenz lässt das so nicht zu. Ich vermute das der Hypervisor selbst im Netzwerk eventuell anders priorisiert wird als seine VMs aber das wäre reine Spekulation. Erstmal sollte das Setup supported sein.
Mitglied: fisi-pjm
fisi-pjm 08.06.2022 um 08:44:46 Uhr
Goto Top
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
Mitglied: temuco
temuco 08.06.2022 um 08:53:03 Uhr
Goto Top
Warum läuft eine SQL DB direkt im Hypervisor?
Aus Geschwindigkeitsgründen – sie soll möglichst direkten Zugriff auf die Hardware haben.

Das gehört auf eine VM oder auf eine dedizierte Hardware.
In der Regel ja. Hier geht es aber um 5 Arbeitsplätze und dafür noch eine Maschine, die ständig läuft, ist nicht erwünscht. Ansonsten macht der DC nur ein bisschen AD und der File-Server speichert ein paar Word- und Excel-Dokumente. Da kann man schon die SQL-DB auf dem Blech installieren.

Auch die Windows Lizenz lässt das so nicht zu.
Hier bin ich mir nicht sicher: Beim Standard ist von Rollen die Rede – ist auch damit eine Datenbank eines Drittherstellers gemeint? Beim Datacenter dürfte das egal sein.

Erstmal sollte das Setup supported sein.
Was heißt das? Technisch dürfte das möglich sein. Schließlich mache ich nichts anders, wenn ich eine Extra-Maschine für die SQL-DB nehmen würde.

Mich interessiert auf jeden Fall, warum es zu diesen Differenzen kommt.

Danke und LG

René
Mitglied: Looser27
Looser27 08.06.2022 aktualisiert um 09:06:58 Uhr
Goto Top
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
Mitglied: unbelanglos
unbelanglos 08.06.2022 um 09:06:22 Uhr
Goto Top
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?
Mitglied: ukulele-7
ukulele-7 08.06.2022 um 09:13:34 Uhr
Goto Top
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.
Mitglied: chiefteddy
chiefteddy 08.06.2022 aktualisiert um 09:16:50 Uhr
Goto Top
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. face-smile

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
Mitglied: temuco
temuco 08.06.2022 um 09:15:06 Uhr
Goto Top
Zitat von @Looser27:

Moin,

welche SQL- Version läuft bei Dir?

11.7.4 10718

Hängt eine Firewall zwischen SQL und Clients? Evtl. IPS/IDS hier aktiv?

Bis auf die Windows-Firewall keine. Die Windows-Firewall hat auch eine Ausnahme für den verwendeten Port aus dem vom LAN stammenden Requests.

Welche AV Lösung läuft auf dem Server und den Clients? Sind hier die korrekten Ausnahmen für den SQL gesetzt?

Der AV kommt noch und soll der "Antivirus Pro" von Securepoint werden. Zurzeit läuft der Defender von Microsoft in den Standardeinstellungen.
Mitglied: temuco
temuco 08.06.2022 um 09:20:13 Uhr
Goto Top
Zitat von @unbelanglos:

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?

Die SQL-Datenbank auf dem Server horcht auf einem Port (standardmäßig 2155) und nimmt darüber die Befehle des Datenbank-Clients entgegen. Das ERP-System nutzt für die Kommunikation den Datenbank-Client – also es handelt sich nicht um eine reine dateibasierende Datenbanklösung wie Access & Co. – so viel Daten werden nicht bewegt.
Mitglied: unbelanglos
unbelanglos 08.06.2022 um 09:25:41 Uhr
Goto Top
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
Mitglied: chiefteddy
chiefteddy 08.06.2022 um 09:32:02 Uhr
Goto Top
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
Mitglied: temuco
temuco 08.06.2022 um 09:36:10 Uhr
Goto Top
Zitat von @unbelanglos:

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

Vom Hören/Lesen her, aber ehrlicherweise nie benutzt. Das wird sich höchstwahrscheinlich jetzt aber ändern. face-smile Danke!
Mitglied: unbelanglos
unbelanglos 08.06.2022 um 09:41:05 Uhr
Goto Top
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.
Mitglied: temuco
temuco 08.06.2022 um 09:45:00 Uhr
Goto Top
Zitat von @chiefteddy:

Ich glaube nicht, dass der ERP-Client (nicht DB-Client!!) direkt mit der DB kommuniziert.

Der ERP-Client spricht den DB-Client an und dieser übers Netz die SQL-DB. Es handelt sich (leider) nicht um eine ASP- oder sonstige Anwendung, bei der noch eine Schicht dazwischen liegt. Das ist auch der Grund, dass verhaltensmäßig viele Daten übers Netz fließen.

Das ERP-System gibt es seit ca. 30 Jahren – damals (Windows 3) gab es keine Drei-Schichten-Anwendungen, wie es heute üblich ist. Es wird aber daran gearbeitet, was aber das jetzige Problem kurzfristig nicht löst.

Das ERP-System heißt ISEntial.

Danke und lG

René
Mitglied: SachsenHessi
SachsenHessi 08.06.2022 um 09:48:57 Uhr
Goto Top
Kommunizierst Du über Named Pipes oder TCP/IP ?
Mitglied: temuco
temuco 08.06.2022 um 09:52:27 Uhr
Goto Top
Zitat von @SachsenHessi:

Kommunizierst Du über Named Pipes oder TCP/IP ?

TCP, Port 2155 – auch auf dem Blech und den virtuellen Maschinen so eingestellt.
Mitglied: unbelanglos
unbelanglos 08.06.2022 um 09:57:15 Uhr
Goto Top
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.
Mitglied: aqui
aqui 08.06.2022 um 09:59:52 Uhr
Goto Top
die keine Jumbo-Pakets kennen
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.
Mitglied: temuco
temuco 08.06.2022 um 10:05:45 Uhr
Goto Top
Zitat von @unbelanglos:

Ich lese und verstehe den Satz:

Das ist lediglich für die Ablage gemeinsam verwendeter Dateien und hat mit dem Datenbankzugriff nichts zu tun. Die Datenbank ist nur über den Client (TCP/Port) erreichbar.
Mitglied: temuco
temuco 08.06.2022 um 10:13:27 Uhr
Goto Top
Zitat von @aqui:

die keine Jumbo-Pakets kennen
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.

Danke, so ist bisher mein Verständnis gewesen. Ich bin aber kein Experte auf diesem Gebiet und so frage ich lieber einmal zu viel...

LG

René
Mitglied: unbelanglos
unbelanglos 08.06.2022 um 10:19:06 Uhr
Goto Top
Zitat von @temuco:

Zitat von @unbelanglos:

Ich lese und verstehe den Satz:

Das ist lediglich für die Ablage gemeinsam verwendeter Dateien und hat mit dem Datenbankzugriff nichts zu tun. Die Datenbank ist nur über den Client (TCP/Port) erreichbar.

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.
Mitglied: LordGurke
LordGurke 08.06.2022 aktualisiert um 10:51:24 Uhr
Goto Top
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.


Zitat von @unbelanglos:
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.

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.
Mitglied: chiefteddy
chiefteddy 08.06.2022 aktualisiert um 11:12:18 Uhr
Goto Top
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.
Mitglied: unbelanglos
unbelanglos 08.06.2022 um 11:07:47 Uhr
Goto Top
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.
Mitglied: LordGurke
LordGurke 08.06.2022 um 11:14:24 Uhr
Goto Top
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.
Mitglied: unbelanglos
unbelanglos 08.06.2022 um 11:28:59 Uhr
Goto Top
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.
Mitglied: Lochkartenstanzer
Lochkartenstanzer 08.06.2022 um 12:01:30 Uhr
Goto Top
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-. face-smile

  • 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
Mitglied: temuco
temuco 08.06.2022 um 12:22:01 Uhr
Goto Top
Zitat von @unbelanglos:

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.

Nein, das stimmt definitiv nicht. Der Client kann mit dem Datenbankserver über unterschiedliche Wege kommunizieren – dazu gehören NPIPES, APIPES, NETBIOS, TCP/IP usw. Dazu ist ein Treiber notwendig, der auf diesen Protokollen aufsetzt wie z. B. SQLBase Native Connectivity, ODBC, OLE DB Dataprovider, ADO-Mapping to SQLBase, .NET Dataprovider, JDBC, ORACLE usw.

Das ERP-System verwendet SQLBase Native Connectivity und .NET Dataprovider, welche als Kommunikationsprotokoll ausschließlich TCP/IP verwenden.

Der einzige Unterschied zu heutigen "modernen" Anwendungen besteht darin, dass die Serverschicht zwischen ERP-Client und Datenbankserver nicht vorhanden ist, so wie wir das von ASP-, PHP-, Java-Anwendungen usw. kennen. Diese Schicht gibt es historisch auf jedem Client, so dass der Datentransfer zwangsläufig größer ist als beispielweise der bei einer ASP-Anwendung der Fall wäre. Dennoch ist der Datentransfer in keiner Weise so hoch wie bei einer dateibasierenden Datenbankanwendung (z. B. Access).

Ich hoffe, das ist jetzt klar geworden.

LG

René
Mitglied: ukulele-7
ukulele-7 08.06.2022 um 13:59:28 Uhr
Goto Top
Zitat von @chiefteddy:

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.
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.
Mitglied: LordGurke
LordGurke 08.06.2022 um 15:33:21 Uhr
Goto Top
Zitat von @unbelanglos:

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

Ich zitiere aus der verlinkten Studie:
Higher transmission time for jumbo frames is a non-issue for modern faster network cards. For instance, serialization delay of a 9K frame on a GE network is less than the serialization delay of a 1500 byte packet on a 100 Mbps network.

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 face-wink
Deshalb sagt das Conclusio des Paper auch:

Our evaluations show that jumbo frames are advantageous to applications like file transfer and Hadoop MapReduce.
For a tiered web service, jumbo frames can lead to increase in response time with Nagle algorithm enabled on the system.
But with Nagle disabled, it performs as well as with regular Ethernet frames.
All of the above observations highlight that turning on jumbo frames can be beneficial for data centers in general.


Die angesprochenen Probleme aus superuser.com:

If a latency-sensitive packet ends up being queued up behind a full-size frame for access to the medium, it takes 6x as long to get on the medium if that full-size frame is a 9kB jumbo frame rather than a standard 1500 Byte frame.

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.

Daher sind auch so Einwürfe wie "Path MTU Discovery" total hohl, weil davon UDP Verbindungen profitieren und weniger TCP.

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.
Mitglied: unbelanglos
unbelanglos 08.06.2022 um 17:54:17 Uhr
Goto Top
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.
Mitglied: ipzipzap
ipzipzap 08.06.2022 um 19:03:54 Uhr
Goto Top
Hallo,

Zitat von @unbelanglos:
Das ist lediglich für die Ablage gemeinsam verwendeter Dateien und hat mit dem Datenbankzugriff nichts zu tun. Die Datenbank ist nur über den Client (TCP/Port) erreichbar.
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.

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
Mitglied: Vision2015
Vision2015 08.06.2022 um 19:08:54 Uhr
Goto Top
Moin...
Zitat von @temuco:

Warum läuft eine SQL DB direkt im Hypervisor?
Aus Geschwindigkeitsgründen – sie soll möglichst direkten Zugriff auf die Hardware haben.
das ist blödsinn...

Das gehört auf eine VM oder auf eine dedizierte Hardware.
In der Regel ja. Hier geht es aber um 5 Arbeitsplätze und dafür noch eine Maschine, die ständig läuft, ist nicht erwünscht. Ansonsten macht der DC nur ein bisschen AD und der File-Server speichert ein paar Word- und Excel-Dokumente. Da kann man schon die SQL-DB auf dem Blech installieren.

Auch die Windows Lizenz lässt das so nicht zu.
Hier bin ich mir nicht sicher: Beim Standard ist von Rollen die Rede – ist auch damit eine Datenbank eines Drittherstellers gemeint? Beim Datacenter dürfte das egal sein.

Erstmal sollte das Setup supported sein.
Was heißt das? Technisch dürfte das möglich sein. Schließlich mache ich nichts anders, wenn ich eine Extra-Maschine für die SQL-DB nehmen würde.

Mich interessiert auf jeden Fall, warum es zu diesen Differenzen kommt.
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?
Das ERP-System verwendet SQLBase Native Connectivity und .NET Dataprovider, welche als Kommunikationsprotokoll ausschließlich TCP/IP verwenden.
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


Danke und LG

René

Frank
Mitglied: chiefteddy
chiefteddy 08.06.2022 um 19:43:13 Uhr
Goto Top
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?

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
Mitglied: Lochkartenstanzer
Lochkartenstanzer 08.06.2022 um 19:48:49 Uhr
Goto Top
Zitat von @chiefteddy:

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

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

lks
Mitglied: chiefteddy
chiefteddy 08.06.2022 um 20:11:11 Uhr
Goto Top
Hier geht es aber um 5 Arbeitsplätze und dafür noch eine Maschine, die ständig läuft, ist nicht erwünscht.
Ansonsten macht der DC nur ein bisschen AD und der File-Server speichert ein paar Word- und
Excel-Dokumente. Da kann man schon die SQL-DB auf dem Blech installieren.

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.)

Da kann man schon die SQL-DB auf dem Blech installieren.

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
Mitglied: temuco
temuco 09.06.2022 um 09:59:07 Uhr
Goto Top
Zitat von @unbelanglos:

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


smb = small medium business
Mitglied: unbelanglos
unbelanglos 09.06.2022 um 10:01:13 Uhr
Goto Top
Ja, dann ist aber der embedded Webservice noch im Rennen.
Mitglied: goscho
goscho 09.06.2022 aktualisiert um 10:36:21 Uhr
Goto Top
Moin
Zitat von @chiefteddy:
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!
Das kann ich so unterstreichen.
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!
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.
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.
Der Server läuft doch sowieso schon, warum jetzt noch ein NAS daneben stellen?
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.)
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.
Mitglied: fisi-pjm
fisi-pjm 09.06.2022 um 10:57:12 Uhr
Goto Top
Zitat von @goscho:

Ich würde auch zuerst mal mit dem Hersteller der ERP-Lösung sprechen, an welcher Stelle Optimierungen möglich sind.
Meine Rede.

Mehr RAM gehört definitiv in den Server.
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
Mitglied: chiefteddy
chiefteddy 09.06.2022 um 14:02:34 Uhr
Goto Top
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.

Ich würde sogar die Fileserver-Rolle auf den DC packen.

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

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

noch eine Maschine, die ständig läuft, ist nicht erwünscht

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
Mitglied: Lochkartenstanzer
Lochkartenstanzer 09.06.2022 um 15:15:13 Uhr
Goto Top
Zitat von @chiefteddy:

Ich würde sogar die Fileserver-Rolle auf den DC packen.

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

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
Mitglied: goscho
goscho 09.06.2022 um 15:29:04 Uhr
Goto Top
Zitat von @chiefteddy:

Hallo @groscho,
Mir ist Redundanz wichtig und ich will nicht immer bei Wartungsarbeiten an Servern Spät- oder Nachtschichten machen bzw. das Wochenende dran geben.
Mir sind das meine Kunden schon wert. face-smile
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. face-big-smile
Das ist mir alle mal einen 2. DC wert.
Als nächstes kommst du vielleicht noch mit dem Märchen, dass es ohne DC auf Blech nicht geht.
Ich würde sogar die Fileserver-Rolle auf den DC packen.

Wie lautet der Spruch: Ein DC ist ein DC und nur ein DC.
Was für ein unsinniger Spruch. Wer hat den ausgegraben?
Mitglied: Lochkartenstanzer
Lochkartenstanzer 09.06.2022 aktualisiert um 15:34:21 Uhr
Goto Top
Zitat von @goscho:

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. face-smile

lks
Mitglied: chiefteddy
chiefteddy 09.06.2022 um 16:08:37 Uhr
Goto Top
Hallo @groscho.

Mir sind das meine Kunden schon wert.

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

Als nächstes kommst du vielleicht noch mit dem Märchen, dass es ohne DC auf Blech nicht geht.

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

Aber dann hat man allein für die redundanten DCs zwei Lizenzen "verballert".

Ü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) face-smile

Jürgen
Mitglied: goscho
goscho 10.06.2022 um 08:12:05 Uhr
Goto Top
Zitat von @chiefteddy:

Hallo @groscho.

Mir sind das meine Kunden schon wert.

Ich glaube, andersrum wird ein Schuh draus: Wochenend-Zuschlag 200%, Spät-/Nachtschicht 100% Aufschlag face-wink
Wieso kommst du darauf, dass ich das zu den von dir angegebenen Konditionen mache?
Evenuell hat man dafür ja sogar Verträge...
Als nächstes kommst du vielleicht noch mit dem Märchen, dass es ohne DC auf Blech nicht geht.

Kommt darauf an: Ist der Virtualisierungs-Host Mitglied der Domäne? Man sollte da schon mal nachdenken!
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.
Mitglied: chiefteddy
chiefteddy 10.06.2022 um 11:08:29 Uhr
Goto Top
Hallo @goscho,

Wieso kommst du darauf, dass ich das zu den von dir angegebenen Konditionen mache?

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.

Aber das weiß man natürlich nur, wenn man sich damit auch richtig beschäftigt und nicht nur
Sprüche in Foren bringt.

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
Mitglied: ultiman
ultiman 11.06.2022 um 02:32:09 Uhr
Goto Top
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
Mitglied: Vision2015
Vision2015 11.06.2022 um 07:14:41 Uhr
Goto Top
Moin...

als erstes würde ich mal die grundlagen des netzwerks prüfen, also mal sehen was Iperf3 so dazu sagt!
Es ist sogar denkbar, dass die Jumbo-Frames ursächlich sind, für deine Probleme. Die Jumbo-Frames gehören deaktiviert
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
Mitglied: Bitsqueezer
Bitsqueezer 13.06.2022 um 13:08:39 Uhr
Goto Top
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:

Zitat von @chiefteddy:
Eigentlich ist das die Ausnahme.
Die Struktur ist in der Regel Client --> Applikations-Server --> DB-Server

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.

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.

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
Mitglied: chiefteddy
chiefteddy 13.06.2022 um 19:40:19 Uhr
Goto Top
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.
Mitglied: Lochkartenstanzer
Lochkartenstanzer 13.06.2022 um 19:58:24 Uhr
Goto Top
Zitat von @chiefteddy:

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.

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
Mitglied: temuco
temuco 13.06.2022 um 20:33:14 Uhr
Goto Top
Zitat von @chiefteddy:

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.

Sorry, ich wollte eigentlich an dieser Grundsatzdiskussion nicht teilnehmen – mir ging es um eine andere Geschichte, die damit wahrlich wenig zu tun hat. Hier aber einige Punkte zur Einordnung:

  • Ob lizenzretchtlich etwas nicht 100% ist, hat in diesem Fall nicht wirklich mit der Technik zu tun: Die Hardware ist für die gestellte Aufgabe mehr als ausreichend und beim Einsatz einer Datacenter-Version, bei der ich beliebige Instanzen von Windows Server 2022 installieren darf, denke ich, dass Microsoft egal sein dürfte, wo ich schließlich den (schlanken) Datenbankserver installiere. Das nur nebenbei erwähnt, mit der Bitte, es nicht weiter zu vertiefen.

  • @chiefteddy, weil du etwas kennst und in dein technisches Verständnis passt, muss das nicht die einzige absolute Wahrheit sein. Ich kann dir eine Serie von Beispielen aufführen, bei denen der Client direkt mit der Datenbank spricht. Wie von jemandem anderen bereits erwähnt, ist das eine der schnellsten Möglichkeiten der Kommunikation zwischen Server und Client in einem LOKALEN Netz. Ich rede hier nicht von Access oder dBase, sondern von echten SQL-Datenbanksystemen wie MS-SQL-Server, ORACLE und eben in diesem Fall SQLBase. Datenhaltung bzw. -verwaltung inkl. Teile der Geschäftslogik über z. B. Stored Procedures bzw. Stored Commands laufen auf dem Server ab, der Rest macht der jeweilige Client, was den Server wiederum entlastet. Das ist in vielen Produkten auch noch heute so. Was du meinst sind Anwendungen, deren Geschäftslogik ebenfalls auf dem Server ausgeführt wird wie z. B. ASP, PHP, JSP usw. – das hat auch seine Berechtigung und bildet einen Standard insbesondere bei Internetanwendungen. Davon war nicht die Rede.

  • Ich möchte auch klar machen, dass das von mir beobachtete Verhalten auch unverändert bleibt, wenn man alle Netzwerkkomponenten ohne Jumbo-Frames fährt: Es ändert sich datenbanktechnisch nichts und das Netzwerk wird merklich langsamer insbesondere beim Transfer großer Datenmengen wie. z. B. dem Kopieren großer Dateien.

  • Ich bin noch nicht dazugekommen, mir den Datentransfer auf TCP- und Datenbankebene genau anzuschauen – ich habe zurzeit einfach zu viel Arbeit. Das hole ich aber bald nach.

  • Gleich aufgebaute Systeme mit weit mehr konkurrierenden Anwendern laufen auf älterer und schwächerer Hardware zum Teil geschmeidiger. Daher vermute ich, dass es nicht wirklich am ERP-System bzw. seiner Datenbank liegen kann.

Danke für die vielen Tipps und die rege Teilnahme!

LG

René
Mitglied: Bitsqueezer
Bitsqueezer 14.06.2022 um 00:00:50 Uhr
Goto Top
Hallo,

@chiefteddy:
die Server-Applikationen, die ich kenne und mit denen ich gearbeitet habe, waren genau so strukturiert, wie ich es beschrieben habe.

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.

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???

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... face-smile
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... ;)

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.

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.

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.

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
Mitglied: aqui
aqui 27.06.2022 um 14:57:53 Uhr
Goto Top
Wenn es das denn nun war bitte dann auch deinen Thread hier als erledigt schliessen!
Mitglied: temuco
temuco 27.06.2022 um 23:45:44 Uhr
Goto Top
Zitat von @aqui:

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

Kann ich machen, aber einige Tests stehen noch an. So ganz geschlossen ist es dann nicht, oder?
Mitglied: aqui
aqui 28.06.2022 um 09:10:58 Uhr
Goto Top
Sofern dann noch Test Feedbacks kommen...?!
Mitglied: temuco
temuco 28.06.2022 um 09:32:24 Uhr
Goto Top
Zitat von @aqui:

Sofern dann noch Test Feedbacks kommen...?!

Schrieb ich schon.

Wir haben den Switch unter Verdacht. Es handelt sich um folgendes Modell:

HPE Aruba 1960 24G 2XT 2XF

Wir haben testhalber einen Billigst-8-Port-Switch TP-Link irgendwas drangehängt und die Performance stieg deutlich.

In den nächsten Tagen versuchen wir, der Sache weiter auf die Spur zu kommen.

LG

René
Mitglied: LordGurke
LordGurke 28.06.2022 um 12:00:25 Uhr
Goto Top
Zitat von @temuco::
HPE Aruba 1960 24G 2XT 2XF

Wir haben testhalber einen Billigst-8-Port-Switch TP-Link irgendwas drangehängt

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.
Mitglied: temuco
temuco 28.06.2022 um 13:12:30 Uhr
Goto Top
Danke. Am Switch und dem Server ist es deaktiviert. Ich muss noch an den Arbeitsstationen nachschauen.