LotharGehlhaar - Teichbauforum

Hallo Leute,

ich hoffe bei Euch ist alles soweit gesund.

Ich habe seit einigen Wochen folgende Probleme mit meinem Teichraspi:

- Die Webseite des Raspi ist häufig schlecht oder auch garnicht erreichbar. Ping funktioniert immer.

- Hin und wieder erscheint auch der Screen, der normalerweise nur beim ersten Mal kommt, bei dem ich bestätigen muss, dass es sich nur um ein Testsystem handelt

- Ein Backup dauert 5-10 Minuten

- Die Zeiten für diverse Jobs mit denen ich die Schaltsteckdose steuere verändern sich selbstständig

- Und nun hat auch mal der Futterautomat, der über die einen 5s Impuls an der Steckdose gesteuert wird, nicht mehr aufgehört zu füttern. War gerade frisch befüllt

Heute habe ich ein Image der SD-Karte gezogen und diese auch gleich kopiert. Ich habe nun die alte SD-Karte in einen neuen Raspi 3 gesteckt und da läuft alles wieder einwandfrei. Der alte Raspi war ein Modell B1 V1.2. Kann es sein, dass der alte Raspi bereits an der Performance Grenze war? ich mache doch einige Temperaturmessungen, teilweise auch im Minutenbereich und erfasse auch 2 Level über US. Ich hatte eigentlich erst auf die SD-Karte getippt, aber die läuft im neuen Raspi bisher absolut stabil. Was denkt Ihr?

Habe aktuell noch auf dem Plan die Inaktivitätssteuerung noch für die Vliesendeerkennung zu aktivieren, leider funktioniert aber der US in der Klarwasserkammer gerade nur schlecht, da da aktuell auch die Umwälzpumpe für die Wärmepumpe drinhängt. Die wird da auch noch drinbleiben bis die Eisheiligen bei uns durch sind.

Gruß Kai

Hallo Kai,

hier scheint es, als ob Du bei irgendeinem Teil ein Montagsgerät erwischt hast. Jedenfalls sind solche Erscheinungen nicht typisch.

Aufschlussreich ist der Hinweis, dass die Dialoge zur Ersteinrichtung regelmäßig erscheinen. Das passiert immer dann, wenn die Teichsoftware in der MySQL-Datenbank keine Preferences vorfindet und deshalb neu anlegen muss. Zwangsläufig werden dabei alle Vorgaben, die Du bisher eingegeben hattest, mit Standardwerten belegt.

Bevor die Teichsoftware im Browser reagiert, muss sie die Preferences lesen. Wenn die aber nicht lesbar sind, ist es kein Wunder, dass Du auf die Reaktion der Teichsoftware warten musst. Nicht nur der Ping, sondern auch ssh sollten trotzdem ohne Wartezeit reagieren?


Als Ursache dafür fallen mir nur zwei Sachen ein.

• Spontane Stromunterbrechungen, Wackelkontakt?
  Wie bei jedem Computer hat eine Unterbrechung fatale Folgen, wenn der Strom gerade dann ausfällt, wenn der Rechner mit einem Schreibvorgang beschäftigt ist. Und gerade die Preferences werden in jeder Minute einmal beschrieben.
  Eigentlich ist diese Ursache relativ unwahrscheinlich, denn das hättest Du gewiss bei anderen Anwendungen und anderer Hardware bemerkt.
• Ein Defekt der SD-Karte
  Unter Umständen könnte die Karte irgendwie vergessen, was der Raspi da drauf geschrieben hat. Praktisch könnte das Staubkorn genau dort auf dem Chip liegen, wo die MySQL-Datenbank liegt?
  Es wäre nicht die erste SD-Karte, die in einem Raspi ihren Geist aufgegeben hat. Praktisch kommt es dann in der Regel zu einem Totalausfall.

Ob die Daten auf dem Image noch konsistent sind, muss sich wohl herausstellen. Du solltest mal schauen, ob Du zu dieser Karte noch Vertrauen haben kannst. Immerhin sind auf dieser Karte mehrmals die Preferences verloren gegangen.

Im Normalbetrieb wird er sich die meiste Zeit langweilen. Eng wird es nur, wenn ein Backup gezogen wird oder wenn eine Datenbank rekonstruiert wird.
Der Konsolenbefehl gibt dafür relativ zuverlässig Auskunft. Wenn der alte Raspi gerade nichts zu tun hat, kannst Du den ja mal leer laufen lassen und die Konsole dabei beobachten.


Pfiffikus,
der auch noch so einen alten Raspi am Teich hängen hat

Eine andere Möglichkeit wäre auch noch das eingesetzte Netzteil. Auch dieses kann mit der Zeit den Geist aufgeben, und würde so zum Neustart/Stromausfall führen.

_________________
Gruß Robert

www.koifutterhandel.de

Hallo Gunter und Robert,

vielen Dank erst mal für Eure Hinweise. Ich hab den alten Raspi inkl. etwas weniger altem Netzteil (musste ich schon mal tauschen) jetzt hier auf dem Tisch liegen und werden ihn mal mit der Kopie der SD-Karte (also die neue) in Betrieb nehmen. Da hängen dann zwar keine Sensoren und USB Steckdose dran, das sollte aber meines Erachtens wenig Einfluß auf die Performance nehmen.
Sobald mit die alte SD-Karte im neuen Raspi ärgert, wird sie natürlich sofort getauscht. Bisher läuft sie da aber einwandfrei, mit ungeahnter Performance (vermutlich im Wesentlichen Aufgrund des deutlich schnelleren Raspis). Ich habe ja außer Temperatur- und Levelmessungen und Steuerung der Fütterung, Wasserwechsel und Bachlauf nichts in der Steuerung drin, sodass es da nicht kritisch ist, wenn der Raspi erneut mal ein Tag ausfallen sollte. Insofern riskiere ich das jetzt erstmal mit der alten SD-Karte, nicht weil ich sparen will, sondern mehr weil ich der Ursache auf den Grund gehen will.

Der Raspi war übrigens jederzeit anpingbar, SSH hatte ich nicht wirklich probiert.

Ich berichte wieder, wenn ich neue Erkenntnisse habe.

Gruß Kai

Hallo,

ich nochmal. Habe jetzt direkt den alten Raspi mit der neuen SD-Karte angeschlossen und mal htop gestartet. Zum Vergleich auch am neuen Raspi. Seht selbst. Sieht mit doch nach nem Performance Problem aus. Der Raspi reagiert auch nachwievor sehr träge.

Gruß Kai

Hallo,

hier noch ein ein Screenshot von einem Levelsensor, der mal für den Teichlevel vorgesehen ist, aber aktuell noch die ziemlich konstante Raumhöhe misst. Um ca. 10h habe ich den neuen Raspi drangehängt. Das spricht eigentlich auch Bände. Bis jetzt läuft das Teil wieder echt top.

Gruß Kai

Hallo Kai,

dieser Effekt der Ausreißer ist bekannt. In dem Artikel, den Bernhard verlinkt hatte, wird das auf die Tätigkeit einer Spinne zurückgeführt. Doch die Ursache scheint uns im Betriebssystem vom Raspi selbst zu liegen. Dieses Linux ist in der Lage, mehrere Prozesse im Multitasking abzuarbeiten. Dieses Python-Skript, mit dem der Sensor angesteuert wird, verhält sich sehr "nice". Wenn dann im Hintergrund irgendein anderer Prozess läuft, der weniger "nice" eingestellt ist, kriegt der mehr Prozessorzeit ab.

Normalerweise wird zum Zwecke der Messung ein Ultraschall-Impuls versandt. Anschließend wird gewartet, bis irgendwann mal ein Echo ankommt. Während dieser Wartezeit verteilt der Linux-Kernel Rechenzeit an alle anderen Prozesse, die gleichzeitig laufen, hin und wieder auch an das Echolot-Skript. Für die Verhältnisse eines Computers ist die Laufzeit des Ultraschallimpulses nämlich eine ewig lange Zeit. Es geht einige Male reihum. Aber irgendwann ist es dann soweit. Das Skript registriert das Eintreffen des Echos und schaut auf die Uhr, um die Laufzeit zu ermitteln und daraus die Entfernung zu errechnen.

Hin und wieder kann es zu einem Szenario kommen, dass der Sensor einen Ultraschallimpuls absendet. Doch gerade, wenn der Echo-Impuls eintrifft, ist der Prozessor mit einem anderen Prozess beschäftigt, der eine höhere Priorität besitzt. Dieser andere Prozess wird dann erstmal abgearbeitet. Erst dann teilt der Kernel den Prozessor wieder dem Echolot-Skript zu. Erst dann kann das Eintreffen des Echos bemerkt und auf die interne Recheruhr geschaut werden. Das ist natürlich viel zu spät, deshalb wird eine zu hohe Laufzeit gemessen und in Deiner Grafik scheint der Wasserstand bei diesen Ausreißer-Messungen unermesslich abzusinken.



Dennis hatte sich mal intensiv um dieses Problem gekümmert und das Python-Skript optimiert. Es werden viele Messungen hintereinander durchgeführt und gemittelt. Anschließend schaut das Skript nach, ob innerhalb dieser Sekundenbruchteile Ausreißerwerte vorkommen, die verworfen werden. Mit diesem Trick waren solche Ausreißer wie in Deiner Grafik zu sehen, eigentlich Geschichte.


Pfiffikus,
der nicht weiß, warum das bei Dir wieder vorkommt

Anzeige:

_________________
Wenn du einen Monat lang ein werbefreies Forum willst, klicke hier und überweise mir 100 Taler!
Wenn du mich im Koi-Schnack etwas fragen möchtest, klicke hier!

Hallo Gunter,

ich glaube jetzt hast Du nur mein letzten Beitrag angeschaut. Schau die mal den mit den beiden htop-Screenshots an. Der alte Raspi war meines Erachtens total überlastet. Mit dem neuen performanteren Modell läuft alles wieder top. Da ist also eigentlich nichts im Code zu optimieren.

Gruß Kai

Hallo Kai,

die htop-Screenshots hatte ich im Blick.

Praktisch stelle ich fest, dass diese Last nicht typisch ist. Bei mir hängt auch noch der alte Raspi am Teich, der sich in der meisten Zeit langweilt. Es läuft dieselbe Software und es ergibt sich dieses Bild. Nur jeweils zur vollen Minute geht die Last nach oben, wenn die einzelnen Jobs auszuführen sind.



Ohne Frage steckt der neue Raspi die Last besser weg. Aber die Frage ist natürlich, was es bei Dir in Deinem Versuchsaufbau so alles zu tun gibt, warum dort eine so große Last entsteht, mit der Dein kleiner Raspi an seine Grenzen gelangt.



Pfiffikus,
der Euch allen ein frohes und ruhiges Osterfest wünscht