ist natürlich kein Fehler, mehr Resource zu haben. Trotzdem würde ich erst mal prüfen, was da eigentlich das Problem ist. Sonst rüstest Du auf und hast eventuelle nur den Erfolg, das es etwas länger dauert, bis die Condition wieder eintritt.
Bist Du mal mit auf den Raspi gegangen und hast „top“ aufgerufen? Das ist m.M. nach standardmässig auf den pi’s installiert, sonst kann man das aber auch leicht nachinstallierten.
Das gibt nämlich sehr viele Informationen aus, unter anderem die CPU-Auslastung und RAM/Swap und natürlich die laufenden Prozesse.
Wie gesagt, das ist nur einem Momentaufnahme und muss noch nichts aussagen, ggfs schaukelt sich ab und an etwas hoch, was dann zu einer Eskalation führt.
Aber vielleicht sieht man ja so schon etwas, sonst zeitnah, wenn es passiert den top starten.
Ansonsten kann man auch mit „top -b > /tmp/top.log“ den Output in eine Datei lenken um es später zu analysieren (da muss man den genaue Zeitpunkt haben).
Die Datei kann allerdings durchaus groß werden, muss man also im Auge haben.
Ich denke nicht, dass mehr Resourcen das Problem lösen.
Es gibt zu der Problematik auch einen Beitrag von mir. Bisher konnte ich keine Lösung finden, bei mir liegt es ziemlich sicher nicht am PI 3 B. Eine frische Installation läuft und kann auch shell Kommandos ausführen, das betrifft ja „alle“ dafür möglichen Komanndos. Aber wenn ich meine Symcon Installation einspiele, dann geht kein Aufruf mehr.
Bisher war ich damit allerdings ziemlich allein, aber wenn es weitere Anwender mit dem Problem gibt :o.
Hast Du mal mit top und ähnlichen Hilfsmittel geschaut? Ich würde schon vermuten, das da was zu sehen ist. eine can’t exen() / fork() hat eigentlich immer was mit dem RAM/Swap zu tun. Und dann gibt es ja noch /var/log/messages …
Das can’t exec()/fork() ist natürlich nur ein Symptom.
Auch direkt nach einem Neustart kann ich nicht „execen“, nach einer Weile lieg der bereits erweiterte Swap an der Obergrenze nahezu vollständig belegt durch Symcon.
Es gab Phasen, in denen ich „irgendetwas“ um die volle Stunde im Verdacht hatte, da der Swap schrittweise verwendet wird, aber alle Ideen führten bisher nicht zu einem Ergebnis.
Und paresy sein Vorschlag würde mich extrem viel Arbeit/Zeit kosten :eek:.
in den Konstellation (das es einzelne Prozesse sind, die das verursachen) könnte ich mir aber schon vorstellen, das eine RAM-Erhöhung was bringt. den Swap zu erhöhen geht auch, würde aber in solchen Fällen zu deutlicher Performance-Einbussen führen und natürlich die SD-Karte auch stressen.
Aber so ein kleiner PI mit viel RAM kostet ja auch nicht die Welt. Leider kann man die SD-Karte nicht einfach umstecken, da der pi4 ja eine aktuelle Version vun „buster“ verlangt.
Orkla ist ja der Betreiber der ganzen „Speedtest“-Infrastruktur und bietet ja neben der eigenen Webseite, Programmen für Win/MacOS und Apps für Mobilgeräte diverse Abrufmöglichkeiten.
Nur per shell gab’s das noch nicht - speedtest-cli ist eine Implementierung auf Basis von Python von irgendjemandem aus der Community.
Nun gibt es von Ookla eine eigene CLI-Werkzeug (siehe README). Das macht keinen Unterscheid bei üblichen bis guten Internetdurchsatz, ich hatte aber gemerkt, das > 200 MBit/s die Werte schlichtweg viel zu niedrig waren. Mit dem offiziellen Tool, was ein Binare ist, kommen da wieder korrekte Werte raus.
Ich habe Symcon auf einem Pi3B mit GB LAN und Glasfaseranschluss, garantiert 100MB, und meine gemessenen Werte sind immer um dir 40MB.
Ich glaube mich erinnern zu können, das der Flaschenhals der LAN Anschluss des Pi ist?
…ich habe jetzt mal den Speedtest von Ookla installiert und im Konfigurationsformular darauf umgestellt. Datenübernahme klappt dann noch, aber „Aktualisiere Daten“ führt dann zu der Fehlermeldung „Service nicht verfügbar“. Bin noch in der Beta-Version Deines Moduls.
hmm, hat dein pi auch schon einen 1000Mbit-ETH-Anschluss? ich meine, das alle vor dem 3B+ nur 100Mbit haben und es bleibt deutlich unter dem theoretischen Wert. Zudem gibt es bei den ältere Modellen auch Limitierung aufgrund von Memory und CpU.
