mySQL>lost conection>Ausführung geziehlt anhalten

Hallo Herr Stark,
ich nutze einen mySQL to mySQL Flowheater. Es werden mehrere joins über verschiedene Tabellen gelegt. Ich habe schon auf der Read und Write Seite die CommandTimeout auf 0, sowie die Connection Timeout auf 600 gestellt. Das ganze dauert ziemlich lange und ich erhalte regelmäßig "Lost connection to MySQL server during query" Fehlermeldung. Vermutlich liegt das am Server?

Kann man das evtl. so lösen, dass der Stop Heater nach 100 Zeilen stopt und per batch an der gleichen Stelle wieder weitermacht?

Was die Sache sicher nicht vereinfacht ist, dass auf der Read Seite keine Tabelle, sondern eine Abfrage steht. Es gibt hier keine eindeutige ID.

Vielen Dank!

Hallo Christoph,

Die Meldung „Lost connection to MySQL server during query“ deutet mehr darauf hin, dass eine schlechte Netzwerkverbindung vorliegt, oder aber der MySQL Server komplett überlastet ist!

Für eine weitere Analyse bräuchte ich etwas mehr Informationen:

1. Sie schreiben, dass der Export erst nach x Zeilen Abbricht, wie lange dauert es bis der FlowHeater mit dem Export des ersten Datensatzes beginnt?


2. Über welches Netz verbinden Sie sich den mit Ihrem MySQL Server? Lokal / Internet evtl. VPN oder SSH und wie hoch ist die Bandbreite.


3. Können Sie sich die Auslastung des MySQL Servers während der Abfrage anzeigen lassen.


4. Auf welcher Hardware läuft der MySQL Server?


5. Wie viele Datensätze sind in den einzelnen Tabellen die Sie mit JOINS in der SQL Abfrage verknüpfen?

Hallo Herr Stark,
1. Es dauert ca 1. Minute, dann beginnt der Flowheater die Zeilen zu zählen.

2. Die Anbindung erfolgt per Lan 100Mbit.

3. Die Auslastung des mySQL Servers liegt bei ca 30%

4. Der Server ist ein virtueller Ubuntu Server 64bit mit 1GB Ram

5. wieviele Zeilen sich durch die Joins ergeben, weiß ich nicht genau, aber die Tabellen haben zwischen 50.000 und 300.000 Zeilen.

Weitere Fragen

1. Wie ist die darunter liegende Hardware für den virtuellen MySQL Server ausgelastet?


2. Bricht die Verbindung zur MySQL Datenbank immer an der gleichen Stelle ab?


3. Wie viele Datensätze konnten bisher immer mindestens exportiert werden?


4. Geht der Export von einzelnen Datensätzen eher flott oder können Sie pro exportieren Datensatz die Sekunden zählen?

Kein Problem
ich war jetzt nur mit etwas anderem beschäftigt...

also ich habe noch mal intensiver getestet:

-Die Hardware mit der virtuellen mySQL Maschine läuft mit ~80% Auslastung, die virtuelle Maschine selbst mit ca. 70%.
-Die zweite Hardware, auf der der virtuelle Flowheater läuft, läuft auf ca. 30% Auslastung. Die virtuelle Flowheater Maschine auch ca. 70%.

-Der Flowheater bricht nicht immer an der gleichen Stelle ab. Er schafft knapp 1000 Zeilen (mal 850 und ein ander mal 950).

-Je nach komplexität ist das Verhalten am Start etwas verschieden. Bei einem Query dauert es ca. 1 Minute bis die erste Zeile bearbeitet wird. Dann geht es ca. im Sekundentakt oder noch etwas kürzer weiter, so lange bis er abbricht. Bei einem anderem, aber ähnlichem Query läuft er von Beginn an mit ca. 2 sec. pro Zeile so lange bis er abbricht.

- Ganz einfache querys laufen richtig schnell.

Das manche SQL Abfragen lange für die Ausführung benötigen ist normal. Die Zeit benötigt der MySQL Server um die Daten zusammen zu stellen. Aber dass ca. 2 Sekunden dann nochmal pro gelesenen Datensatz aus der MySQL Tabelle vergehen kann ich mir jetzt nicht vorstellen. Wir in der FlowHeater Definition pro Datensatz noch etwas gemacht? Wenn ja bitte mal nur einen einfachen Export in eine CSV Textdatei durchführen. Tritt hierbei auch das gleiche verhalten auf?

Wie ist die Auslastung des MySQL InnoDB Buffers?

Können Sie mal versuchen die MySQL Datenbank auf einem anderen evtl. physikalischen MySQL Server zu legen.

Hallo,
ich nutze im Flowheater noch mehrere SQL-Heater mit individuellen querrys, welche Daten aus weiteren Tabellen holen.

Die Situation hat sich jetzt etwas verändert. Ich habe die Einstellungen der READ/ WRITE wie folgt geändert:

AutoCommitAfter: 2
Command Timeout: 0
Connection Timeout: 3000

Durch die Änderung von "AutoCommitAfter" läuft das ganze jetzt wesentlich schneller (mehrere Zeilen pro sec.) durch, bricht aber trotzdem fast immer ab.

Der Export in eine Textdatei ist nicht ganz vergleichbar, da ich auf der write Seite eine UID aus 5 Feldern bilde.

Das ganze ist in etwa so:

1. Flowheater Durchgang:
Reaad:
join über mehrere Tabellen > UID 5 Spalten > Write in Tabelle 2
(Baut die Tabelle auf, bzw. updatet neue Datensätze)

2. Flowheater Durchgang:
Read: aus Tabelle 2

die neuen Werte werden alle über SQL-Heater aus verschiedenen Tabellen gesucht und entsprechend eingefügt

Write in Tabelle 2
(die im ersten Durchgang hinzugefügten Datensätze werden jetzt vervollständigt)


Der erste Durchgang ist jetzt nach "AutoCommitAfter" durchgelaufen, aber der zweite mit den SQL-Heatern bricht immer nach ~1500 Zeilen ab.

Was mir jetzt noch aufgefallen ist, kurz bevor der Flowheater "rausspringt" läuft er etwas langsamer, ca. 1-2 sec. pro Zeile, wird noch mal schneller und gibt dann die Meldung Connection lost during SQL...

Es ist auf jeden Fall nicht so, dass der Flowheater vor dem rausspringen die 3000sec wie eingestellt abwartet.

Wo kann man die Auslastung des InnoDB Buffers anschauen?

Hallo Christoph,

Connection Timeout ist die Zeit die beim ersten Verbindungsaufbau gewartet wird bis die Verbindung zustande kommt.

Command Timeout ist die Zeit die der FlowHeater wartet bis nach der Ausführung der SELECT QUERY die Rückmeldung vom MySQL Server kommt, dass die Daten selektiert / zusammengesammelt wurden. Hier kann es je nach Komplexität der QUERY schon mal auch etwas länger dauern.

Sie schreiben dass Sie durch einen AutoCommit After = 2 eine Beschleunigung erzielt haben? Das ist sehr seltsam und deutet eigentlich darauf hin, dass die MySQL Datenbank hoffnungslos überlastet ist.

Hintergrund zu Transaktionen: Der FlowHeater verwendet Standardmäßig eine Große Datenbanktransaktion um Daten in die Datenbank zu schreiben bzw. zu aktualisieren. Dieses Vorgehen wurde einmal aus Sicherheitsgründen gewählt, wenn ein Fehler während des Import/Updates auftritt stellt die Datenbank automatisch den Zustand wie vor der Ausführung wieder her. Und zum anderen aus Performance Gründen. Eigentlich alle Datenbanken verwenden mittlerweile Cache Mechanismen und können hier locker mit 100.000 und mehr Insert/Updates problemlos umgehen.

Die Auslastung des konfigurierten InnoDB Buffers können Sie z.B. über die "MySQL Workbench -> Management -> MySQL Server Status" einsehen, siehe Screenshot.

Wie Sie ihrer Datenbank Beine machen dafür gibt es im Internet genügend Tutorials: InnoDB Performance Tuning Tips


MySQL Workbench InnoDB Buffer Verwendung