Raspi - Ende vom RAM? Falls Ja, was nun….?
-
dass nur beim Cubietruck ein NAND wäre `
Beim Cubietruck wird vermutlich eine nicht standardisierte Schnittstelle zum NAND-Flash verwendet. -
Bei jedem deiner Posts bekomme ich mehr graue Haare `
:lol: :lol: :lol:
@Homoran:Das ist dann ja noch ein RAM-Fresser mehr. der Container für die piVCCU….. `
Du hast mich falsch verstanden - Ich habe einen PI mit der CCU2 drauf, einen PI mit der CCU als Gateway und einen PI für IoBroker. Ich meinte nun, den PI der nur das Gateway hat neu zu machen und als Slave zu verwenden. Nicht den Pi wo IoB jetzt drauf läuft und auch nicht den wo meine CCU2 drauf rennt
@Homoran:Alle Änderungen von States des Slaves müssen mit dem Master in Echtzeit kommuniziert werden…. `
Und das ist dann da K.O. Kriterium. Der geht nur über WLAN weil ich dort kein Kabel habe
Wenn ich jetzt Paul seinen Betrag richtig verstehe wäre ein Tinkerboard also eine brauchbare Alternative und würde das RAM Problem lösen ohne mir die nächsten Probleme zu machen?
-
Beim M3 habe ich ein aktuelles (??) Ubuntu Mate gefunden und installiert.
Während der Installation waren 356 Pakete veraltet und beim Update && upgrade lag die Temperatur an 60°C
top - 01:30:38 up 14 min, 3 users, load average: 1.77, 1.40, 0.84 Tasks: 204 total, 3 running, 201 sleeping, 0 stopped, 0 zombie %Cpu(s): 7.9 us, 5.9 sy, 0.0 ni, 83.9 id, 2.0 wa, 0.0 hi, 0.3 si, 0.0 st KiB Mem : 2057572 total, 756364 free, 266960 used, 1034248 buff/cache KiB Swap: 262140 total, 262140 free, 0 used. 1736810 avail Mem root@bpi-iot-ros-ai:~# cat /sys/class/thermal/thermal_zone0/temp 58Ein tropfen alkoholfreies Bier auf den Kühlkörper senkte kurzzeitig auf 54°C :lol: :lol:
Dann wieder
root@bpi-iot-ros-ai:~# cat /sys/class/thermal/thermal_zone0/temp 67Gruß
Rainer
-
Ich habe mich vor einem Jahr gegen den Einsatz von einem PI3 oder anderen Einplatinen PC entschieden.
Ram war erst mal nicht der Grund, aber die Ausfallsicherheit und die Skalierbarkeit.
Wenn die MicroSD Karte mal kaputt geht, was durchaus passiert muss man erst mal eine neue da haben und ein Aktuelles Image liegt ja auch nicht immer gleich rum usw.
Geht der PI mal kaputt was aus Erfahrung eher selten ist ( ca. 200 Stück Beruflich im Einsatz ), braucht man Ersatz Hardware.
So was passiert immer dann, wenn Samstag Abend ist und 3 Feiertage vor einem sind. :mrgreen:
Dazu ist das dann gerade nicht lieferbar….
Weiterhin möchte ich Basteln können ohne das Livesystem versehentlich zu zerlegen.
Auch durch das Installieren und ausprobieren von Adaptern geht mal was kaputt und läuft dann nicht mehr.
Da man ja immer "mal eben" was machen will, wird es dann wieder schnell spät und man kann nicht aufhören weil ja gerade was kaputt ist.
Daher nutze ich einen NUC und als Betriebssystem Ubuntu Server
Da drauf dann Virtualbox und weitere Ubuntu Server.
Installation von IoBroker auf Ubuntu Server ist einfach.
Und das beste überhaupt.
Zum Basteln einfach eine Kopie der VM machen eine anhalten und die andere starten und spielen.
Will man die Änderungen doch nicht haben, löscht man die VM wieder und startet die alte.
Geht der NUC mal kaputt. Kopiere ich die VM auf mein Rechner und starte diese. Dauert 5min und alles läuft wieder.
So bestimme ich, wann ich an dem System arbeite und nicht das System mir.
Was hier wohl los wäre zu Hause, wenn die ganzen Komfort Geschichten mal eine Woche nicht laufen. :geek:
-
Daher nutze ich einen NUC und als Betriebssystem Ubuntu Server
Da drauf dann Virtualbox und weitere Ubuntu Server. `
Das geht aber nur mit "höheren" NUCs (schätze mal ab i5 ist das erst sinnvoll.mein LowCost PPYH oder CPYH taugt nur für natives Linux.
Gruß
Rainer
-
` > Das geht aber nur mit "höheren" NUCs (schätze mal ab i5 ist das erst sinnvoll.
mein LowCost PPYH oder CPYH taugt nur für natives Linux. `
Das sehe ich anders, weil ich einen nutze. :mrgreen:
Das Master Sytem hat eine Load Average von < 1 im Schnitt.
Ich habe sogar eine Gui drauf laufen, um die VMs einfacher verwalten zu können.
Dazu laufen aktuell 2 VMs ( IoBroker , UnifiController )
Die VMs brauchen ja alle kaum CPU, von daher sehe ich das recht entspannt.
Leider nur 4gb Ram, lag noch daheim rum. 8gb wären für weiter VMs Pflicht.
Eine würde aber noch gehen
-
Ja mit VMs zu Arbeiten ist sicherlich auch eine, wenn nicht sogar die Lösung aber aktuell glaub ich, dass ich doch erst einmal beim Raspi bleibe und dann ggf. auf Tinkerboard wechsele.
Nachdem ich den Artikel zum RAM bei Linux durchgelesen habe und mich dann noch mal mit den blöden Angaben zur CPU Auslastung unter Linux beschäftigt habe bin ich grad zu dem Schluß gekommen, dass der PI3 noch was Luft hat. Wenn dann geht ihm echt zuerst der RAM aus und dann kommt nen Tinkerboard.
Tja und was die Ausfall-Sicherheit angeht - ich habe 4 PI im Einsatz, 2 davon könnten schon mal ne ganze Weile aus sein ohne das es nennenswerte Auswirkungen hätte. Backup-Hardware ist also da
Wenn ich was ändere, mach ich immer ne Kopie der SD Karte und habe so allein vom IOBroker immer 3 32GB SD Karten, welche ich nur reinstecken müsste. Für mich bin ich damit gut gegen Ausfälle gewappnet.
-
Eine Master/Slave Lösung auf einer anderen Art und weise wäre auch Nice.
Quasi ein Master IoBroker, aber alle Daten werden immer Syncron mit allen Slaves gehalten.
Die Slaves machen nichts als die Daten aufzunehmen. Bricht der Master weg kann man einen Slave zum Master machen.
Den alten Master "reparieren" und als Slave wieder einhängen.
Wüsste nur nicht so recht wie man das mit der Ip Adresse lösen könnte. Dafür brauchte es wohl eine Art Failover IP.
Aber so was, wäre schon sehr charmant.
-
So was versuche ich schon länger (halbherzig) z.B. mit MQTT. ein solch redundantes System wäre einfach nur toll.
Aber:
irgendwo muss einer sein, der das ganze synchronisiert. und wenn der ausfällt ist Essig!
Gruß
Rainer
-
> irgendwo muss einer sein, der das ganze synchronisiert. und wenn der ausfällt ist Essig!MySql als Beispiel läuft sehr gut in so einer Umgebung.
Der Master verteilt halt an alle Salves weiter.
Bricht der Master weg muss man natürlich eingreifen, aber aus einem Slave einen Master zu machen ist ja nicht so kompliziert.
Eine Wirkliche Synchronisation wäre dies ja nicht, weil es ja nur in eine Richtung gehen würde.
-
Was du hier beschreibst ist nicht nur Master/Slave sondern richtig failover das ist programmiertechnisch etwas schwieriger.
Bei Datenbanken ist das etwas einfacher als laufender Software
–-----------------------
Send from mobile device
Das schöne ios hat Auto Korrektur zum k****
Wer Schreibfehler findet darf sie behalten oder auf eBay verkaufen, mindest Umsatz 10% für die community
-
Wahrscheinlich weil iobroker die Daten nicht live speichert sondern das nur alle x Sekunden macht?
Also die Daten im RAM verweilen.?
-
Wahrscheinlich weil iobroker die Daten nicht live speichert sondern das nur alle x Sekunden macht?
Also die Daten im RAM verweilen.? `
Nein!
Die Daten werden in einen object Datenbank als Datei gespeichert auf der Festplatte oder in einer redis DB (wie man möchte beides ist Acer local auf den Gerät. Redis Remote währe möglich).
Aber alle Installationen zb Adapter liegen im File System auf der Festplatte.
Eine Software die zB failover hat speichert alles in einer Datenbank und hat halt verschiedene Webserver die auf dieselbe Datenbank zugreifen.
Fällt eine aus kann die andere weiterlaufen.
Datenbank dahinter muss natürlich auch redundant sein.
Wie gesagt ist nicht einfach komplett zu integrieren
–-----------------------
Send from mobile device
Das schöne ios hat Auto Korrektur zum k****
Wer Schreibfehler findet darf sie behalten oder auf eBay verkaufen, mindest Umsatz 10% für die community
-
Ich mache einfach Master / Slave und habe einen zweiten Master mit gleicher IP-Adresse ausgeschaltet.
Zwischen durch nehme ich den orginal Master mal eben vom Netz und spiele aktuelles Backup oder iobroker Ordner in den Master (Reserve) ein.
Wenn der Master ausfällt ist der Reserve in 5min Betriebsbereit.
-
Auch eine gute Idee.
Ich halte meine VM an und mache dann einen Export der VM.
Also die wird nicht neugestartet.
Aber da schweifen wir dann wohl auch vom Thema ab.
Von einem PI hat mich immer die microSd Karte abgeschreckt. Wir nutzen ca. 200 PIs von Version 1-3 für wirklich einfache aufgaben welche kaum auf der Karte schreiben.
Dennoch stirbt im Schnitt eine Karte die Woche. Manche laufen seit Jahren manche schaffen nicht mal 2 Monate.
Leider sind slc micro sd Karten oder USB Sticks doch recht teuer.
-
eine micro SD Karte ist mir beim Pi auch schon mal hops geganngen. Dafür aber ein USB Stick noch nie…
Habe ständig zwei RPI am laufen. Ich finde die USB-Datenträger sehr robust. Meine zwei VU+Zero Receiver im Schlaff und Gästezimmer zeichnen schon seit Jahren auf den USB Stick auf. Bis heute noch nichts passiert.
