Re: ExecEngine scheint mehrfach zu laufen
Verfasst: 31.05.2014, 02:41
Moin,
dann gebe ich auch noch mal kurz meinen Senf dazu ab:
Probleme in VisuWin, wenn die Uhr nicht läuft, deuten auf Probleme mit der IP-Kommunikation hin, weil die "Push"-Nachrichten von der CCU nicht ankommen, der initialzustand wird gepollt. Wenn die Uhr irgendwann wie verrückt anfängt zu rennen, würde mir das extrem zu denken geben, weil dann irgendwas die CCU massiv auslastet.
Das können Zombie-Instanzen sein, eine oder mehrere offene WebUI-Sessions.
Da aber wahrscheinlich die wenigsten ein dauerhaftes Monitoring ihrer CCU betreiben, wird das keinem auffallen, wenn das Schächtelchen am Anschlag arbeitet, weil ein Lüfter, der dann hochdreht, hat die Kiste zum Glück ja nicht.
Und ich würde leider bei dem System nichts pauschalieren, nur weil es bei Bümpi keine Probleme gibt, heißt das nicht, das es bei Rhobin auch keine Probleme geben muss.
Das fängt bei der Komplexität der Programme an, Anzahl der Variablen, Module, ja sogar statischer Text in den Makros, der zum eMail-Versand etc. genutzt wird, belegt so etwas wie einen Variablen-Index.
Die Art der Progammierung, ich habe das Gefühl, das viele hier im Forum Makros mit (kurzen) Ausführungsintervallen nutzen, obwohl das gar nicht notwendig ist, weil das meistens mit einem Trigger auf Empfang oder Änderung erledigt werden könnte.
Und ich habe persönlich das Gefühl, das die CCU1 in Verbindung mit den FHZ2000 sehr netzwerk-Sensitiv ist, je mehr Traffic im Netz, desto mehr Probleme mit der Verbindung zwischen CCU1 und FHZ2000 treten auf, wobei der Traffic nicht unbedingt heftiges GByteweise Dateien verscheiben sein muss, mehr der Low-Level-TCP/IP Traffic, ARP-Requests usw.
In meinem SoHo-Netzwerk, ausschließlich managebare GByte-Switche (keine Hubs), wo die Verbindung zwischen CCU und meinen 2 FHZ über 2-3 Switche läuft, gibt es mit steigender Anzahl laufender PCs im Netzwerk mehr Verbindungsneuaufbauten zwischen FHZ2000 und CCU1, soweit ich das mit Wireshark debuggen konnte hat immer die FHZ2000 die Verbindung neu aufgebaut, weil die CCU banal ausgedrückt, nicht schnell genug geantwortet hat. Dabei geht jedesmal ein bisschen Hauptspeicher der CCU verloren, bis der FHZ2000IF neu gestartet wird. Ich kann/will aber nicht ausschließen, das ich mir diese Probleme teilweise selbst mache, weil ich z.B. keinen USB-Stick, sondern eine NFS-Freigabe als Datenträger auf der CCU nutze, und da auch regelmäßig Daten drüber schreibe/lese. Ausserdem läuft mein Health-Monitoring der CCU, was auch alle 5min kurze Zeit die ein oder andere Ausgabe von Kommadozeilentools auswertet und verarbeitet.
Die Exec-Engine bzw. der Controll-Prozess hat meiner Meinung nach einen Watchdog, der die Ausführung neu startet, wenn eine gewisse Zeit "keine Antwort" von der ExecEngine kommt. Kann man ausprobieren, in dem man ein Makro schreibt, was sich selbst immer wieder neu aufruft (kein gehezu-Sprung nach oben, da bekommen andere Module auch mal an die Reihe), da ist nach ca. 15.000 "Rekursionen" Feierabend, entweder, weil der Stack geplatzt ist, oder weil keiner mehr Antwortet, auf jeden Fall startet dann die Ausführung neu.
Wenn meine selbstgeschrieben Tools z.B. erkennen, das die Ausführung meines HPCL-Projekts auf der CCU neu gestartet wurde, lassen die der CCU erstmal 120 Sekunden Zeit, damit HPCL alles auf die Reihe bringen kann, bevor die überhaupt erst anfangen, sich z.B. einmalig die Variablenliste per XMLRPC zu requesten. Alleine dieser Request dauert inzwischen bei meinem Projekt ca. 30-40 Sekunden, bis die Antwort mit ~3.000 Variablen/Objektennamen da ist, danach können meine Tools dann aber die paar Variablen, die sie benötigen, gezielt per Lfd-IndexNr. abfragen/setzen, das geht dann ratz fatz.
Ich finde es "gemein", wenn VisuWin schon läuft, und nur darauf wartet, das endlich eine ExecEninge antwortet, um die dann gleich zu traktieren. Wenn die Ausführung gestartet wird, hat die ExecEngine erstmal jedemenge zu tun, je mehr HM-Geräte angelernt sind, desto länger dauert es, bis z.B. alle Zustände der Geräte erstmal abgefragt wurden, bei 220V-Aktoren z.B. auch per Funk-Anfrage.
Egal, gute Nacht, der Familienvater
dann gebe ich auch noch mal kurz meinen Senf dazu ab:
Probleme in VisuWin, wenn die Uhr nicht läuft, deuten auf Probleme mit der IP-Kommunikation hin, weil die "Push"-Nachrichten von der CCU nicht ankommen, der initialzustand wird gepollt. Wenn die Uhr irgendwann wie verrückt anfängt zu rennen, würde mir das extrem zu denken geben, weil dann irgendwas die CCU massiv auslastet.
Das können Zombie-Instanzen sein, eine oder mehrere offene WebUI-Sessions.
Da aber wahrscheinlich die wenigsten ein dauerhaftes Monitoring ihrer CCU betreiben, wird das keinem auffallen, wenn das Schächtelchen am Anschlag arbeitet, weil ein Lüfter, der dann hochdreht, hat die Kiste zum Glück ja nicht.
Und ich würde leider bei dem System nichts pauschalieren, nur weil es bei Bümpi keine Probleme gibt, heißt das nicht, das es bei Rhobin auch keine Probleme geben muss.
Das fängt bei der Komplexität der Programme an, Anzahl der Variablen, Module, ja sogar statischer Text in den Makros, der zum eMail-Versand etc. genutzt wird, belegt so etwas wie einen Variablen-Index.
Die Art der Progammierung, ich habe das Gefühl, das viele hier im Forum Makros mit (kurzen) Ausführungsintervallen nutzen, obwohl das gar nicht notwendig ist, weil das meistens mit einem Trigger auf Empfang oder Änderung erledigt werden könnte.
Und ich habe persönlich das Gefühl, das die CCU1 in Verbindung mit den FHZ2000 sehr netzwerk-Sensitiv ist, je mehr Traffic im Netz, desto mehr Probleme mit der Verbindung zwischen CCU1 und FHZ2000 treten auf, wobei der Traffic nicht unbedingt heftiges GByteweise Dateien verscheiben sein muss, mehr der Low-Level-TCP/IP Traffic, ARP-Requests usw.
In meinem SoHo-Netzwerk, ausschließlich managebare GByte-Switche (keine Hubs), wo die Verbindung zwischen CCU und meinen 2 FHZ über 2-3 Switche läuft, gibt es mit steigender Anzahl laufender PCs im Netzwerk mehr Verbindungsneuaufbauten zwischen FHZ2000 und CCU1, soweit ich das mit Wireshark debuggen konnte hat immer die FHZ2000 die Verbindung neu aufgebaut, weil die CCU banal ausgedrückt, nicht schnell genug geantwortet hat. Dabei geht jedesmal ein bisschen Hauptspeicher der CCU verloren, bis der FHZ2000IF neu gestartet wird. Ich kann/will aber nicht ausschließen, das ich mir diese Probleme teilweise selbst mache, weil ich z.B. keinen USB-Stick, sondern eine NFS-Freigabe als Datenträger auf der CCU nutze, und da auch regelmäßig Daten drüber schreibe/lese. Ausserdem läuft mein Health-Monitoring der CCU, was auch alle 5min kurze Zeit die ein oder andere Ausgabe von Kommadozeilentools auswertet und verarbeitet.
Die Exec-Engine bzw. der Controll-Prozess hat meiner Meinung nach einen Watchdog, der die Ausführung neu startet, wenn eine gewisse Zeit "keine Antwort" von der ExecEngine kommt. Kann man ausprobieren, in dem man ein Makro schreibt, was sich selbst immer wieder neu aufruft (kein gehezu-Sprung nach oben, da bekommen andere Module auch mal an die Reihe), da ist nach ca. 15.000 "Rekursionen" Feierabend, entweder, weil der Stack geplatzt ist, oder weil keiner mehr Antwortet, auf jeden Fall startet dann die Ausführung neu.
Wenn meine selbstgeschrieben Tools z.B. erkennen, das die Ausführung meines HPCL-Projekts auf der CCU neu gestartet wurde, lassen die der CCU erstmal 120 Sekunden Zeit, damit HPCL alles auf die Reihe bringen kann, bevor die überhaupt erst anfangen, sich z.B. einmalig die Variablenliste per XMLRPC zu requesten. Alleine dieser Request dauert inzwischen bei meinem Projekt ca. 30-40 Sekunden, bis die Antwort mit ~3.000 Variablen/Objektennamen da ist, danach können meine Tools dann aber die paar Variablen, die sie benötigen, gezielt per Lfd-IndexNr. abfragen/setzen, das geht dann ratz fatz.
Ich finde es "gemein", wenn VisuWin schon läuft, und nur darauf wartet, das endlich eine ExecEninge antwortet, um die dann gleich zu traktieren. Wenn die Ausführung gestartet wird, hat die ExecEngine erstmal jedemenge zu tun, je mehr HM-Geräte angelernt sind, desto länger dauert es, bis z.B. alle Zustände der Geräte erstmal abgefragt wurden, bei 220V-Aktoren z.B. auch per Funk-Anfrage.
Egal, gute Nacht, der Familienvater