Absturz Verwaltungskonsole

Guten Tag,

Ich habe ein Problem mit der Verwaltungskonsole. Zeitweise macht diese Schwierigkeiten beim Löschen von Variablen. Es kommt vor, dass es mir nicht mehr Möglich ist, eine Variable zu löschen. Wenn ich versuche eine Variable zu löschen stürzt die Vewaltungskonsole ab. Nur ein Neustart vom Rechner löst das Problem. Der Dienst lässt sich nach dem Absturz nicht mehr starten.
Wenn ich mein Settings.xml anschaue sehe ich das zum Teil Einträge wie diesen hier:

<ID17291>
<Type Value=„4“/>
<Name Value=„Unbenanntes Objekt (ID: 17291)“/>
<ParentID Value=„53653“/>
</ID17291>

Hat jemand eine Idee wieso sich die Verwalungskonsole verabschiedet?

Gruss Dani

Hier ein Ausschnitt aus den Logfiles. Beim ersten Löschen alles ok. Nach dem zweiten Löschen stürzt die Verwalungskonsole ab.

09.06.2011 15:14:16.001 | 0 | DEBUG | ExecuteThreadID #9 | Skriptausführung: ModBus_RequestRead($IPS_TARGET); ~ Absender: Ereignis #51884, Zeit Ereignis
09.06.2011 15:14:16.025 | 0 | DEBUG | ExecuteThreadID #9 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 24 ms
09.06.2011 15:14:16.423 | 38818 | DEBUG | ExecuteThreadID #3 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 1421 ms
09.06.2011 15:14:16.855 | 41174 | MESSAGE | InstanceManager | Lösche Instanz [Allgemein\Alarme\Alarm3]
09.06.2011 15:14:16.855 | 41174 | MESSAGE | ModBus Address | Lösche…
09.06.2011 15:14:17.008 | 21468 | DEBUG | ExecuteThreadID #2 | Skriptausführung: 21468.ips.php ~ Absender: Ereignis #22077, Zeit Ereignis
09.06.2011 15:14:18.259 | 21468 | DEBUG | ExecuteThreadID #2 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 1251 ms
09.06.2011 15:14:20.001 | 0 | DEBUG | ExecuteThreadID #1 | Skriptausführung: ModBus_RequestRead($IPS_TARGET); ~ Absender: Ereignis #11284, Zeit Ereignis
09.06.2011 15:14:20.013 | 0 | DEBUG | ExecuteThreadID #1 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 12 ms
09.06.2011 15:14:20.503 | 48017 | DEBUG | ExecuteThreadID #1 | Skriptausführung: 48017.ips.php ~ Absender: Ereignis #42745, Zeit Ereignis
09.06.2011 15:14:21.003 | 0 | DEBUG | ExecuteThreadID #7 | Skriptausführung: ModBus_RequestRead($IPS_TARGET); ~ Absender: Ereignis #53341, Zeit Ereignis
09.06.2011 15:14:21.007 | 0 | DEBUG | ExecuteThreadID #7 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 4 ms
09.06.2011 15:14:21.503 | 38818 | DEBUG | ExecuteThreadID #10 | Skriptausführung: 38818.ips.php ~ Absender: Ereignis #15546, Zeit Ereignis
09.06.2011 15:14:21.512 | 48017 | DEBUG | ExecuteThreadID #1 | Ausgeführt, Resultat: 1, Erfolgreich: True, Zeit: 1009 ms
09.06.2011 15:14:22.499 | 47554 | DEBUG | VariableManager | [Zimmer5\Heizung\Temperatur\Value] = 0
09.06.2011 15:14:22.743 | 30884 | MESSAGE | InstanceManager | Lösche Instanz [Allgemein\Alarme\Alarm2]
09.06.2011 15:14:22.743 | 30884 | MESSAGE | ModBus Address | Lösche…
09.06.2011 15:14:24.001 | 0 | DEBUG | ExecuteThreadID #9 | Skriptausführung: ModBus_RequestRead($IPS_TARGET); ~ Absender: Ereignis #51884, Zeit Ereignis
09.06.2011 15:14:25.001 | 38818 | DEBUG | ExecuteThreadID #6 | Skriptausführung: 38818.ips.php ~ Absender: Ereignis #15546, Zeit Ereignis
09.06.2011 15:14:28.000 | 21468 | DEBUG | ExecuteThreadID #3 | Skriptausführung: 21468.ips.php ~ Absender: Ereignis #22077, Zeit Ereignis
09.06.2011 15:14:30.000 | 0 | DEBUG | ExecuteThreadID #1 | Skriptausführung: ModBus_RequestRead($IPS_TARGET); ~ Absender: Ereignis #53341, Zeit Ereignis
09.06.2011 15:14:30.500 | 38818 | DEBUG | ExecuteThreadID #8 | Skriptausführung: 38818.ips.php ~ Absender: Ereignis #15546, Zeit Ereignis
09.06.2011 15:14:32.000 | 0 | DEBUG | ExecuteThreadID #2 | Skriptausführung: ModBus_RequestRead($IPS_TARGET); ~ Absender: Ereignis #51884, Zeit Ereignis
09.06.2011 15:14:33.000 | 0 | DEBUG | ExecuteThreadID #5 | Skriptausführung: ModBus_RequestRead($IPS_TARGET); ~ Absender: Ereignis #11284, Zeit Ereignis
09.06.2011 15:14:33.500 | 48017 | DEBUG | ExecuteThreadID #7 | Skriptausführung: 48017.ips.php ~ Absender: Ereignis #42745, Zeit Ereignis
09.06.2011 15:14:35.001 | 38818 | DEBUG | ExecuteThreadID #4 | Skriptausführung: 38818.ips.php ~ Absender: Ereignis #15546, Zeit Ereignis

Was macht die CPU Auslastung deines Rechners? Ich vermute der ist im Limit…

paresy

Ich habe das gleiche Problem.
An der Auslastung liegt es nicht…

Hi

Ich hab seit einiger Zeit ähnlichs Problem, gab auch einen Thread dazu find ihn nur nicht.
Bei mir stürzt die Konsole zwar aber nicht ab, sonderen wird nach löschen und anlegen von Objekten nicht upgedated. Probiert manns nochmals gibts Fehlermeldungen Wie „Objekt xy nicht vorhanden“

Das XML File ist richtig.
Wird die Konsole neu gestartet ist die zuvor gemachte Veränderung sichtbar.

Paresis Hinweis mit Serverauslastung könnte hinkommen, da ich es erst gegen Ende Betatest und da erst nachdem ich einige neue vermutlich mehr CPU fressende Scripte eingebaut habe beobachte.

Es tritt auch nur auf wenn die Konsole längere Zeit geöffnet ist.
Nach Neustart der Konsole läufts für einige Zeit 1-2Std. astrein.

Im CPU Auslastungslog hab ich maximal 20% Auslastung (Atom Dual Core) alle 10min gibts einen kurzen Peak auf 100%.

Ob das wirklich mit dem beobachtete Effekt zusammenhängt konnt ich noch nicht endgültig klären.

vieleicht ists ja bei euch ähnlich
bb

Also ich habe das auch immer mal.
Aber bei mir kommt es (bisher) nur vor, wenn ich von einem externen Rechner auf den Server zugreife und da längere Zeit was ändere.
Dann ist es bei mir genau wie bei BB.

CPU-Auslastung ist es bei mir am Server auf keinen Fall… an meinem Netbook schon eher. Da geht das sehr schnell.

Neustart des Netbookzugriffes half aber bisher immer.

Die SW leigt auf einem Intel Atom Dual Core 1.8Ghz mit 2GB Ram. Es sind an die 380 Variablen deklariert und es läft ca alle 2 Sekunden ein Skript ab. Ein Skript kann dann aber auch 5-8 Variablen abfragen (ModBusRead_Request). Zwischen jeder der einzenlnen Abfraben im Script mache ich eine Pause von 100 ms.
IPS und Dashboard benutzen zusammen zwischen 20-30% CPU Auslastung. Der Start von IPS und Dashboard dauert eine Weile. Sobald geladen läuft es einwandfrei. Gibt es da eine Limite in Sachen deklarierter Variablen in Beuzg auf Prozessorleistung? Hat jemand Erfahrungen in dem Bereich?
Das eigenartige war: Nachdem ich die Variabeln nicht löschen konnte habe ich das Programm temporär auf einen performanten Rechner kopiert. Auch da stürtzte der Dienst ab und die Variablen liessen sich nicht löschen. :confused:

Hallo zusammen,

Das ist bei mir auch der Fall.

Hab schon vieles getestet und konnte bei mir einen Zusammenhang mit der Anzahl an Modbus-Instanzen feststellen.
Sobald mehr als 150 Modbus-Instanzen verwendet werden, dann treten die Aktualisierungs-Probleme in der Konsole auf. (Prozessor-Last ~50%)
Dies ist auch reproduzierbar bei einer Testkonfiguration mit ausschließlich 150-200 Modbus-Instanzen und sonst keine weiteren Variablen/Skripte/Events.

@Dani:
Wieviele Deiner 380 Variablen sind Modbus-Instanzen?
Gibt es hier evtl. einen Zusammenhang?

Schöne Grüße
Roland

Hm, das Problem scheint doch aber mit dem Update zusammen zu hängen.
Jetzt kommt ein Klassiker, ist aber so:

GESTERN GING ES NOCH!

330 der 380 Variablen sind bei mir ModBus Variablen. Ich konnte auch Aktualisierungsprobleme in der Konsole (Dashbaord!) feststellen so ab 200 ModBus Variablen. Somit könnte schon ein Zusammenhang bestehen. Bei mir ist es aber so, das ein ganz grosser Teil der Variablen nur da sind und vielleicht einmal im Tag benutzt oder abgefragt werden.
@Roland: Wie fagst denn Du den Status der ModBus Variablen ab? Zyklisch? Damit hatte ich Probleme wenn der Zyklus zu kurz ist oder zu viele Variablen in kurzer Zeit abgefragt werden. Bei mir ist das Problem aber leider auch vorhanden, wenn ich nicht zyklisch abfrage. Das ist dann schon eher seltsam…Limitationen?

Hallo Dani,

bei mir werden die Modbus-Variablen zyklisch mit einem 1000ms Trigger aktualisiert. Also eigentlich sehr resourcenschonend…
Allerdings ist das Problem bei mir nicht erst seit der 2.4. Das konnte ich schon länger beobachten.
Hab immer versucht die Anzahl an Modbus-Variablen so gering wie möglich zu halten und konnte so das Problem umgehen.
Jetzt benötige ich mehr als 200 Modbus-Instanzen und seitdem kämpfe ich wieder mit der Konsole… :rolleyes:

Schöne Grüße
Roland

Da wäre ich auch dabei …
Zur Migration der 2.4 (und wegen einiger mitgenommener Teile von der Release-Party) musste ich auch mal wieder ein paar Anpassungen machen. Den Client-Rechner mit der Konsole hat es mir dabei 2mal in die Knie gezwungen - leider nicht wirklich nachvollziehbar. Die Systemauslastung war im Taskmanager bei ~90%, ~70 davon hat die Konsole gesaugt. Leider ‚flatterten‘ bei mir auch die Buttons im Taskmanager, so das ein ‚kill‘ nur der Konsole nicht möglich war. Also Neustart und alles war gut.
Ich hatte das bei mir auf ein nach den Jahren doch recht ‚verwurschteltes‘ XP-home-System geschoben - scheint ja doch nicht so zu sein.

Das altersschwache Laptop, was bei mir IPS ins Netz bringt, rennt und rennt …

Muss ich mir Gedanken machen? Tue ich nicht wirklich :loveips:

Ich mache mir auch keine Gedanken - das wird schon… :smiley: :loveips:

Hab jetzt eine cleane IPS-Installation auf einen Testrechner mit Core2Duo 2x2,66GHz und 4GB RAM laufen.
Auch bei diesem Rechner gibt es ab ~150 Modbus-Instanzen die ersten kleinen Verzögerungen. Bei 300 Instanzen wird die Aktualisierung schon so langsam, dass man beim Erstellen sekundenlang „Node“ lesen kann. Alle Änderungen (Umbenennen, Neue Instanzen, Links etc.) werden erst nach Neustart der Konsole angezeigt.
Prozessorlast war immer unter 80%

Wer möchte, kann meine Test-Settings mal bei sich testen und solange Modbus-Instanzen löschen bis Änderungen sofort wieder angezeigt werden. Mich würde interessieren ob die Aktualisierung auch bei unterschiedlichen Systemen ab 150-200 Instanzen träger wird.
Es spielt dabei keine Rolle ob der Client-Socket mit einem Modbus-Device verbunden ist oder nicht - die Verzögerung bleibt gleich.

Schöne Grüße
Roland

settings_350_ModbusInstanzen.zip (22.1 KB)

node.png

modbus_instanz.png

Hmmm also scheinbar keine Einzelfälle.

Hier auch grad jetzt wirder:
Änderungen in der Konsole werden ins xml File und auch zum parall laufenden WF übertragen.
Zurück zur Konsole kommt aber nix, Variablen werden nicht mehr upgedated.

CPU weder am IPS noch am Client unauffällig.

Kann es sein das da die Verbindung „aus irgendeinem Grund“ (zb. Überauslastung) wird und ab dann nichts mehr geht ?

IPS-Team, eure Meinung dazu?

gruß
bb

Bei mir hat sich das auch so bemerkbar gemacht, dass sich erst nach einer gewissen Anzahl ModBus Instanzen die Updates der Variablen verzögert hat. Ach wenn ich alle zyklischen Scripts anhalte (also das eigentliche Update der ModBus Variablen) bleibt das Problem bestehen, und in der Verwaltungskonsole sind auf einmal die Updates gewisser Variablen (nicht ModBus in dem Fall) nicht mehr zu sehen.

Habt ihr ne Lösung gefunden?
Es ist so ruhig in diesem Beitrag geworden…

Hallo,

habe mit ähnlichen Problemen zu kämpfen. Bei mir ist der Sachverhalt so:

  • Keine ModBus Komponenten
  • ca. 450 Variablen
  • Problem tritt bei IPS 2.4 und auch jetzt bei IPS 2.5 auf
  • Habe zig Einträge der Art: „Unbenanntes Objekt (ID: XXXXX)“ in meiner über 400KB großen Settings.xml. Wenn ich nach einer solchen ID in der Settings.xml suche, taucht diese ein zweites Mal mit entsprechender richtiger Bezeichnung auf.

Können diese „Unbenanntes Objekt …“ Einträge in der Settings.xml gelöscht werden??? Habt Ihr bereits Lösung???

Gruß Proxima