Load average am Anschlag -> Neustart
-
also du hast 2 extreme load ereignisse ca 7:50 und ca 8:56
und 1 leichtes load ereignis bei ca 8:30/8:351. chart
input count
bei 7:50 lässt sich nicht abschätzen
bei 8:35 er leicht an
bei 9:00 stärker (leider abgeschnitten)freies RAM
7:50 nicht gut lesbar
8:35 leichtes abfallen
9:00 starkes abfallen2.chart
load
hier sieht man deutlich die starken und leichen load anstiege
bei den uhrzeitenRAM oder CPU?
Im text schreibst du der 2. chart zeigt die cpu last ich gehe davon aus, das es nur die grüne load linie betrifft, der rest zeigt den ram verbrauch der adapter
bei 8:00 siehst du einen leichten anstieg und dann ein starkes abfallen.
das müsste entweder ein neustart des javascript adapters sein oder (was ungewöhnlich wäre) der adapter gibt plötzlich eine große menge an speicher frei. ich tippe auf ersteres
admin adapter steigt der ram verbrauch stärker an und fällt dann wieder ab.
9:00 ähnliches, aber nicht so stark ausgeprägtich tippe erst einmal auf ein skript im javascript adapter.
entweder erzeugt es viele lese und schreibvorgänge in sehr kurzer zeit
oder events schaukeln sich auf.
entweder blockt das der admin, ich glaube da gibt es eine grenze wieviel vorgänge ein adapter innerhalb einer sekunde senden darf und startet den javascript adapter neudu sagst der ganze iobroker wurde neu gestartet? bei welchem ereignis war das?
die connected/disconnected meldungen sind eigentlich harmlos. alles in iobroker kommuniziert per socket. der client (also jeder adapter oder auch visualisierungen) melden sich an und schließen die verbindung wenn bspw bei vis das tablet in den schlafmodus geht (glaube ich). ich habe ähnliche meldungen, allerdings nicht ganz so oft.
ich hatte vor einigen jahre ein ähnliches problem. da hat ein skript wegen falsch programmieren setTimeouts immer mehr zugriffe auf datenpunkte erzeugt. irgendwann ist der js-controller dann abgestürzt.
aber nur eine vermutung und evtl hinweise fürs weitersuchen.
wenn du an den skripten nichts verändert hast, kann es evtl auch durch eine höhere schreibdichte auf datenpunkte, bei denen du im javascript einen trigger darauf hast kommen. evtl durch einen neuen oder aktualisierten adapter. da könntest du mal auf input counts/output counts des javascript adapters tracken, ob das zu diesen ereignissen extrem ansteigt (und hoffen das das noch geschrieben wird bevor der iobroker abstürzt)Im text schreibst du der 2. chart zeigt die cpu last ich gehe davon aus
Tat ich das?
sorry.
Cpu last ist ganz unten die Tabelle!du sagst der ganze iobroker wurde neu gestartet? bei welchem ereignis war das?
09:04, siehe Tabelle
Der chart zeigt leider durch die Aggregation nicht immer alle kurzen aber massiven Ausschläge an 😞
nur eine vermutung und evtl hinweise fürs weitersuchen.
Danke, das ist genau was ich brauche!
Aber Skripte sehe ich nicht, der js-Adapter läuft ruhig.
bei 9:00 stärker (leider abgeschnitten)
Müsste ich mal versuchen den "echten" Wert herauszufinden
DANKE
Edit:
kein Support per PN! - Fragen im Forum stellen - Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Das Forum freut sich über eine Spende. Benutzt dazu den Spendenbutton oben rechts. Danke!
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash - -
also du hast 2 extreme load ereignisse ca 7:50 und ca 8:56
und 1 leichtes load ereignis bei ca 8:30/8:351. chart
input count
bei 7:50 lässt sich nicht abschätzen
bei 8:35 er leicht an
bei 9:00 stärker (leider abgeschnitten)freies RAM
7:50 nicht gut lesbar
8:35 leichtes abfallen
9:00 starkes abfallen2.chart
load
hier sieht man deutlich die starken und leichen load anstiege
bei den uhrzeitenRAM oder CPU?
Im text schreibst du der 2. chart zeigt die cpu last ich gehe davon aus, das es nur die grüne load linie betrifft, der rest zeigt den ram verbrauch der adapter
bei 8:00 siehst du einen leichten anstieg und dann ein starkes abfallen.
das müsste entweder ein neustart des javascript adapters sein oder (was ungewöhnlich wäre) der adapter gibt plötzlich eine große menge an speicher frei. ich tippe auf ersteres
admin adapter steigt der ram verbrauch stärker an und fällt dann wieder ab.
9:00 ähnliches, aber nicht so stark ausgeprägtich tippe erst einmal auf ein skript im javascript adapter.
entweder erzeugt es viele lese und schreibvorgänge in sehr kurzer zeit
oder events schaukeln sich auf.
entweder blockt das der admin, ich glaube da gibt es eine grenze wieviel vorgänge ein adapter innerhalb einer sekunde senden darf und startet den javascript adapter neudu sagst der ganze iobroker wurde neu gestartet? bei welchem ereignis war das?
die connected/disconnected meldungen sind eigentlich harmlos. alles in iobroker kommuniziert per socket. der client (also jeder adapter oder auch visualisierungen) melden sich an und schließen die verbindung wenn bspw bei vis das tablet in den schlafmodus geht (glaube ich). ich habe ähnliche meldungen, allerdings nicht ganz so oft.
ich hatte vor einigen jahre ein ähnliches problem. da hat ein skript wegen falsch programmieren setTimeouts immer mehr zugriffe auf datenpunkte erzeugt. irgendwann ist der js-controller dann abgestürzt.
aber nur eine vermutung und evtl hinweise fürs weitersuchen.
wenn du an den skripten nichts verändert hast, kann es evtl auch durch eine höhere schreibdichte auf datenpunkte, bei denen du im javascript einen trigger darauf hast kommen. evtl durch einen neuen oder aktualisierten adapter. da könntest du mal auf input counts/output counts des javascript adapters tracken, ob das zu diesen ereignissen extrem ansteigt (und hoffen das das noch geschrieben wird bevor der iobroker abstürzt)da könntest du mal auf input counts/output counts des javascript adapters tracken, ob das zu diesen ereignissen extrem ansteigt
Ooh, nicht korrekt gelesen
Hab nur die input counts 😞Was mich allerdings wundert ist, dass js.0 und js.1 etwa gleiche Werte (ca.1400) haben, obwohl in js.0 keine Skripte laufen
edit:
Jetzt aber
Input counts sind 10x so hoch wie die output countskein Support per PN! - Fragen im Forum stellen - Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Das Forum freut sich über eine Spende. Benutzt dazu den Spendenbutton oben rechts. Danke!
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash - -
da könntest du mal auf input counts/output counts des javascript adapters tracken, ob das zu diesen ereignissen extrem ansteigt
Ooh, nicht korrekt gelesen
Hab nur die input counts 😞Was mich allerdings wundert ist, dass js.0 und js.1 etwa gleiche Werte (ca.1400) haben, obwohl in js.0 keine Skripte laufen
edit:
Jetzt aber
Input counts sind 10x so hoch wie die output counts@Homoran sagte:
js.0 und js.1 etwa gleiche Werte (ca.1400) haben, obwohl in js.0 keine Skripte laufenFür beide Instanzen wird der (getrennte) Puffer synchronisiert.
Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: Asus PN 42 / N100 / 8 GB / 500 GB; Proxmox mit 2 VM (iob / openCCU) -
@Homoran sagte:
js.0 und js.1 etwa gleiche Werte (ca.1400) haben, obwohl in js.0 keine Skripte laufenFür beide Instanzen wird der (getrennte) Puffer synchronisiert.
@paul53 Danke!
Hab mir so etwas gedacht und jetzt statt js.0 input in und output für js.1 im chart integriertkein Support per PN! - Fragen im Forum stellen - Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Das Forum freut sich über eine Spende. Benutzt dazu den Spendenbutton oben rechts. Danke!
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash - -
@paul53 Danke!
Hab mir so etwas gedacht und jetzt statt js.0 input in und output für js.1 im chart integriert@Homoran sagte:
für js.1 im chart integriertBei Input von 4000 muss ein Adapter schnell viele DP aktualisieren.
Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: Asus PN 42 / N100 / 8 GB / 500 GB; Proxmox mit 2 VM (iob / openCCU) -
@Homoran sagte:
für js.1 im chart integriertBei Input von 4000 muss ein Adapter schnell viele DP aktualisieren.
-
Im text schreibst du der 2. chart zeigt die cpu last ich gehe davon aus
Tat ich das?
sorry.
Cpu last ist ganz unten die Tabelle!du sagst der ganze iobroker wurde neu gestartet? bei welchem ereignis war das?
09:04, siehe Tabelle
Der chart zeigt leider durch die Aggregation nicht immer alle kurzen aber massiven Ausschläge an 😞
nur eine vermutung und evtl hinweise fürs weitersuchen.
Danke, das ist genau was ich brauche!
Aber Skripte sehe ich nicht, der js-Adapter läuft ruhig.
bei 9:00 stärker (leider abgeschnitten)
Müsste ich mal versuchen den "echten" Wert herauszufinden
DANKE
Edit:
Homoran sagte:
@OliverIO sagte:
du sagst der ganze iobroker wurde neu gestartet? bei welchem ereignis war das?
09:04, siehe Tabelle
@oliverio
Ich hab da noch was gefunden2026-08-23 08:58:42.519 - info: admin.0 (1197) Adapter rating updated
Das kommt mir aber bekannt vor.
kein Support per PN! - Fragen im Forum stellen - Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Das Forum freut sich über eine Spende. Benutzt dazu den Spendenbutton oben rechts. Danke!
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash - -
Ich hab da noch was gefunden
2026-08-23 08:58:42.519 - info: admin.0 (1197) Adapter rating updated
Das kommt mir aber bekannt vor.
der admin hat die ratings, also die bewertungssterne der adapter gelesen
https://github.com/ioBroker/ioBroker.socket-classes/blob/aea61897afee4642784737c162760db9bcdcf4fe/src/lib/socketCommandsAdmin.ts#L267 -
Ich hab da noch was gefunden
2026-08-23 08:58:42.519 - info: admin.0 (1197) Adapter rating updated
Das kommt mir aber bekannt vor.
der admin hat die ratings, also die bewertungssterne der adapter gelesen
https://github.com/ioBroker/ioBroker.socket-classes/blob/aea61897afee4642784737c162760db9bcdcf4fe/src/lib/socketCommandsAdmin.ts#L267@OliverIO danke, ja das weiss ich.
Aber ich habe einige Absturzberichte im Hinterkopf, bei denen auch das lesen der ratings das letzte Lebenszeichen war. Die finde ich gerade nicht mehr.Ist aber wahrscheinlich nur Zufall, gestern 14:10 war da nichts entsprechendes im log.
Hier
Habe ich mal sie counts auf max aggregiert.
Input kommt auf gut 3000, output auf 600Das korreliert nicht (??) mit den peaks bei load.
Auch wenn es bei 15:30 so sein könnte, habe ich dort mit dem Zoom in einem flot chart gespielt, bis die load auf 4 war. Danach aufgehört und die load fing sich wieder.
Das käme meiner Theorie vom Zugriff auf die SD und hoher I/O entgegen.
kein Support per PN! - Fragen im Forum stellen - Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
Das Forum freut sich über eine Spende. Benutzt dazu den Spendenbutton oben rechts. Danke!
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash - -
@OliverIO danke, ja das weiss ich.
Aber ich habe einige Absturzberichte im Hinterkopf, bei denen auch das lesen der ratings das letzte Lebenszeichen war. Die finde ich gerade nicht mehr.Ist aber wahrscheinlich nur Zufall, gestern 14:10 war da nichts entsprechendes im log.
Hier
Habe ich mal sie counts auf max aggregiert.
Input kommt auf gut 3000, output auf 600Das korreliert nicht (??) mit den peaks bei load.
Auch wenn es bei 15:30 so sein könnte, habe ich dort mit dem Zoom in einem flot chart gespielt, bis die load auf 4 war. Danach aufgehört und die load fing sich wieder.
Das käme meiner Theorie vom Zugriff auf die SD und hoher I/O entgegen.
wenn ich mich recht erinnere setzt du das standard jsonl als datenbank format ein. wenn du viele datenpunkte hast und auch viel history machst, kommst du evtl an die grenzen?
evtl mal redis probieren? -
wenn ich mich recht erinnere setzt du das standard jsonl als datenbank format ein. wenn du viele datenpunkte hast und auch viel history machst, kommst du evtl an die grenzen?
evtl mal redis probieren?@OliverIO Danke!
Wäre vielleicht mal zu testen, ist für mich aber eher eine Symptombekämpfung.Wenn es nicht eine kritische Masse gibt, nach deren Überschreitung alles zusammenbricht ergibt das für mich keinen Sinn.
Ich logge diese Daten seit 12 Jahren auf allen bisherigen Systemen.
Seit Umzug auf den Pi5 lag die load durchgehend unter 1 (backup und install ausgenommen)Seit 2-3 Wochen jetzt diese immensen Ausreißer.
Ich weiss dass ich mit history übertrieben habe, aber ich habe gestern 30GB! Daten aus 2021 und 2022 gelöscht.
Wenn getHistory überlastet war, hätte das IMHO schleichend beginnen und nach der Radikalkur wieder beendet sein müssen.Skripte habe ich nocht in den letzten Wochen neu angelegt oder geändert.
Es kann aus meiner Logik eher ein Adapter- oder nodejs Update verursacht haben.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden328
Online33.0k
Benutzer83.7k
Themen1.3m
Beiträge