Blog-Leser Stefan K. hat mich per Mail kontaktiert, weil er sich vom Wissen der Leserschaft einen Tipp bezüglich des MySQL ODBC Connectors unter Windows einen Tipp erhofft. Nach einem Software-Update auf die Version 8.0.35 sind die Verbindungen auf die SQL-Datenbank plötzlich langsamer – aber nur unter einem Windows 10-Client. Vielleicht hat jemand einen Tipp.
Anzeige
Stefan schrieb mir per Mail, dass in seiner Umgebung eine kleine MySQL Datenbank im Unternehmen eingesetzt wird, welche Informationen für einen Produktkonfigurator enthält. Nichts Großes, das Ganze sei bereits seit Jahren im Einsatz, und wird von deren IT gepflegt sowie auch funktional immer mal wieder erweitert.
Client mit Excel und MySQL ODBC Connector
Die MySQL-Datenbank wird unter Windows als System-DSN im OBDC-Datenquellen-Administrator eingebunden. Dann wird Excel verwendet, um aus der Datenbank als Datenquelle entsprechende Informationen abzurufen. Stefan schreibt, dass es mal wieder Zeit für ein Update der SQL-Datenbank-Software auf die aktuellste Version von MySQL gewesen sei, auch weil die neueren Versionen Sicherheitslücken ausräumen.
Update von MySQL gemacht
Ausgangssituation waren folgende Konstellationen für die MySQL-Datenbank auf einem Server und die Windows 10-Clients:
- Server: MySQL 8.0.30 Windows Server 2016 Datacenter
- Client: Windows 10 Enterprise 22H2 + MySQL ODBC Connector in der Version 8.0.30 (32bit Treiber) + Office 2019 LTSC (32bit) / (Windows und Office auf aktuellem Stand)
Im ersten Schritt wurde die Datenbanksoftware MySQL von der Version 8.0.30 auf die Version 8.0.35 aktualisiert. Dies verursachte keinerlei Probleme. Alle Clients verbinden sich über den MySQL ODBC-Connector in der Version 8.0.30 normal und alles funktionierte wie immer. Der initiale Datenabruf über den MySQL ODBC-Connector benötigt laut Stefan so ca. 5 Sekunden. Das sei ein Zeitraum mit dem die Anwender noch gut leben können.
Plötzlich extrem langsame Zugriffe
Stefan hat dann im Anschluss auf seinem PC unter Windows 10 den ODBC-Connector von der Version 8.0.30 auf die 8.0.35 angehoben. Laut seiner Aussage funktioniert technisch alles einwandfrei. Nur ist die ODBC-Verbindung auf die MySQL-Datenbank nun merklich langsamer. Statt der bisherigen 5 Sekunden dauert der initialen Abruf nun ca. 25 Sekunden (Anstieg um den Faktor 5).
Ursachensuche bisher ergebnislos
Der Blog-Leser hat dann verschiedene Prüfungen durchgeführt, um die Fehlerursache einzugrenzen. Die betreffenden Schritte beschreibt Stefan so:
- Installiere ich die alte Version des ODBC-Connectors wieder, dann ist alles schnell
- Installiere ich die neue Version des ODBC-Connectors auf einem anderen PC, dann ist dieser ebenfalls langsam
- Installiere ich die alte Version ODBC-Connectors auf diesem anderen PC, so ist dieser wieder schnell
- Mit der Datenbank in der Version 8.0.30 ist der neue ODBC-Treiber 8.0.35 ebenfalls langsam, die alte Version 8.0.30 weiterhin schnell
- Die Vorgängerversion des ODBC-Treibers 8.0.33 ist ebenfalls langsam (die 8.0.34 wurde nie veröffentlicht)
Kurz gesagt vermutet Stefan die Ursache für die langsamen ODBC-Zugriffe irgendwo im ODBC-Treiber und hat bereits testweise:
- Das Logging der SQL-Anfragen auf dem Client aktiviert -> Keine Fehler / Auffälligkeiten
- SSL/TLS für die Verbindung auf deaktiviert gesetzt -> Kein messbarer Unterschied zwischen verschlüsselt und unverschlüsselt
- Im Internet nach einer Lösung gesucht, Bugtracker Oracle, MySQL Forum. Bisher nichts das passte.
In den Einstellungen des ODBC-Treibers sind zwischen Version 8.0.30 und 8.0.35 laut Aussage des Leser keine Unterschiede zu erkennen. Fast alles läuft auf "Default". Stefan vermutet, dass die Krux trotzdem dort liegen könnte, falls sich im Standard etwas geändert hat, dass sich massiv auf die Performance auswirkt. Stefan hofft hier auf das Wissen der Leserschaft und fragt, ob jemand von euch das Problem schon mal gehabt und einen Tipp hat, woran es liegen könnte?
Anzeige
2015
Werden jetzt 5mal mehr Daten übertragen oder hängt die Anfrage oder entstehen seltsame Lücken im Daten Verkehr oder der CPU-last?
(So rein generell wäre mir 5sec Wartezeit eigentlich zu viel, auch wenn die User leidensfähig sind(was sollen sie auch machen? es ist ja nicht sooo schlimm einmal am Tag 5sec warten zu müssen), es erzeugt Frust.)
Es scheint ja offensichtlich ein Problem des Clients zu sein, weil egal ist, welche Version der Server hat.
Auch ist das Problem seit Version 8.0.33 voll reproduzierbar, hin und her. Das ist schön.
Man müsste einfach nur in der History nachsehen,
was sich im Treiber geändert hat…
angeblich soll es Performance Verbesserung gegeben haben…
Kann es evtl. am UTF8MB4 liegen? (Das klingt irgendwie nach einem Recht altem System. )
Ist die Spalten Statistik aktiv?
( Es gab es schon, dass ein Feature nicht zu funktionieren schien.
Da es kein Nachteil zeigte blieb es drin und irgendwan kam die Neue Version und auf einmal lief das Feature und brauchte Ressourcen…)
Wie läuft es mit dem MariaDB ODBC conector ? (nur so als Test.
Wenn das auch schnarcht würde ich mir mal ansehen was die Applikation macht.)
Die Daten in der Datenbank sind identisch und es werden die exakt gleichen SQL-Befehle zum Abruf der Daten verwendet. Die Datenbank beinhaltet z.B. technische Spezifikationen von Motoren (Spannung, Frequenz, Leistung, Energieeffizienzklassen, Zertifizierungen wie UL/CSA oder CCC, usw.). Die Daten sind quasi statisch. Nur alle paar Wochen gibt es mal Updates.
-> Die anderen Punkte sehe ich mir an, auch den Connector von MariaDB werde ich testen.
Ja, das ist doch "optimalst".
Dann besteht die Möglichkeit, einfach mal mit einem Port mirror mitlesen, ob die beiden connector Versionen etwas anderes machen und was.
Aber nicht nur auf den DatenblattbServer bezogen mit schreiben.
So, nach einigen Tests wird es wohl der Connector von MariaDB werden. Dieser läuft ohne Probleme mit der MySQL DB, gefühlt sogar noch einen Tick schneller. Mittelfristig stellen wir dann auch die Datenbank auf MariaDB um. Allen vielen Dank für die Hinweise und Anregungen.
Ein Zeitunterschied zwischen 5 und 25sec ist nicht nur ein Faktor 5, sondern sind auch 20sec.
Und 20sec ist ein Wert den man gerne mal bei Netzwerke, DNS, eingesetzt hat.
Wenn das Problem Richtung Verbindungen geht,
evtl. mal gucken ob was mit
"connect timeout" "interactive mode" etc.
zu bewegen wäre.
Natürlich seltsam, das das bei der alten Version noch funktioniert hat.
Gegen Windows 11 als Client wurde das noch nicht getestet?
Aber kann ja egal sein, weil das so klar mit der Connector Version verknüpft scheint.
DNS können wir ausschließen. Der Server hat eine fixe IP-Adresse und die ist in den Verbindungeinstellungen des Connectors fest eingetragen. Somit kein DNS im Spiel. Mit Einstellungen wie die interactive mode oder automatic reconnect haben wir auch bereits gespielt. Leider keine Auswirkungen.
Die Verbindung ist auch binnen Millisekunden aufgebaut, daher gehe ich nicht davon aus, dass es dort Probleme mit Timeout gibt.
Guten Morgen,
erstmal vielen Dank an Günter, dass er das Thema hier im Blog gebracht hat.
Oben im Beitrag steht, dass das Problem nur einen Windows 10 Client betrifft. Dies ist so leider nicht korrekt. Wie weiter unten geschrieben ist jeder Client betroffen, welcher einen neueren Connector in der Version 8.033 oder 8.0.35 erhält. Sobald die alte Version 8.0.30 wieder installiert wird ist alles wieder so schnell wie vorher.
Blöde Frage: Wurden sämtliche Virenscanner auf dem Client deaktiviert?
Es ist ja ein Treiber und da wird dann die DLL erneuert… Je nach Signatur überprüft der Virenscanner dann die Verbindung, gerade der Windows Defender hat da manchmal ein seltsames Verhalten.
Ja, ich habe testweise auf meine PC einmal alle Schutzfunktionen abgeschaltet und dies hatte keinen Einfluss auf die Performance.
Keine Ahnung was Excel da treibt, aber so allgemein gibt es einiges zu beachten:
https://www.progress.com/tutorials/odbc/performance-optimized
An anderer Stelle wurde auf tracing und logging hingewiesen, das natürlich ausgeschaltet sein sollte. Vom Treiber gibt es auch eine Debug-Version, die natürlich langsamer ist.
Wenn 5s als normal empfunden wird, sehe ich aber ein grundsätzliches Problem mit der Art des Datenzugriffs
Die fünf Sekunden treten einmalig beim Öffnen der Arbeitsmappe auf. Ab diesem Punkt kann ohne merkliche Verzögerungen gearbeitet werden. In der Regel haben die Leute das länger offen. Ich sage mal so: Ein Client vom ERP-System oder die CAD-Umgebung benötigen zum Programmstart auch ihre Zeit. Mache ich das morgens auf und nachmittags wieder zu, so ist das dann weniger ein Problem.
Über was für eine Abfrage bzw. Datenmenge reden wir denn da? Ist das eine einzige Abfrage die tausende Datensätze zurückliefert? Falls ja: das klingt so, als wäre der Cursor mit dem die Datensätze abgearbeitet werden nicht lokal, was zur Folge hat, dass beim Durchlauf und Zugriff auf die Datensätze diese einzeln vom Server angefragt und über das Netz transportiert werden, anstatt unmittelbar nach Ermittlung im Block zum Client übertragen zu werden.
Da ich aber den zu Gunde liegenden Code nicht kenne, ist das nur ein Schuss ins Blaue.
und diese 5sec dauern jetzt 25sec.
Dann wurde wohl die ganze Tabelle lokale kopiert und es wird nur noch mit der lokalen Kopie gearbeitet.
Das doch super.
Einfach mitschreiben was in den Beiden Fällen passiert.
Es muss ja eigentlich dasselbe sein.
Und da wird nicht zwischen der 30 und 35 soviel umgestellt worden sein.
In diff rein, und gucken was der Unterschied ist.
wäre die billigste Methode.
So hat man zwar noch keine Lösung, aber vielleicht die Ursache.
ich dachte eher daran, dass, auch warum auch immer, irgendwas beim DNS abgefragt werden soll, und kein DNS antwortet.
Es könnte auch sein, das Irgendwas bei der .30 per broadcast aufgelöst wurde und jetzt nur noch per DNS,
da der MySql Server garnicht die Ursache ist(die Version ist ja egal)
so als Beispiel:
Es gab auch früher mal Software, die den DNS "forwärts" fragte, ihm die IP Adresse in eine IP Adresse umzurechnen, was ja nicht funktioniert, aber nicht auffiel, weil man ja schon die IP hatte, und wer fragt schon Fehler Codes ab? Macht die Software nur unübersichtlich… Es war dann immer eine leichte Verzögerung zu spüren, da aber alles funktionierte blieb es dann so.
(Man hätte eine Prüfung einbauen müssen,ob der Host name schon .8 ist, ehe man den DNS fragt, der keine IP Nummer erwartet,wenn er eine IP Nummer liefert…)
Ich glaube nicht daß das hier der Fall ist, es ist nur ein Beispiel was passieren kann.
Das Problem ja prima isoliert werden.
Ich würde ganz tump mal das HTTPS abschalten (ist ja nur Labor) und mit wireshark gucken, was da so getrieben wird. Irgendwas muss ja anders sein.
Vorher mal den Connector von MariaDB probieren, dass soll ja kompatibel sein…
Ich stolpere hier über die Versionsnummer. 8.1.0 ist eigentlich für Produktionsumgebung empfohlen, aktuell ist 8.2.0. Sind die Systeme noch alle 32bit?
8.1.0 und 8.2.0 sind vollständig 64bit. Für diese Versionen gibt es auch keine 32bit Treiber mehr. Der 8.0.x Versionzweig steht unter LTS und wird noch bis 30 April 2026 mit Updates versorgt.
Nur zur Info
hast du auf dem Server die x64bit installiert? Ich vermute das auf server 2016 garnichts anderes geht
64bit
32bit
Hier findest Du die Änderungen am Connector 033, da es da ja schon Auftritt ist 035 uninteressant
Auch die Änderungen für 032 und 031 könnten es auslösen (sind dort anwählbar in der Navi links), da es ja laut aussage ab 030 funktioniert.
Ich würde den Datenverkehr mal mitschneiden mit tcpdump oder wireshark da findet man meistens gute infos.
Könnte ein Timeout sein, wird versucht etwas zu nutzen was nicht klappt und dann erst das alte genutzt wird, zurückgeschaltet.
In den Connectoränderungen sind teilweise config und default Änderungen aufgeführt, vielleicht nach dem Update einfach mal ne alte config nutzen mysql restart und schauen, ob man damit das Problem eingrentzen kann.
Welches TLS unterstützen Client und Server und welche nutzen dann Client und Server nach Aufbau der Connection (evtl. ein versuch etwas höheres zu nutzten und dann ein zurückschalten auf eine andere Version)
https://learn.microsoft.com/de-de/windows/win32/secauthn/protocols-in-tls-ssl–schannel-ssp-
Es kann dabei auch bei der gleichen Version an dem Versuch zunächst ein nichtvorhandnen CipherSuite zu nutzen scheitern.
Bitte mal auf Server und Client mit der IIS Crypto GUI prüfen welche Versionen aktiviert und drauf sind:
http://www.nartac.com
Mal das Zertifikat was die mysqlserverversion dafür nutzt angesehen?
Es wäre Interessant ob es auch auf Win11 Clients Auftritt, die sind aber x64, da der Connector 8.0.35 aber nur x32 ist vielleicht mal von win11 mit dem Connector 8.2.0 x64 versuchen ob es dann klappt, vielleicht geht der dann auch bei nem 8.0.35 server mit x64, denn der Server müsste bei dir doch x64 sein.
"Improved JSON data character support by presenting JSON columns as utf8mb4 strings instead of binary data.
This change also affected the following *ODBC* functions:
SQLColumns() *result* set changes:
DATA_TYPE (column #5) and SQL_DATA_TYPE (column #14) are now SQL_LONGVARCHAR or SQL_WLONGVARCHAR depending on the driver type (ANSI or UNICODE);
*previously* it was always SQL_LONGVARCHAR.
COLUMN_SIZE (column #7) and BUFFER_LENGTH (column #8) are now 4294967295;
previously they were NULL.
CHAR_OCTET_LENGTH (column #16) is now 4294967295; previously it was 0.
SQLDescribeCol() result parameter changes:…
"
4294967295 ist IIRC 0xffffffff aka "-1"
da kam früher 0.
Die haben dann doch an der Schnittstelle geschraubt.
Irgendwie grummelt es micn jetzt noch mehr beim Wort UTF8MB4.
Nicht dass da jetzt ständig hin und her konvertiert wird.
Ein einfacher Trick um zu sehen ob da viel gerechnet wird, ist einfach die 230V Stromaufnahme zu messen.
Was Idle anzeigt ist ja rel. wertlos geworden.
Wenn man etwas installieren möchte/ kann wäre auch Hardware Moni möglich um die Stromaufnahme zu testen.