[Lösung gefunden] Multihost - Vor- & Nachteile ??
-
@bahnuhr sagte in Multihost - Vor- & Nachteile ??:
dann biste ja ein blitzmerker
Ach weisste, manchmal hab ich auch mal das Hirn frei, dann setz ich sowas schnell um....
und trotzdem weiss ich bis heute noch nicht wie man sich als Root auf einem Linuxsystem anmeldet
Und das soll auch so bleiben
-
@djmarc75 sagte in Multihost - Vor- & Nachteile ??:
Root auf einem Linuxsystem anmeldet
da hätte ich sogar eine Anleitung für dich
-
@bahnuhr sagte in Multihost - Vor- & Nachteile ??:
da hätte ich sogar eine Anleitung für dich
BITTE NICHT !!!!
-
Ich hatte ´mal die Idee (aber noch nicht getestet/umgesetzt), auf einem Master (raspi 4B) / Slave (raspi 3B) System Adapter/Instanzen wie z. B. history oder flot (also welche ohne Gerätezugriff) auf den Slave zu verschieben, um den Master von "Rechenarbeit" zu entlasten (weil meine VIS manchmal etwas "träge" ist, wenn ich flot-Diagramme anzeigen lasse). Haltet Ihr das für eine gute Idee oder sollte man das lieber sein lassen?
-
@andersmacher sagte in [Lösung gefunden] Multihost - Vor- & Nachteile ??:
sollte man das lieber sein lassen?
es wird nichts bringen außer zusätzlichem Netzwerktraffic.
Die Dateien und die Verwaltung wird auf dem Master durchgführt
-
@homoran Danke für Deine Rückmeldung!
Da habe ich dann offenbar das Master-/Slave-Konzept noch nicht verstanden.
Muß ich Deine Antwort so verstehen, daß eine flot-Diagrammanfrage aus VIS heraus tatsächlich bezüglich CPU-Leistung immer den Master und niemals den Slave "belastet".
Was läuft denn dann auf dem Slave überhaupt, wenn man dort einen Adapter bzw. eine Instanz liegen hat oder "hinschiebt"?Ich hatte noch vergessen anzugeben, daß ich die History-Daten derzeit auf einem USB-Stick speichere (also nicht auf der SD-Karte, um diese nicht mit Schreibzugriffen "abzunutzen") und ich diesen Stick dann natürlich auch an den Slave hängen würde (momentan hängt er am Master).
-
@andersmacher sagte in [Lösung gefunden] Multihost - Vor- & Nachteile ??:
daß eine flot-Diagrammanfrage aus VIS heraus tatsächlich bezüglich CPU-Leistung immer den Master und niemals den Slave "belastet".
du benutzst so böse, harte Worte wie immer und niemals
Ich kann dir dazu leider wirklich nichts genaues sagen. Wenn du history auf dem Slave laufen hast und dort auch den Stick mit den Daten dran, wird die Rechenarbeit für das Auslesen der Daten und das Aggregieren auf dem Slave stattfinden.
Die Verwaltung der Objects und States findet trotzdem auf dem Master statt.
Inwieweit das jetzt den Master mehr oder wieviel weniger als den Slave belastet kann ich dir nicht sagen. -
@andersmacher sagte in [Lösung gefunden] Multihost - Vor- & Nachteile ??:
@homoran Danke für Deine Rückmeldung!
Da habe ich dann offenbar das Master-/Slave-Konzept noch nicht verstanden.
Muß ich Deine Antwort so verstehen, daß eine flot-Diagrammanfrage aus VIS heraus tatsächlich bezüglich CPU-Leistung immer den Master und niemals den Slave "belastet".
Was läuft denn dann auf dem Slave überhaupt, wenn man dort einen Adapter bzw. eine Instanz liegen hat oder "hinschiebt"?Jede Instanz die auf dem Slave gestartet wird läuft auf dem Slave. Das heisst alle Berechnungen laufen auf dem Slave. Sofern ich das recht erinnere wird eine Vis sofern auf dem Slave auch ein Web Adapter läuft direkt auf dem Slave erzeugt. Auch Flot Abfragen (die primär auf die Daten eines History Adapters zugreifen) laufen damit auf dem Slave ab.
Soweit also so gut. Allerdings liegen die States und Objekte üblicherweise (Es gibt da eine alternative) auf dem Master. Damit sollte ein auf dem Slave laufender History Adapter die Änderungen der einzubeziehenden States über das Netz vom Master erhalten und dann im Dateisystem des Slave abspeichern. Der FLOT Adapter (auf dem Slave) würde dann auch direkt auf die History Daten vom Slave zugreifen - soweit ok.
Ich hatte noch vergessen anzugeben, daß ich die History-Daten derzeit auf einem USB-Stick speichere (also nicht auf der SD-Karte, um diese nicht mit Schreibzugriffen "abzunutzen") und ich diesen Stick dann natürlich auch an den Slave hängen würde (momentan hängt er am Master).
Vom speichern der History-Daten auf einem USB Stick würde ich generell abraten. Die USB Sticks sind noch weniger als die SD Karten auf ständige Schreibzugriffe ausgelegt - diese sterben noch schneller als die SD Karte. Dazu kommt das der Schreib/Lesezugriff auf den USB Stick auch verhältnismässig langsam ist, so das das Schreiben der Daten und das auslesen der Daten für Graphiken eher langsam erfolgt.
Ich hoffe das bringt etwas dunkel ins Licht. (oder so)
A.
-
@homoran Ja, ja, ich da wohl öfter mal zu "digital" in der Formulierung
Aber so, wie Du es jetzt formulierst ("...Rechenarbeit für das Auslesen der Daten und das Aggregieren auf dem Slave stattfinden.") geht das schon in die Richtung, die ich mir als "Entlastung des Masters" vorgestellt hatte. Ist dann wohl doch mal einen Versuch wert, denn ich würde annehmen, daß sich gerade bei flot und history das mit den Objects und States in Grenzen halten müßte und das ja auch jetzt schon auf dem Master läuft und es daher ja eigentlich nichts verschlimmbessern sollte.
-
Ich würde, bevor ich das Setup unnötigerweise komplexer mache als notwendig, erstmal schauen ob das bisherige System überhaupt in den Grenzbereich reingeht und da per Split überhaupt was gewonnen werden kann.
-
zum Thema USB Stick:
ich habe damals als das Thema sterbende SDSD Karten überhand nahm. und gerade der Pi4-2GB rauskam bewusst eine SD Karte genommen und genauso bewusst history.
Dann auf tTeufel komm raus Daten geloggt, teilweise im 6-Sekundentakt 24 Datenpunkte.
Die Karte lebt heute immer noch! -
@asgothian Auch Dir Danke, für die ausführliche Erklärung, die ja wohl tendenziell in die gleiche Richtung läuft.
USB-Sticks habe ich auch genutzt, weil ich davon noch einige habe, die ich für nichts anderes mehr benutze und ich dann auch im Fall eines Ausfalls eines Sticks (allerdings läuft da seit ca. 3a noch immer die 1. Bestückung) nicht gleich ein Problem mit dem ganzen ioBroker habe.
Wenn das mit den "manchmal trägen Diagrammen" allerdings ein selbstgemachtes Problem durch langsame USB-Sticks ist, muß ich da mal ran.
@thomas-braun Bis jetzt schien es mir jedoch so, daß immer, wenn die Diagramme mal hakten, die CPU-Auslastung auch sehr hoch war. Daher meine oben beschriebene ursprüngliche Idee. -
@andersmacher sagte in [Lösung gefunden] Multihost - Vor- & Nachteile ??:
die CPU-Auslastung auch sehr hoch war.
Die kann aber auch durch langsame USB-Sticks nach oben getrieben werden.
-
@thomas-braun Danke für die Info!
-
@andersmacher sagte in [Lösung gefunden] Multihost - Vor- & Nachteile ??:
Bis jetzt schien es mir jedoch so, daß immer, wenn die Diagramme mal hakten, die CPU-Auslastung auch sehr hoch war.
Je nachdem welche Aggregation, wieviele Datenreihen jnd wieviele Rohdaten für deinen chart verwendet werden, ist da schon einiges an Rechenleistung notwendig. Bei mir sehe ich es teilweise sogar am Stromverbrauch des NUC, wenn ich solche charts zoome.
Allerdings geht die System load average auch dann hoch wenn es viele anstehende I/O Vorgänge in der Pipelibe gibt, die nicht abgearbeitet werden, weil z.B. das Medium zu langsam ist.
-
Genau das mit der höhren I/O-Last durch langsame Medien wird auch hier beschrieben:
-
@thomas-braun
@Homoran
Ok, habe ich mir also durch meine "USB-Stick-Verwertung" u. U. selber einen Flaschenhals geschaffen. Muß ich dann wohl wirklich mal angehen, wenn das mit den "langsamen diagrammen" schlimmer/häufiger wird. -
@andersmacher beim pi4 aber nicht den USB3 Port nehmen. Das kann zu massiven Störimpulsen komnen
