UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[A Former User]

@homoran said in iobroker Absturz:

nicht wirklich!
es gibt genug User, die bequem mit 2GB auskommen, tlw. überraschenderweise sogar mit 1GB.

War vielleicht missverständlich ausgedrückt von mir. Damit meinte ich den RAM.
Zeig mir den Raspi, der heute überraschenderweise gut mit 1 GB RAM auskommt.

Ich bleibe dabei - SWAP ist fertig: Swap: 209M 208M 1.7M
Er kann dann im Zweifel nicht mehr zuweisen und bumm.

[Homoran]

@rscsb sagte in iobroker Absturz:

Damit meinte ich den RAM.

ich auch

@rscsb sagte in iobroker Absturz:

SWAP ist fertig: Swap: 209M 208M 1.7M

gut, da hab ich schief gelesen.
aber wie gesagt ist mir das auch bei 8GB RAM passiert, warum auch immer.

aber bei

@pb74 sagte in iobroker Absturz:

1226.5 avail Mem

müsste erstmal gar nichts ausgelagert werden.

Die Ursache ist eher in zu hoher load average zu suchen.
und die wird mit mehr auslagern nicht geringer

[A Former User]

@homoran said in iobroker Absturz:

bei ihm ist da noch Luft

1,7M - is nich viel Luft

I/O wegen dauernden Auslagerns

das wirkt sich besonders dann aus, wenn von allem besonders wenig da ist.

[Homoran]

@rscsb sagte in iobroker Absturz:

1,7M - is nich viel Luft

sag ich doch

@homoran sagte in iobroker Absturz:

gut, da hab ich schief gelesen.

hab da 170mb gesehen

sieh mal hier

mit 8gb RAM und 4500 available

[A Former User]

@homoran said in iobroker Absturz:

Du weißt, dass Du da auch die SWAP-Spalte dazu einblenden kannst ?!
Dann siehst Du unter Umständen auch, welcher Prozess den Speicher füllt.

[Homoran]

@rscsb sagte in iobroker Absturz:

Dann siehst Du unter Umständen auch, welcher Prozess den Speicher füllt.

ich könnte wetten nach einem reboot ist das weg.
Hab ich in 10 Jahren iob noch nie gehabt.

ich nehme allerdings an, dass das backitup beim Packen von 64GB history war, wo der verfügbare RAM nicht schnell genug umgeschichtet wurde.
oder es stammt vom letzten größeren OS Update.

Ähnliches wird auch bei @PB74 der Fall sein, weshalb mich das in diesem Fall erst einmal gar nicht interessiert, da bei ihm ausreichend und bei mir reichlich verfügbarer RAM existiert.

Seine Abstürze / Lähmung des Systems kommen nach meiner Betrachtung vom zu hohen I/O weil wahrscheinlich die USB-Platte am USB3 hängt, was wegen hochfrequenter Störungen durch die CPU zu genau diesem Effekt führt.

Einen weiteren Thread hatten wir gerade erst, wo die load average nach Umstecken auf USB2 auf 1/4 der bisherigen Last fiel.

[PB74]

@pb74 wo höngt die USB-Platte dran?

Die SSD hängt mit dieser USB A-A Brücke am USB3 Anschluss:

[MartinP]

So sieht es auf meiner Kiste aus (in PVE shell selber).

top - 19:43:01 up 1 day,  4:03,  2 users,  load average: 3.27, 2.38, 2.23
Tasks: 485 total,   1 running, 484 sleeping,   0 stopped,   0 zombie
%Cpu(s): 41.6 us, 26.0 sy,  0.0 ni, 25.8 id,  1.5 wa,  0.0 hi,  5.1 si,  0.0 st 
MiB Mem :   7792.8 total,   1064.7 free,   3663.7 used,   3468.2 buff/cache     
MiB Swap:   7800.0 total,   6292.7 free,   1507.2 used.   4129.1 avail Mem 

Keine Abstürze

Die Uptime ist nur gut 1 Tag, weil gestern ein neues Kernel gekommen ist, und deshalb ein Neustart fällig war ...

[PB74]

Der Raspberry lässt sich anpingen, ist aber per SSH nicht erreichbar. Monitor / Tastatur / Maus direkt am Raspberry habe ich noch nicht testen können.

Ich lasse den Raspi jetzt in diesem Zustand mal stehen, vielleicht hat noch jemand andere Ideen bzgl. Zugriff.

Ansonsten kann ich leider frühestens morgen abend weiter testen....

[Homoran]

@pb74 sagte in iobroker Absturz:

Der Raspberry lässt sich anpingen, ist aber per SSH nicht erreichbar.

das sieht nach Überlastung und damit zu hoher load average aus.

kannst du schon mal sagen ob die USB Platte am USB3 hängt?

EDIT:
Sorry übersehen!
Häng die Platte bitte beim nächsten runterfahren an USB2

[Homoran]

@martinp das ist aber kein Raspi mit USB Platte

[PB74]

Ich könnte ein USB3 A-A Kabel anstelle der Brücke einstecken, damit die SSD mit einem USB2-Anschluss verbunden ist.

Dazu müsste ich aber den Raspberry "hart" runterfahren...

[Homoran]

@pb74 sagte in iobroker Absturz:

Dazu müsste ich aber den Raspberry "hart" runterfahren...

Deswegen solltest du das machen, wenn der Raspi sowieso mal sauber down ist.

[PB74]

@homoran

Da ist nur die Frage, wie ich den Raspi jetzt sauber runterfahren könnte...

[Homoran]

@pb74 sagte in iobroker Absturz:

@homoran

Da ist nur die Frage, wie ich den Raspi jetzt sauber runterfahren könnte...

@pb74 sagte in iobroker Absturz:

Monitor / Tastatur / Maus direkt am Raspberry

und dann den Linux Affengriff

https://de.m.wikipedia.org/wiki/Klammergriff#Linux

Insbesondere REISUB

[MartinP]

Eine Seite mit Hinweisen zum mMonitoring der Spannungsversorgung des Pi

https://gist.github.com/Paraphraser/17fb6320d0e896c6446fb886e1207c7e

[Homoran]

@martinp sagte in iobroker Absturz:

zum mMonitoring der Spannungsversorgung des Pi

da gibt es bei @PB74 keine Probleme.
Das hätte im diag gestanden

[PB74]

Guten Morgen,

seit heute früh 0:00 Uhr läuft der iobroker wieder... ich habe nicht eingegriffen.

Es wäre schon ein komischer Zufall, wenn zu dieser Zeit die Netzversorgung ausgefallen und daraus der "harte" Neustart des Systems zustande gekommen wäre...

Ich kann leider erst heute Abend dann die Diagnose laufen lassen und mal in die Protokolle schauen.

[Homoran]

@pb74 sagte in iobroker Absturz:

Es wäre schon ein komischer Zufall, wenn zu dieser Zeit die Netzversorgung ausgefallen und daraus der "harte" Neustart des Systems zustande gekommen wäre...

Wird auch nicht so sein.
Der Stau wird (zu langsam) abgearbeitet worden sein, so dass die load average wieder annehmbar gewesen sein wird.

[PB74]

Ich werde den Raspberry dann heute Abend mal runterfahren, die SSD an USB2 anschließen und wieder berichten.