ioBroker lässt RAM überlaufen und andere Phänomene
-
Hallo Community!
Eigentlich bin ich nur stiller Mitleser, wenn ich mal Probleme habe ist das Forum meine erste Anlaufstelle zum nachlesen, aber zu meinem Problem finde ich einfach nichts
Ich habe ein Problem mit meinem ioBroker. Kurz zum Aufbau, der Server - (VM auf XCP-ng, Windows 10, 64 bit, Updates auf neustem Stand, Node.js: 18.19.0, js-Controller zum Zeitpunkt 5.0.12) - bildet bei mir die Schnittstelle zwischen meinen Siemens LOGO!s und Apple HomeKit. Die Maschine lief seit 3 Jahren störungsfrei, bis letzte Woche... Binnen weniger Minuten hatte ich hunderte (!) Meldungen in der HomeApp über angeblich geschaltete Kontakte, Rauchmelder usw. Also habe ich mich mit dem Server verbunden und von 16GB RAM waren 15,9GB belegt!
Daraufhin habe ich ioBroker beendet, doch dabei sprangen nur ein paar 100MB raus. Also das System komplett neu gestartet. Vorerst war auch alles ok, aber am nächsten Tag steuerte der Server erneut auf ein RAM zu. Daraufhin habe ich mir mittels Process-Explorer und RAMMap mal angeschaut, was da so passiert und sah, dass alle paar Sekunden, von allen laufenden Prozessen des ioBroker (node.exe), welche im Hintergrund die conhost.exe ausführen, ein weiterer Prozess (WMIC.exe) gestartet wird, welche wiederum eine conhost startet und eine Sekunde später sind die Prozesse wieder weg. In der RAMMap sieht man dann nach ein paar Stunden buchstäblich 10-tausende Prozesse WMIC, conhost, welche mit jeweils 32k im RAM stehen. PIDs steigen je nachdem, wie mutig man ist, bis in die 100000+.
Nun wollte ich natürlich möglichst schnell wieder einen funktionierenden Zustand der Maschine herstellen. Nicht umsonst macht die Maschine schließlich jede Woche automatisch ein Backup mittels Acronis. Doch das Phänomen bleibt. Egal ob ich jetzt in den Januar zurück reise oder noch weiter (letztes eingespieltes Backup war vom 3.10.23), die Maschine meldet sich jedes mal brav, dass der info-Adapter nicht mehr weiter entwickelt wird, welchen ich dann auch jedes Mal deinstalliere, doch das Problem mit dem RAM bleibt. Also habe ich eine komplett neue VM aufgesetzt. Gleiche Daten wie oben. ioBroker installiert, mit dem Installer aus einem bestehenden Verzeichnis (aus Backup raus kopiert) das alte Projekt auf eine neue Maschine gebracht -> Problem bleibt, allerdings fiel mir da zum ersten Mal auf, dass er bei jedem Start meckert, die Adapter würden bereits laufen??? Also wieder alles deinstalliert, neu installiert, nacktes ioBroker, kein altes Projekt integriert, zum Test 3 Adapter installiert die nichts tun, außer sich mit den LOGO!s zu verbinden und eine leere Apple HomeKit-Bridge bereitzustellen. Auch hier, alle paar Sekunden ein neuer Prozess, neue PID, nach einer Sekunde weg. Auch hier wird beim Start angemerkt, die Adapter würden schon laufen (instance system.adapter.yahka.0 terminated with code 7 (ADAPTER_ALREADY_RUNNING) ) und zwar jeder Adapter, admin, discovery, s7, yahka... Die RAM-Auslastung steigt zwar langsamer, da nur 1/3 der Anzahl von Adaptern zum Test erstellt wurden, aber sie steigt nach wie vor.
Ich weiß nicht mehr weiter...
-
Hallo Community!
Eigentlich bin ich nur stiller Mitleser, wenn ich mal Probleme habe ist das Forum meine erste Anlaufstelle zum nachlesen, aber zu meinem Problem finde ich einfach nichts
Ich habe ein Problem mit meinem ioBroker. Kurz zum Aufbau, der Server - (VM auf XCP-ng, Windows 10, 64 bit, Updates auf neustem Stand, Node.js: 18.19.0, js-Controller zum Zeitpunkt 5.0.12) - bildet bei mir die Schnittstelle zwischen meinen Siemens LOGO!s und Apple HomeKit. Die Maschine lief seit 3 Jahren störungsfrei, bis letzte Woche... Binnen weniger Minuten hatte ich hunderte (!) Meldungen in der HomeApp über angeblich geschaltete Kontakte, Rauchmelder usw. Also habe ich mich mit dem Server verbunden und von 16GB RAM waren 15,9GB belegt!
Daraufhin habe ich ioBroker beendet, doch dabei sprangen nur ein paar 100MB raus. Also das System komplett neu gestartet. Vorerst war auch alles ok, aber am nächsten Tag steuerte der Server erneut auf ein RAM zu. Daraufhin habe ich mir mittels Process-Explorer und RAMMap mal angeschaut, was da so passiert und sah, dass alle paar Sekunden, von allen laufenden Prozessen des ioBroker (node.exe), welche im Hintergrund die conhost.exe ausführen, ein weiterer Prozess (WMIC.exe) gestartet wird, welche wiederum eine conhost startet und eine Sekunde später sind die Prozesse wieder weg. In der RAMMap sieht man dann nach ein paar Stunden buchstäblich 10-tausende Prozesse WMIC, conhost, welche mit jeweils 32k im RAM stehen. PIDs steigen je nachdem, wie mutig man ist, bis in die 100000+.
Nun wollte ich natürlich möglichst schnell wieder einen funktionierenden Zustand der Maschine herstellen. Nicht umsonst macht die Maschine schließlich jede Woche automatisch ein Backup mittels Acronis. Doch das Phänomen bleibt. Egal ob ich jetzt in den Januar zurück reise oder noch weiter (letztes eingespieltes Backup war vom 3.10.23), die Maschine meldet sich jedes mal brav, dass der info-Adapter nicht mehr weiter entwickelt wird, welchen ich dann auch jedes Mal deinstalliere, doch das Problem mit dem RAM bleibt. Also habe ich eine komplett neue VM aufgesetzt. Gleiche Daten wie oben. ioBroker installiert, mit dem Installer aus einem bestehenden Verzeichnis (aus Backup raus kopiert) das alte Projekt auf eine neue Maschine gebracht -> Problem bleibt, allerdings fiel mir da zum ersten Mal auf, dass er bei jedem Start meckert, die Adapter würden bereits laufen??? Also wieder alles deinstalliert, neu installiert, nacktes ioBroker, kein altes Projekt integriert, zum Test 3 Adapter installiert die nichts tun, außer sich mit den LOGO!s zu verbinden und eine leere Apple HomeKit-Bridge bereitzustellen. Auch hier, alle paar Sekunden ein neuer Prozess, neue PID, nach einer Sekunde weg. Auch hier wird beim Start angemerkt, die Adapter würden schon laufen (instance system.adapter.yahka.0 terminated with code 7 (ADAPTER_ALREADY_RUNNING) ) und zwar jeder Adapter, admin, discovery, s7, yahka... Die RAM-Auslastung steigt zwar langsamer, da nur 1/3 der Anzahl von Adaptern zum Test erstellt wurden, aber sie steigt nach wie vor.
Ich weiß nicht mehr weiter...
@annetheke sagte in ioBroker lässt RAM überlaufen und andere Phänomene:
Ich weiß nicht mehr weiter...
sei mir nicht böse, aber diese langen Textpassagen helfen mir wirklich nicht in das ganze eine Struktur zu bekommen.
Also kurz:
- RAM "läuft über"
- Meldungen in ??
- prozesse doppelt.
Auch die Hard/software Konstellation hab ich nicht ganz verfolgen können. Wahrscheinlich auch weil mir due ganzen Abkürzungen nichts sagen.
Aver verstehe ich das richtig dass du einen Server X hast auf dem eine VM läuft in der Windows läuft und darin ioBroker?
dann funktioniert
iob diagleider nichtbitte irgendwie weitere Fakten (logs, Meldungen, Screenshots) hier beibringen
Hilfe dazu gibt es hier https://forum.iobroker.net/topic/51555/hinweise-für-gute-forenbeiträge/1 -
Hallo Community!
Eigentlich bin ich nur stiller Mitleser, wenn ich mal Probleme habe ist das Forum meine erste Anlaufstelle zum nachlesen, aber zu meinem Problem finde ich einfach nichts
Ich habe ein Problem mit meinem ioBroker. Kurz zum Aufbau, der Server - (VM auf XCP-ng, Windows 10, 64 bit, Updates auf neustem Stand, Node.js: 18.19.0, js-Controller zum Zeitpunkt 5.0.12) - bildet bei mir die Schnittstelle zwischen meinen Siemens LOGO!s und Apple HomeKit. Die Maschine lief seit 3 Jahren störungsfrei, bis letzte Woche... Binnen weniger Minuten hatte ich hunderte (!) Meldungen in der HomeApp über angeblich geschaltete Kontakte, Rauchmelder usw. Also habe ich mich mit dem Server verbunden und von 16GB RAM waren 15,9GB belegt!
Daraufhin habe ich ioBroker beendet, doch dabei sprangen nur ein paar 100MB raus. Also das System komplett neu gestartet. Vorerst war auch alles ok, aber am nächsten Tag steuerte der Server erneut auf ein RAM zu. Daraufhin habe ich mir mittels Process-Explorer und RAMMap mal angeschaut, was da so passiert und sah, dass alle paar Sekunden, von allen laufenden Prozessen des ioBroker (node.exe), welche im Hintergrund die conhost.exe ausführen, ein weiterer Prozess (WMIC.exe) gestartet wird, welche wiederum eine conhost startet und eine Sekunde später sind die Prozesse wieder weg. In der RAMMap sieht man dann nach ein paar Stunden buchstäblich 10-tausende Prozesse WMIC, conhost, welche mit jeweils 32k im RAM stehen. PIDs steigen je nachdem, wie mutig man ist, bis in die 100000+.
Nun wollte ich natürlich möglichst schnell wieder einen funktionierenden Zustand der Maschine herstellen. Nicht umsonst macht die Maschine schließlich jede Woche automatisch ein Backup mittels Acronis. Doch das Phänomen bleibt. Egal ob ich jetzt in den Januar zurück reise oder noch weiter (letztes eingespieltes Backup war vom 3.10.23), die Maschine meldet sich jedes mal brav, dass der info-Adapter nicht mehr weiter entwickelt wird, welchen ich dann auch jedes Mal deinstalliere, doch das Problem mit dem RAM bleibt. Also habe ich eine komplett neue VM aufgesetzt. Gleiche Daten wie oben. ioBroker installiert, mit dem Installer aus einem bestehenden Verzeichnis (aus Backup raus kopiert) das alte Projekt auf eine neue Maschine gebracht -> Problem bleibt, allerdings fiel mir da zum ersten Mal auf, dass er bei jedem Start meckert, die Adapter würden bereits laufen??? Also wieder alles deinstalliert, neu installiert, nacktes ioBroker, kein altes Projekt integriert, zum Test 3 Adapter installiert die nichts tun, außer sich mit den LOGO!s zu verbinden und eine leere Apple HomeKit-Bridge bereitzustellen. Auch hier, alle paar Sekunden ein neuer Prozess, neue PID, nach einer Sekunde weg. Auch hier wird beim Start angemerkt, die Adapter würden schon laufen (instance system.adapter.yahka.0 terminated with code 7 (ADAPTER_ALREADY_RUNNING) ) und zwar jeder Adapter, admin, discovery, s7, yahka... Die RAM-Auslastung steigt zwar langsamer, da nur 1/3 der Anzahl von Adaptern zum Test erstellt wurden, aber sie steigt nach wie vor.
Ich weiß nicht mehr weiter...
@annetheke sagte in ioBroker lässt RAM überlaufen und andere Phänomene:
Ich weiß nicht mehr weiter
Meine Vermutung ist dass Dein "Problem" eher vom Windooze herrührt. Warum in einer VM kein Debian als Basis ?
-
Hallo Community!
Eigentlich bin ich nur stiller Mitleser, wenn ich mal Probleme habe ist das Forum meine erste Anlaufstelle zum nachlesen, aber zu meinem Problem finde ich einfach nichts
Ich habe ein Problem mit meinem ioBroker. Kurz zum Aufbau, der Server - (VM auf XCP-ng, Windows 10, 64 bit, Updates auf neustem Stand, Node.js: 18.19.0, js-Controller zum Zeitpunkt 5.0.12) - bildet bei mir die Schnittstelle zwischen meinen Siemens LOGO!s und Apple HomeKit. Die Maschine lief seit 3 Jahren störungsfrei, bis letzte Woche... Binnen weniger Minuten hatte ich hunderte (!) Meldungen in der HomeApp über angeblich geschaltete Kontakte, Rauchmelder usw. Also habe ich mich mit dem Server verbunden und von 16GB RAM waren 15,9GB belegt!
Daraufhin habe ich ioBroker beendet, doch dabei sprangen nur ein paar 100MB raus. Also das System komplett neu gestartet. Vorerst war auch alles ok, aber am nächsten Tag steuerte der Server erneut auf ein RAM zu. Daraufhin habe ich mir mittels Process-Explorer und RAMMap mal angeschaut, was da so passiert und sah, dass alle paar Sekunden, von allen laufenden Prozessen des ioBroker (node.exe), welche im Hintergrund die conhost.exe ausführen, ein weiterer Prozess (WMIC.exe) gestartet wird, welche wiederum eine conhost startet und eine Sekunde später sind die Prozesse wieder weg. In der RAMMap sieht man dann nach ein paar Stunden buchstäblich 10-tausende Prozesse WMIC, conhost, welche mit jeweils 32k im RAM stehen. PIDs steigen je nachdem, wie mutig man ist, bis in die 100000+.
Nun wollte ich natürlich möglichst schnell wieder einen funktionierenden Zustand der Maschine herstellen. Nicht umsonst macht die Maschine schließlich jede Woche automatisch ein Backup mittels Acronis. Doch das Phänomen bleibt. Egal ob ich jetzt in den Januar zurück reise oder noch weiter (letztes eingespieltes Backup war vom 3.10.23), die Maschine meldet sich jedes mal brav, dass der info-Adapter nicht mehr weiter entwickelt wird, welchen ich dann auch jedes Mal deinstalliere, doch das Problem mit dem RAM bleibt. Also habe ich eine komplett neue VM aufgesetzt. Gleiche Daten wie oben. ioBroker installiert, mit dem Installer aus einem bestehenden Verzeichnis (aus Backup raus kopiert) das alte Projekt auf eine neue Maschine gebracht -> Problem bleibt, allerdings fiel mir da zum ersten Mal auf, dass er bei jedem Start meckert, die Adapter würden bereits laufen??? Also wieder alles deinstalliert, neu installiert, nacktes ioBroker, kein altes Projekt integriert, zum Test 3 Adapter installiert die nichts tun, außer sich mit den LOGO!s zu verbinden und eine leere Apple HomeKit-Bridge bereitzustellen. Auch hier, alle paar Sekunden ein neuer Prozess, neue PID, nach einer Sekunde weg. Auch hier wird beim Start angemerkt, die Adapter würden schon laufen (instance system.adapter.yahka.0 terminated with code 7 (ADAPTER_ALREADY_RUNNING) ) und zwar jeder Adapter, admin, discovery, s7, yahka... Die RAM-Auslastung steigt zwar langsamer, da nur 1/3 der Anzahl von Adaptern zum Test erstellt wurden, aber sie steigt nach wie vor.
Ich weiß nicht mehr weiter...
Das hört sich für mich auch eher nach Probleme der virtualisierungsplatform und oder Windows an.
Wurde da die Version aktualisiert?
Schau mal dort, ob die Leute von XCP Ähnliches berichten. -
@annetheke sagte in ioBroker lässt RAM überlaufen und andere Phänomene:
Ich weiß nicht mehr weiter...
sei mir nicht böse, aber diese langen Textpassagen helfen mir wirklich nicht in das ganze eine Struktur zu bekommen.
Also kurz:
- RAM "läuft über"
- Meldungen in ??
- prozesse doppelt.
Auch die Hard/software Konstellation hab ich nicht ganz verfolgen können. Wahrscheinlich auch weil mir due ganzen Abkürzungen nichts sagen.
Aver verstehe ich das richtig dass du einen Server X hast auf dem eine VM läuft in der Windows läuft und darin ioBroker?
dann funktioniert
iob diagleider nichtbitte irgendwie weitere Fakten (logs, Meldungen, Screenshots) hier beibringen
Hilfe dazu gibt es hier https://forum.iobroker.net/topic/51555/hinweise-für-gute-forenbeiträge/1RAM "läuft über": Ja buchstäblich, es werden derart viele Prozesse gestartet, dass irgendwann kein Platz mehr ist und es wird fleißig ausgelagert und komprimiert.
Meldungen in ??: In der Webansicht unter "Protokolle"
Prozese doppelt: Meinst du die angeblich laufenden Adapter? Die sehe ich nur 1 mal im Task Manager bzw Process-Explorer. Wenn es um die ständig startenden WMIC und conhost geht, ist "doppelt" arg untertrieben.
@homoran said in ioBroker lässt RAM überlaufen und andere Phänomene:
Aver verstehe ich das richtig dass du einen Server X hast auf dem eine VM läuft in der Windows läuft und darin ioBroker?
Exakt!
@djmarc75 said in ioBroker lässt RAM überlaufen und andere Phänomene:
Meine Vermutung ist dass Dein "Problem" eher vom Windooze herrührt. Warum in einer VM kein Debian als Basis ?
Und warum verschwindet das Problem nicht, wenn man zu einem Stand zurück geht, an dem man sicher weiß, dass alles ok war? Auf der Maschine wird kein Update gefahren ohne es vorher zu testen und nach 3 Jahren problemlosen Betrieb glaube ich nicht, dass Windows da wirklich das Problem ist...
-
RAM "läuft über": Ja buchstäblich, es werden derart viele Prozesse gestartet, dass irgendwann kein Platz mehr ist und es wird fleißig ausgelagert und komprimiert.
Meldungen in ??: In der Webansicht unter "Protokolle"
Prozese doppelt: Meinst du die angeblich laufenden Adapter? Die sehe ich nur 1 mal im Task Manager bzw Process-Explorer. Wenn es um die ständig startenden WMIC und conhost geht, ist "doppelt" arg untertrieben.
@homoran said in ioBroker lässt RAM überlaufen und andere Phänomene:
Aver verstehe ich das richtig dass du einen Server X hast auf dem eine VM läuft in der Windows läuft und darin ioBroker?
Exakt!
@djmarc75 said in ioBroker lässt RAM überlaufen und andere Phänomene:
Meine Vermutung ist dass Dein "Problem" eher vom Windooze herrührt. Warum in einer VM kein Debian als Basis ?
Und warum verschwindet das Problem nicht, wenn man zu einem Stand zurück geht, an dem man sicher weiß, dass alles ok war? Auf der Maschine wird kein Update gefahren ohne es vorher zu testen und nach 3 Jahren problemlosen Betrieb glaube ich nicht, dass Windows da wirklich das Problem ist...
@annetheke sagte in ioBroker lässt RAM überlaufen und andere Phänomene:
dass Windows da wirklich das Problem ist...
ich aber auch!
error 7 entsteht, wenn durch einen unsauberen Neustart ein Prozwss nicht beendet und trotzdem neu gestartet wird.
Diese Neustarts könnten tatsächlich durch mangelnden ram entstehen.
leider kann ich bei WIN kein bischen helfen
-
RAM "läuft über": Ja buchstäblich, es werden derart viele Prozesse gestartet, dass irgendwann kein Platz mehr ist und es wird fleißig ausgelagert und komprimiert.
Meldungen in ??: In der Webansicht unter "Protokolle"
Prozese doppelt: Meinst du die angeblich laufenden Adapter? Die sehe ich nur 1 mal im Task Manager bzw Process-Explorer. Wenn es um die ständig startenden WMIC und conhost geht, ist "doppelt" arg untertrieben.
@homoran said in ioBroker lässt RAM überlaufen und andere Phänomene:
Aver verstehe ich das richtig dass du einen Server X hast auf dem eine VM läuft in der Windows läuft und darin ioBroker?
Exakt!
@djmarc75 said in ioBroker lässt RAM überlaufen und andere Phänomene:
Meine Vermutung ist dass Dein "Problem" eher vom Windooze herrührt. Warum in einer VM kein Debian als Basis ?
Und warum verschwindet das Problem nicht, wenn man zu einem Stand zurück geht, an dem man sicher weiß, dass alles ok war? Auf der Maschine wird kein Update gefahren ohne es vorher zu testen und nach 3 Jahren problemlosen Betrieb glaube ich nicht, dass Windows da wirklich das Problem ist...
Dann hast du auch nicht den exakt gleichen Stand wieder erreicht
-
@annetheke sagte in ioBroker lässt RAM überlaufen und andere Phänomene:
dass Windows da wirklich das Problem ist...
ich aber auch!
error 7 entsteht, wenn durch einen unsauberen Neustart ein Prozwss nicht beendet und trotzdem neu gestartet wird.
Diese Neustarts könnten tatsächlich durch mangelnden ram entstehen.
leider kann ich bei WIN kein bischen helfen
-
RAM "läuft über": Ja buchstäblich, es werden derart viele Prozesse gestartet, dass irgendwann kein Platz mehr ist und es wird fleißig ausgelagert und komprimiert.
Meldungen in ??: In der Webansicht unter "Protokolle"
Prozese doppelt: Meinst du die angeblich laufenden Adapter? Die sehe ich nur 1 mal im Task Manager bzw Process-Explorer. Wenn es um die ständig startenden WMIC und conhost geht, ist "doppelt" arg untertrieben.
@homoran said in ioBroker lässt RAM überlaufen und andere Phänomene:
Aver verstehe ich das richtig dass du einen Server X hast auf dem eine VM läuft in der Windows läuft und darin ioBroker?
Exakt!
@djmarc75 said in ioBroker lässt RAM überlaufen und andere Phänomene:
Meine Vermutung ist dass Dein "Problem" eher vom Windooze herrührt. Warum in einer VM kein Debian als Basis ?
Und warum verschwindet das Problem nicht, wenn man zu einem Stand zurück geht, an dem man sicher weiß, dass alles ok war? Auf der Maschine wird kein Update gefahren ohne es vorher zu testen und nach 3 Jahren problemlosen Betrieb glaube ich nicht, dass Windows da wirklich das Problem ist...
@annetheke sagte in ioBroker lässt RAM überlaufen und andere Phänomene:
WMIC und conhos
sagt mir gar nichts.
das log bitte als Text in code-tags posten und nicht nur auf warn gefiltert. ggf. dann in Spoiler.
in dem Ausschnitt startet anscheinend gerade alles neu, die Ursache oder was auch immer weiterhelfen könnte ist da nicht zu sehen -
@annetheke sagte in ioBroker lässt RAM überlaufen und andere Phänomene:
WMIC und conhos
sagt mir gar nichts.
das log bitte als Text in code-tags posten und nicht nur auf warn gefiltert. ggf. dann in Spoiler.
in dem Ausschnitt startet anscheinend gerade alles neu, die Ursache oder was auch immer weiterhelfen könnte ist da nicht zu sehen -
Der Error entsteht sofort beim Systemstart, da lief noch nicht ein Prozess von ioBroker
@annetheke sagte in ioBroker lässt RAM überlaufen und andere Phänomene:
Der Error entsteht sofort beim Systemstart, da lief noch nicht ein Prozess von ioBroker
Dann sollte das eigentlich auch kein Problem von ioBroker sein.
-
Dann hast du auch nicht den exakt gleichen Stand wieder erreicht
@oliverio Wenn ich einen neuen Datenträger nehme und da ein Fullbackup von einem ausgewählten Zeitpunkt drauf spiele, habe ich exakt den Softwarestand erreicht, den ich ausgewählt habe, zumal ich das auch an anderen Punkten der alten VM festmachen kann, wie ob ein bestimmtes Update des OS installiert ist oder nicht.
-
@annetheke sagte in ioBroker lässt RAM überlaufen und andere Phänomene:
2024-02-14 10:23:00.334 - info: host.HK01-MA iobroker add s7 --host HK01-MAwarum wird der beim Start neu installiert?
ist da etwas früher schiefgelaufen?@annetheke sagte in ioBroker lässt RAM überlaufen und andere Phänomene:
spawn EROFS
Read Only File System
Warum?
.... und Neustart
-
@annetheke sagte in ioBroker lässt RAM überlaufen und andere Phänomene:
2024-02-14 10:23:00.334 - info: host.HK01-MA iobroker add s7 --host HK01-MAwarum wird der beim Start neu installiert?
ist da etwas früher schiefgelaufen?@annetheke sagte in ioBroker lässt RAM überlaufen und andere Phänomene:
spawn EROFS
Read Only File System
Warum?
.... und Neustart
@homoran said in ioBroker lässt RAM überlaufen und andere Phänomene:
warum wird der beim Start neu installiert?
ist da etwas früher schiefgelaufen?Eigentlich nicht. Ich habe 2 s7 Adapter installiert und einen yahka. Schief gelaufen ist da nichts.
@homoran said in ioBroker lässt RAM überlaufen und andere Phänomene:
Read Only File System
Warum?Das Filesystem ist kein Read Only System...
-
@homoran said in ioBroker lässt RAM überlaufen und andere Phänomene:
warum wird der beim Start neu installiert?
ist da etwas früher schiefgelaufen?Eigentlich nicht. Ich habe 2 s7 Adapter installiert und einen yahka. Schief gelaufen ist da nichts.
@homoran said in ioBroker lässt RAM überlaufen und andere Phänomene:
Read Only File System
Warum?Das Filesystem ist kein Read Only System...
@annetheke sagte in ioBroker lässt RAM überlaufen und andere Phänomene:
Das Filesystem ist kein Read Only System...
das log lügt eigentlich nicht
-
@annetheke sagte in ioBroker lässt RAM überlaufen und andere Phänomene:
Das Filesystem ist kein Read Only System...
das log lügt eigentlich nicht
Es wäre ziemlich schlecht, wenn meine Systemplatte Read Only wäre, zumal ich ja fleißig Daten hin und her schicken kann... Ich habe allerdings mal grade dem ioBroker Dienst ein Benutzerkonto zugewiesen, für den Fall, dass das Systemkonto sich aus irgendwelchen Gründen weigern sollte, mitzuspielen.
-
Es wäre ziemlich schlecht, wenn meine Systemplatte Read Only wäre, zumal ich ja fleißig Daten hin und her schicken kann... Ich habe allerdings mal grade dem ioBroker Dienst ein Benutzerkonto zugewiesen, für den Fall, dass das Systemkonto sich aus irgendwelchen Gründen weigern sollte, mitzuspielen.
@annetheke
Du gehst hier durch verschiedene Schichten mit Berechtigungen und Verfügbarkeiten.
Iobroker - vm Betriebssystem - VM - hypervisor - windows - FestplattenAn jeder Stelle könnte ein Problem auftreten.
Ist das festplattenimage für die vm noch groß genug?Hast du eine Begrenzung auf Kerne/Threads eingestellt?
Der Fehler entsteht ja beim starten eines neuen Prozesses, der Brauch eine Zuordnung zu einen thread/Kern. Das könnte auch so ein Engpass sein. Der eigentlich nicht auftreten sollte.Nutzt du in der vm wieder Windows? Besser wäre ein linux Betriebssystem zu verwenden. Ich denke so eine Konstellation haben nicht wirklich viele.
-
@annetheke
Du gehst hier durch verschiedene Schichten mit Berechtigungen und Verfügbarkeiten.
Iobroker - vm Betriebssystem - VM - hypervisor - windows - FestplattenAn jeder Stelle könnte ein Problem auftreten.
Ist das festplattenimage für die vm noch groß genug?Hast du eine Begrenzung auf Kerne/Threads eingestellt?
Der Fehler entsteht ja beim starten eines neuen Prozesses, der Brauch eine Zuordnung zu einen thread/Kern. Das könnte auch so ein Engpass sein. Der eigentlich nicht auftreten sollte.Nutzt du in der vm wieder Windows? Besser wäre ein linux Betriebssystem zu verwenden. Ich denke so eine Konstellation haben nicht wirklich viele.
-
Ist nur die Frage, was sich von jetzt auf gleich geändert hat, ohne dass jemand die Maschine berührt hat... Etwas über 80GB sind frei.
@annetheke
Ja damit versuchen wir dir zu helfen.
Allerdings mit deiner Konstellation stehst du ziemlich alleine da
Xcp, Windows auf Windows virtualisiert
Etwas muss sich verändert haben und wenn sich durch ein systemupdste von Windows sich irgendein Treiber geändert hat.
Deswegen auch der Tipp bei xcp auch mal in den Foren zu forschen. -
@annetheke
Ja damit versuchen wir dir zu helfen.
Allerdings mit deiner Konstellation stehst du ziemlich alleine da
Xcp, Windows auf Windows virtualisiert
Etwas muss sich verändert haben und wenn sich durch ein systemupdste von Windows sich irgendein Treiber geändert hat.
Deswegen auch der Tipp bei xcp auch mal in den Foren zu forschen.Dafür bin ich euch auch sehr dankbar, das Projekt ist etwas Umfangreich und leider nicht mal eben neu erstellt...
Windows ist nicht auf Windows virtualisiert.
XCP - Windows mit ioBroker, mehr gibt es nicht. Treiber haben sich keine geändert, auch nicht in einem Update, da das Windows keine Treiber aktualisiert, schon gar nicht selbst, und die Treiber sich bei XCP auch nicht wirklich oft ändern, es sei denn es käme eine neue Version von XCP raus und die wären auch wieder weg, wenn man auf einen älteren Stand restauriert. Eine Beschränkung an Threads gibt es nicht und Kerne logischer Weise nicht mehr, als die Hardware selbst hat.
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 Anmelden536
Online32.8k
Benutzer82.8k
Themen1.3m
Beiträge