ioBroker regelmässig load >40 und bleibt hängen
-
@homoran said in ioBroker regelmässig load >40 und bleibt hängen:
@marlan99 sagte in ioBroker regelmässig load >40 und bleibt hängen:
kann nur noch mit einem Power cycle wiederbelebt werden.
was ggf. dein Dateisystem zerstört!
Zum Glück die bisherigen gefühlt 50 Mal noch nicht. Der 51. wird es dann sein
@marlan99 sagte in ioBroker regelmässig load >40 und bleibt hängen:
load average: 0.56, 0.27, 0.48
da sehe ich nichts von 40.
Das ist korrekt, denn hier läuft das system gerade. Wenn es dann die 40 hat geht ein paar Sekunden später nix mehr. Die 40 (oder mehr) sehe ich im output von „top“ , nachdem er sich aufgehöngt hat.
Dann müsstest du mal systematisch nach der Ursache forschen.
- Tritt das Phänomen zu bestimmten Zeiten auf?
- startet da ein Amokskript?
- ein scheduled Adapter?
- ....
Es war immer zu unterschiedlichen Zeiten. Seit gestern nun auch bei jedem täglichen Backupversuch. Wenn ich es manuell starte, dann bricht er beim backup der objects ab.
Nachdem ausführen der Befehle, die ich hier von Thomas Braun erhalten habe ist zumindest schon mal das Backup zweimal ohne Fehler durchgelaufen.@marlan99 sagte in ioBroker regelmässig load >40 und bleibt hängen:
Im GUI lässt sich die Seite „Objekte“ nicht mehr öffnen.
dann hast du zu viele Knoten offen
Kann man die über ein cli kommando schliessen? Über das GUI komme ich aktuell gar nicht mehr dran um allfällige offenen Knoten zu schliessen.
Da ich ein kleiner Monk bin, mache ich immer alle Knoten zu, bevor ich die Seite Objekte verlasse. - Tritt das Phänomen zu bestimmten Zeiten auf?
-
Jetzt habe ich noch folgende Meldungen im Protokoll.
Ich werde weiterhin das Gefühl nicht los, dass etwas mit den Objekten oder redis nicht hinhaut.iobroker 2024-04-14 14:11:22.866 error Caught by controller[2]: at TCP.<anonymous> (node:net:350:12) host.iobroker 2024-04-14 14:11:22.865 error Caught by controller[2]: at Socket.emit (node:domain:489:12) host.iobroker 2024-04-14 14:11:22.865 error Caught by controller[2]: at Socket.emit (node:events:517:28) host.iobroker 2024-04-14 14:11:22.864 error Caught by controller[2]: at Object.onceWrapper (node:events:632:26) host.iobroker 2024-04-14 14:11:22.864 error Caught by controller[2]: at Socket.<anonymous> (/opt/iobroker/node_modules/ioredis/built/redis/event_handler.js:151:20) host.iobroker 2024-04-14 14:11:22.863 error Caught by controller[2]: at close (/opt/iobroker/node_modules/ioredis/built/redis/event_handler.js:184:25) host.iobroker 2024-04-14 14:11:22.863 error Caught by controller[2]: Error: DB closed host.iobroker 2024-04-14 14:11:22.863 error Caught by controller[1]: at processTicksAndRejections (node:internal/process/task_queues:95:5) host.iobroker 2024-04-14 14:11:22.862 error Caught by controller[1]: at StateRedisClient.setState (/opt/iobroker/node_modules/@iobroker/db-states-redis/src/lib/states/statesInRedisClient.ts:813:35) host.iobroker 2024-04-14 14:11:22.862 error Caught by controller[1]: at Redis.set (/opt/iobroker/node_modules/ioredis/built/commander.js:122:25) host.iobroker 2024-04-14 14:11:22.861 error Caught by controller[1]: at Redis.sendCommand (/opt/iobroker/node_modules/ioredis/built/redis/index.js:679:33) host.iobroker 2024-04-14 14:11:22.861 error Caught by controller[1]: at Socket.Writable.write (node:internal/streams/writable:337:10) host.iobroker 2024-04-14 14:11:22.860 error Caught by controller[1]: at _write (node:internal/streams/writable:333:10) host.iobroker 2024-04-14 14:11:22.860 error Caught by controller[1]: at writeOrBuffer (node:internal/streams/writable:392:12) host.iobroker 2024-04-14 14:11:22.859 error Caught by controller[1]: at Socket._write (node:net:974:8) host.iobroker 2024-04-14 14:11:22.859 error Caught by controller[1]: at Socket._writeGeneric (node:net:962:11) host.iobroker 2024-04-14 14:11:22.859 error Caught by controller[1]: at writeGeneric (node:internal/stream_base_commons:151:3) host.iobroker 2024-04-14 14:11:22.858 error Caught by controller[1]: at afterWriteDispatched (node:internal/stream_base_commons:160:15) host.iobroker 2024-04-14 14:11:22.858 error Caught by controller[1]: [ioredis] Unhandled error event: Error: write EPIPE host.iobroker 2024-04-14 14:11:22.856 error Caught by controller[0]: [pidusage] We couldn't find uptime from /proc/uptime, using os.uptime() value javascript.0 2024-04-14 14:11:22.674 error Error: DB closed at close (/opt/iobroker/node_modules/ioredis/built/redis/event_handler.js:184:25) at Socket.<anonymous> (/opt/iobroker/node_modules/ioredis/built/redis/event_handler.js:151:20) at Object.onceWrapper (node:events:632:26) at Socket.emit (node:events:517:28) at Socket.emit (node:domain:489:12) at TCP.<anonymous> (node:net:350:12) javascript.0 2024-04-14 14:11:22.674 error Error: DB closed -
-
@marlan99 sagte in ioBroker regelmässig load >40 und bleibt hängen:
Die 40 (oder mehr) sehe ich im output von „top“ , nachdem er sich aufgehöngt hat.
der wäre interessant!
Natürlich geht bei load >4 (fast) nichts mehr, bei 40 gar nichts.
@marlan99 sagte in ioBroker regelmässig load >40 und bleibt hängen:
Seit gestern nun auch bei jedem täglichen Backupversuch. Wenn ich es manuell starte, dann bricht er beim backup der objects ab.
auch "normal".
Backitup benötigt viel RAM beim erstellen der gepackten Daten. Bei deinen Mengen natürlich auch sehr viel davon.Was ein weiterer Hinweis auf zu wenig RAM für diese Anzahl Objekte ist.
-
Problem ist behoben und ich bin ja soooo doooooof und der Beweis dafür, dass man den Aussagen bei Problembeschreibungen einfach nicht immer vertrauen kann.
Kurzfassung:
Die Datenpunkte sind um das 10-fache angewachsen. Dies führte dazu, dass sämtliche Tasks die auf die Objektstruktur zugreifen wollen die CPU und das Memory überdurchschnittlich beanspruchen. In meinem Fall CPU load > 40 und somit zum Stillstand des Systems ohne Aussicht auf Erholung.Langfassung:
Meine Analysen habe ich immer mit dem Browser auf dem iPad gemacht. Hier konnte ich das Problem insofern eingrenzen, dass das Problem bei den Datenpunkten liegen muss. Aber leider eben keinen Zugriff darauf.
Durch das Backup (wenn es dann mal funktionierte) konnte ich sehen, dass ich ca 200'000 Datenpunkte habe und gemäss meinen Erinnerungen etwa stimmen müsste.......
Heute dann mal auf einem Rechner die Analyse weitergemacht und hoppla, jetzt gelange ich doch über das GUI in die Objektliste.
Hier dann den Adapterübeltäter gefunden, welcher ca 180'000 Datenpunkte zuviel angelegt hatte.
Nach der Bereinigung verblieben dann noch 25'000 DP.
Jetzt rennt mein System wieder wie gewohnt und gefüht sogar noch etwas schneller als vorher. Aber wie eingangs erwähnt. Ich traue meinen Aussagen auch hier nicht mehr......Als Überblick meines ioBroker Systems:
- Raspi4B mit 4GB Ram mit SSD disk via USB3
- 37 Adapter installiert mit insgesamt 40 Instanzen
- javascript Adapter mit 140 aktiven Scripts
- Influx DB
- Grafana server
Durchscnittliche CPU Last 0.4 / durchschnittlich verbrauchtes Memory 70%-75%
Ich bedanke mich an die tollen Supporter hier.
DANKE -
@marlan99 sagte in ioBroker regelmässig load >40 und bleibt hängen:
Hier dann den Adapterübeltäter gefunden, welcher ca 180'000 Datenpunkte zuviel angelegt hatte.
Und wer war es?
-
@thomas-braun lass mich raten: BLE
-
@homoran sagte in ioBroker regelmässig load >40 und bleibt hängen:
lass mich raten: BLE
Falsch geraten, der ist nämlich nicht installiert.
-
@thomas-braun oh, stimmt.
es war der Tesla Adapter V1.4.2, der für irgendwelche history lifetime Daten diese Datenpunkte zu viel erstellt hatte.
Ich habe heute im github gesehen dass der Entwickler am 10.04. eine neue beta Version (v1.4.4) bereitgestellt hat, wobei gemäss release notes dies beheben soll. Mein Problem begann am 09.04.Da der Adaptr aber auch die Möglichkeit bietet bestimmte Pfade komplett zu ignorieren, habe ich vorerst diesen Weg gewählt. Die neue Beta ist bei mir noch nicht installiert.
-
Stable ist da 1.3.2.
Bei Beta-Versionen muss man davon ausgehen das da 'Dinge' drin sind. Dafür sind es ja Beta-Versionen.Die neue Beta ist bei mir noch nicht installiert.
Das solltest du dann als Beta-Tester aber tun, nutzt ja nix, wenn du eine Version 1.4.2 betatestest.
-
@thomas-braun da gebe ich dir natürlich recht.
Habe es auch mitgetestet und lief seit 6 Monaten Fehlerfrei.Ich vermute auch, dass Teslaseitig etwas geändert hat, dass es am 09.04. dann diesen Effekt hervorbrachte.
