Ankündigung

**gaert** · 22.05.2017, 20:59

Offenbar öffnet ein EXEC-LBS ständig neue mySQL-Verbindungen - ohne diese wieder zu schließen...

**Marha** · 22.05.2017, 21:18

Ich bekomme ca 100 Werte über UDP herein, jeder Wert über einen eigenen Port. Mit dem 805er Baustein filtere ich bei den Werten ein LF heraus und weise den Wert dann jeweils einer GA zu. Vermutlich passiert das ganze dann, wenn sich viele Werte gleichzeitig ändern. Und viele GAs gleichzeitig geschrieben werden. Wie kann ich das ganze entzerren, damit nicht so viele Datenbankzugriffe gleichzeitig auftreten?

**gaert** · 22.05.2017, 21:22

Das müssten die jeweiligen LBS-Entwickler beantworten - an EDOMI selbst liegt's jedenfalls nicht

**jonofe** · 22.05.2017, 22:12

Zitat von Marha Beitrag anzeigen

Ich bekomme ca 100 Werte über UDP herein, jeder Wert über einen eigenen Port. Mit dem 805er Baustein filtere ich bei den Werten ein LF heraus und weise den Wert dann jeweils einer GA zu. Vermutlich passiert das ganze dann, wenn sich viele Werte gleichzeitig ändern. Und viele GAs gleichzeitig geschrieben werden. Wie kann ich das ganze entzerren, damit nicht so viele Datenbankzugriffe gleichzeitig auftreten?

Was genau machst du denn mit dem 805er LBS bzgl. UDP? Der 805er führ doch einfach nur ein PHP Statement aus. Welchen PHP Code übergibst du dem Baustein?
Wenn du 100 UDP Verbindungen aufbaust, dann überrascht mich auch nicht mehr, dass der Squeeze LBS nicht mehr richtig funktioniert.

**Marha** · 23.05.2017, 05:52

Von einem externen Device bekomme ich Sensorwerte per UDP. Ich verwende den 278er LBS (UDP-Listener). An dessen Ausgang hängt ein 805er LBS, der den Befehl trim($E1) ausführt, weil die Strings, die per UDP hereinkommen mit einem LF abgeschlossen sind. An dessen Ausgang hängt die Ausgangsbox ungleich leer, wo der String in eine GA geschrieben wird. Das ganze ca 100 Mal. Leider bin ich, was Edomi und PHP angeht, noch ziemlich in den Anfängen. Vielleicht habe ich die falschen LBS kombiniert. Zu meinem Verständnis, an welcher Stelle ist denn ein Datenbankzugriff nötig? Doch erst, wenn die GA geschrieben wird oder schon vorher, wenn über UDP etwas empfangen wird?
Warum meinst Du, dass der Squeeze LBS nicht mehr funktioniert? Weil das System ausgelastet ist oder welchen Grund vermutest du?
Heute Nacht ist Edomi ohne jeglichen Fehlereintrag durchgelaufen.

**jonofe** · 23.05.2017, 06:17

Hast du 100 ausgänge? oder 100 UDP listener? Wenn dein Server keine SQL connections mehr aufbauen kann, dann funktioniert vermutlich kaum noch ein LBS.

**Marha** · 23.05.2017, 06:27

Ich habe 100 UDP-Listener LBS, da ich nur einen Ausgang des UDP-Listener verwenden kann. Wenn ich den UDP-Listener anpassen würde, dass er auf mehrere Ports hört und entsprechend mehr Ausgänge zur Verfügung stellt, würde das das Problem etwas entschärfen?

**jonofe** · 23.05.2017, 07:25

was genau sendet denn auf 100 verschiedenen UDP Ports? Kannst du vielleicht etwas genau erläutern, was du genau machst?

**jonofe** · 23.05.2017, 07:30

Ich denke das Problem liegt im UDP Listener. Habe mal kurz reingeschaut. Ist ja ein EXEC Daemon LBS, welcher 10x pro Sekunde aufgerufen wird. Außerdem wird innerhalb der Schleife ein sql_connect() gemacht. Das ganz nun multipliziert mit 100 und schon explodiert dein MySQL Server.

Winni sollte vielleicht noch mal drüber schauen. Ggf. reicht es schon das sql_connect() vor der while-Schleife zu machen. Dazu kenne ich den LBS aber zu wenig.

**Winni** · 23.05.2017, 07:35

jonofe Das connect ist in die while Schleife gewandert, weil EDOMI ja automatisch nach einiger Zeit einen disconnect macht.... Dann hat z.B. eKey nach (ich glaube) 6 Stunden nicht mehr funktioniert. Kann man irgendwie abfragen, ob man noch verbunden ist und nur in diesem Fall einen neuen Connect machen? Bin leider mit php nicht so sehr vertraut.
PS: Wird überhaupt eine neue Verbindung aufgebaut, wenn bereits eine Verbindung besteht?!

**jonofe** · 23.05.2017, 07:43

Zitat von Winni Beitrag anzeigen

jonofe Das connect ist in die while Schleife gewandert, weil EDOMI ja automatisch nach einiger Zeit einen disconnect macht.... Dann hat z.B. eKey nach (ich glaube) 6 Stunden nicht mehr funktioniert. Kann man irgendwie abfragen, ob man noch verbunden ist und nur in diesem Fall einen neuen Connect machen? Bin leider mit php nicht so sehr vertraut.

Okay, verstehe. Eigentlich macht das sql_connect auch nichts aus. Blockiert denn die Schleife bei socket receive Befehl? Vermutlich ja. Dann ist ein sql_connect() notwendig und auch sinnvoll. Ich vermute, dass es dann einfach ein Problem ist, dass hier 100 UDP Bausteine eingesetzt werden. Man müsste mal schauen, wie das Limit bei mySQL eingestellt ist. Soweit ich es verstanden habe, macht sql_connect() keine zusätzliche Verbindung auf, sondern erneuert die Verbindung, wenn diese ins timeout gelaufen ist. Daher würden die 100LBS vermutlich nicht mehr als 100 Verbindungen offen haben. Aber vielleicht ist dies bereits zu viel.

**jonofe** · 23.05.2017, 07:48

In mySQL kann man die Anzahl Connections wie folgt prüfen/einstellen:

Code:

[root@edomi-dev ~]# [B][COLOR=#FF0000]mysql[/COLOR][/B]
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 8180111
Server version: 5.1.73 Source distribution

Copyright (c) 2000, 2013, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> [B][COLOR=#FF0000]show variables like "max_connections";[/COLOR][/B]
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 151   |
+-----------------+-------+
1 row in set (0.00 sec)

mysql> [B][COLOR=#FF0000]SHOW STATUS WHERE `variable_name` = 'Threads_connected';[/COLOR][/B]
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 17    |
+-------------------+-------+
1 row in set (0.00 sec)

mysql>[B][COLOR=#FF0000] set global max_connections = 200;[/COLOR][/B]
Query OK, 0 rows affected (0.00 sec)

mysql>

Ich würde die mal auf 200 stellen und schauen, ob das Problem dann behoben ist. Nach Aktivierung von EDOMI sollte dann der Werte von Threads_connected deutlich unter 200 sein, damit das Problem nicht erneut auftritt. Ideal ist es aber sicher für die Performance von EDOMI nicht, müsste man aber genau analysieren.

**Marha** · 23.05.2017, 08:12

Das werde ich heute Abend ausprobieren.
Auf einem Raspberry Pi habe ich diese Konstellation in smarthomeNG seit ca einem Jahr problemlos am Laufen mit einer Last des Raspberry Pi von 8 % (wird jedenfalls angezeigt). Nun wollte ich auf Edomi umziehen. Mein Eindruck von Edomi ist, dass es wesentlich performanter ist als smarthomeNG. Daher bin ich guter Dinge, dass das "Problem" zu lösen ist.

**gaert** · 23.05.2017, 08:17

mysql_connect() öffnet in der Tat eine neue Verbindung, mysql_disconnect() schließt eine Verbindung wieder. Im Rahmen einer Schleife ist dies total unsinnig! Zum Verhindern eines Verbindungstimeouts ist z.B. die Funktion logic_dbKeepalive() zu verwenden (siehe Hilfe).

Ankündigung

ERR_LOG Fehlercode: 2

ERR_LOG Fehlercode: 2

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar