ioBroker hängt Sekunden, keine Daten auf Admin
-
@domi920 sagte in ioBroker hängt Sekunden, keine Daten auf Admin:
Heißt das, dass ein Skript ein Problem verursacht?
sehr gut möglich!
@domi920 sagte in ioBroker hängt Sekunden, keine Daten auf Admin:
wie soll ich am Besten vorgehen?
Vielleicht kannst du es eingrenzen und abschätzen welches Skript (oder Instanz) zu dueser Zeit gestartet ist
Die load average der letzten Minute liegt wieder über 3, die von 5 Minuten >2 und die von 10 Minuten noch bei 1.5
Wenn sich da irgendwas hochschaukelt kann der Start auch schon etwas länger her sein (2-5 Minuten) -
@homoran ich werde jetzt mal genauer sehen wann die CPU Last so hoch ist.
Irgendwas muss die Last verursachen...Ich schreibe hier weiter wenn ich was gefunden habe...
PID USER PR NI VIRT RES SHR S %CPU %MEM ZEIT+ BEFEHL 703 iobroker 20 0 5811432 813332 45344 R 95,4 10,2 598:41.37 iobroker.js-con 467160 iobroker 20 0 1503820 695632 44248 R 59,7 8,7 232:15.80 io.javascript.0 484617 iobroker 20 0 5283660 280340 45772 R 53,5 3,5 35:28.99 io.tuya.0 1033 iobroker 20 0 772704 137492 37376 R 15,5 1,7 73:58.17 io.history.0 1104 iobroker 20 0 791372 129784 37476 R 11,2 1,6 78:54.10 io.influxdb.0Komisch ist allerdings dass auch dass teilweise tuya, zigbee, history oder so auch dabei sind....
wenn es an einen Skript liegt dann wäre es logisch wenn nur ein Adapter hochgehen würde von der Last... -
@domi920 möglich ist auch dass du in das pi4-usb3 Problem rennst.
Es gibt da hochfrequente Störungen zwischen CPU und USB3
Das führt zu Problemen im I_O.
Da bei dir eine USB-Platte dranhängt kann dann da möglicherweise der Traffic drunter leiden, was auch die Load hochtreibt. -
Ich hatte zu meinen Raspberry Zeiten auch Probleme mit der externen SSD.
Das System ist regelmäßig abgestürzt als sie Platte am USB 3 hing. Auch mit aktiven USB Hub.Am USB 2 lief dann alles wunderbar.
Und wirklich langsamer ist das System davon auch nicht geworden. -
@homoran Ja der hängt tatsächlich am USB 3.0 Port. Aber das tut es schon seit über nen halben Jahr ohne Probleme.
Ich werde mir das auf jeden Fall merken und auch testen wenn ich weiter nichts finde. -
@david-g Wenn sich weiter nichts findet werde ich das tatsächlich auch noch probieren
-
Habe jetzt aktuell mal den Tuya Adapter auf Debug gestellt. Weil dieser Adapter geht meist parallel von der Auslastung hoch.
Mal sehen wenn der Fehler wieder auftritt. Dazu lasse ich einen Eintrag im Log erstellen & mir eine Telegram Nachricht mit den Auslastungen schicken. -
Ich vermute eher wie schon von andern erwähnt , das ein Script Amok läuft .
Einzeln die Scripte abschalten und warten bringt nicht´s ..
Vorschlag:
Erstmal den Javascript Adapter ausklammern , also diesen dann ausschalten und erstmal so lassen.
Dann alle Adapter ausschalten bis auf den Admin , dann dein System neu rebooten .
Danach wenn alles hochgefahren ist , nach und nach ( nicht alle hintereinander ) auch beobachten wie sich dein System verhält bei jedem Adapter einschalten .Wenn alles läuft wie es sein sollte , kann man mit dem Javascript Adapter ( Scripte ) weiter machen .
-
@glasfaser das komische ist, dass die hohe Auslastung nur immer wieder mal auftritt, manchmal jede halbe Stunde, manchmal aber auch fehlt Stundenlang gar nichts.
Wenn es immer so wäre wenn was bestimmtes passiert (Skript(e) wird wegen irgendwas abgearbeitet) dann wäre es relativ einfach zum herausfinden.Ich kann schon alle Adapter ausschalten & einen reboot machen und langsam alle Adapter hinzuschalten, aber das wird wahrscheinlich nichts bringen weil es ja keine permanente Störung ist. Weißt was ich meine?
Seit mehr als 7 Stunden läuft alles wieder normal, also mit ca. 20 - 30 % CPU Auslastung.
Weil der Tuya Adapter meist auch so hohe Auslastung hat, werde ich vermehrt mal einen Blick drauf werfen was im Protokoll steht. Nur bei Log Stufe Info konnte ich nichts rauslesen.
Meine Vermutung wäre eben dass der Tuya Adapter irgendwas macht & darauf meine Skripte was machen. Aber ist nur eine Vermutung die auch völlig falsch sein kann.Danke für eure ganzen Tipps & Ratschläge!
Was mir noch eingefallen ist, wenn es an einen einzelnen Skript liegt könnte auch vll die Fehlermeldung kommen:
javascript.0 (624868) Script script.js.Erdgeschoss.Küche.Ansteuerung_Lampen_alle is calling setState more than 1000 times per minute! Stopping Script now! Please check your script! -
Nun sind einige Tage vergangen & ich habe einen großen Übeltäter gefunden:
Tuya Adapter.
Meine Beobachtung war folgende, dass die Cloud Abfrage Probleme machte.
Diese habe ich deaktiviert, außerdem habe ich den Haken gesetzt bei:Sollen die App Cloud-Daten (Device-ID,
Session und andere Meta-Daten)
erneuert werden?Als Ergebnis habe ich nun nur noch selten (maximal wenige male im Tag) eine Auslastung von ca. 30% bei den Tuya Adapter und das auch nur für wenige Sekunden.
Gefühlt bin ich schon einen Schritt weiter, dennoch gibt es wenige male im Tag eine Host CPU Auslastung von mehr als 100%.
Dabei ist aber der Javascript Adapter nicht höher als 20 - 30%.
Ich gehe also davon aus, dass es nicht an meinen Skripten liegt.Jetzt aber brauche ich bitte nochmal eure Hilfe:
Ich lasse mir eine Telegram Nachricht senden, wenn die CPU Last vom Host größer als 70% ist.
Es wäre noch interessant welcher Adapter für einige Sekunden so eine hohe Last hat.
Wäre es möglich mit Hilfe eines Skriptes folgende Struktur zu überwachen:system.adapter.x.x.cpuWenn einer dieser CPU Werte größer als z. B. 30 % ist, sollte dieser Adapter mit seiner CPU Last in einer Telegram Nachricht versendet werden. bzw. die Werte natürlich.
So könnte ich herausfinden welcher Adapter so viel CPU benötigt.
Wie kann man dazu ein Skript schreiben? -
Update:
Mittlerweile gab es ein Update vom Tuya Adapter. Das Problem tritt aktuell nicht mehr auf. Ob dies mit dem Update im Zusammenhang steht oder nicht weiß ich nicht.Die CPU Last ist mittlerweile in Ordnung und nicht öfters über 100%.
Außer es starten Adapter die z. B. Die Tankpreise alle 4 Stunden oder so abrufen.Danke für eure großartige Hilfe!
Gruß Dominik
