Hmm, das bringt mich auf eine Idee, welche ich mal kontrollieren muss.
Ich lass immer die Console im Browser offen, auch wenn ich nix mehr mache! Dann geht mein Rechner nach einer entsprechenden Zeit in den Standby. Mal schauen ob man da was zeitlich abgleichen kann!
Fruß Heiko
Alternativ hatte Kronos auch beobachtet, dass bei einem abgebrochenem/feststeckenden RTSP Stream der RAM Verbraucht steigt. Nutzt du evtl. RTSP Streams?
paresy
ich mache heute abend das update auf die Beta 5.3.
VOIP nutze ich nicht
RTSP Streams habe ich ebenfalls nicht in IPS eingebettet…
Ich habe zwar ein Stream im Webfront auf irgendeiner tiefen Seite eingebunden, aber aufgerufen wird die nie!
Soll ich den mal rausschmeißen? Das Webfront ansich läuft bei mir immer auf einem Tablet an der Wand!?
Gruß Heiko
Ich hab mir mit ein paar Updates auf dem Razby - meinen Razby abgeschossen…
Dadurch konnte ich zwangsweise von Pi B+ auf ein PI 3+ mit neuerem Razberry Steckmodul umsteigen.
Die Rücksicherung durch Z-Way hat problemlos funktioniert.
Die Rücksicherung von IPS hat ebenfalls problemlos funktioniert.
Ne neue SD Karte ist ebenfalls drin.
Der Zwangsumzug ist klasse - an einigen Stellen ist IPS deutlich schneller geworden…
Nun läuft ein Raspbian Buster -ohne Altlasten- und ein IPS 5.3 Beta in Kernel 06.12.2019, 0717398f8fbc.
Mal schauen ob es die Abstürze noch weiterhin gibt, oder ob sich mit eine der Aktionen hier das erledigt hat…
P.S. ich kann z-way als Backup für Zwave.me Zwave Gateways nur empfehlen…
I have a WebFront tab that shows two RSTP streams from a 6MP Dahua camera. I’ve experienced crashes on at least three occasions when WebFront was running in an open Chrome window and my MacBook went in sleep mode after some while. So far no crashes while actively viewing the streams.
I am currently using IPS 5.3 revision 321402ec4fe0, platform armhf on an Odroid XU4 with 2GB RAM and Ubuntu 18.04.3 LTS.
I have had this issue in 5.2 too.
Update von der Speicherfront
gestern ging wieder der Speiche zu Ende - das habe ich gleich genutzt um auf die letzte Version (6.12.) zu wechseln (hatte die vorletzte am Laufen).
Dannach nur ganz kurz geschaut ob alles läuft und dann die Console geschlossen (lass ich normalerweise offen) und auch PC (Arbeits-PC) runtergefahren.
Heute morgen traue ich meine Augen nicht - Speicher unverändert hoch … den ganzen Tag :))
Anbei die Speicherverläufe (Woche, Vor/Nach Installation, Tag über)
So kann es bleiben 
Hallo pitti,
das heißt, du hast zwei Dinge auf einmal geändert (neue Version und Konsole geschlossen gelassen)?
Dann wissen wir jetzt leider immer noch nicht, was von beidem dazu führte.
Oder hattest du eins davon schon zuvor getestet?
Gruß
Slummi
Ja, sorry :mad:
Ich habe die letzten 2 Tage auch sehr wenig Zeit an der Console verbracht - der Speicher steht wie eine 1 - unverändert gut!
Ich schau weiter!
Gruß Heiko
Hallo,
bei mir ist es unter der aktuellen 5.3er Beta (vorher stable) nicht besser geworden, eher im Gegenteil. Aktuell steigt das System sogar eher aus, alle 2 - 3 Tage teilweise. Bei mir ist die Anzahl der PHP Threads vor dem Ausfall immer am Maximum (10, Hardware PI3B+). Nach Neustart ist dies nicht der Fall. Es gibt aber keine hängenden Threads. In den Meldungen erscheinen keine Fehler.
Ich finde einfach keinen richtigen Zusammenhang bei den Abstürzen. Während meiner Dienstreisen in den letzten Wochen war definitiv keine Konsole geöffnet. Webfront nur selten (habe nirgendwo eine dauerhafte Anzeige). Und trotzdem kam es zu Abstürzen.
Ich werde - soweit die Zeit es erlaubt - meinen Raspi 4 am Wochenende neu aufsetzen mit Buster. Alle alten Zöpfe mal abschneiden, da meine aktuelle Version von Wheezy nach Stretch upgegradet wurde.
Ich werde dann mit bei 4GB RAM auf 40 PHP Threads hochgehen. Dann werde ich weiter beobachten, ob unter der neuen Hardware die Probleme auch wieder auftauchen. Es ist schon komisch. Solche Probleme wie aktuell hatte ich nur mal kurzzeitig - wenn ich mich recht entsinne - mit der 3.x. Außerdem habe ich nach langer Zeit eine USV, die auch die IT mit Strom versorgt, wenn mal der Strom ausfällt. Hatte ich in letzter Zeit ein paar Mal aus Versehen. (Handwerker im Haus, ich nicht zu Hause). Vielleicht kommen die Probleme ja auch aus dem Sektor.
Der Absturz fängt in der Regel immer damit an, dass bei mir die Verbindung zu einer LOGO verloren geht und nicht wieder aufgebaut wird. Danach dauert es dann bis zum Absturz nicht mehr lange. Gott sei Dank kommt Weihnachten, da kann ich dann mal wieder mehr testen.
Aktuell braucht das Symcon auch sehr lange beim Neustart. Es steht ca. 1 Minute an der Stelle mit der Zeitzonen Erkennung (das ist neu). Danach wird reaggregiert.
Mal schauen, ich werd mal berichten wie es weitergeht.
Hast du schon probiert, die Anzahl der Threads hochzustellen (z.B. auf 30)?
Je nach Umgebung ist 10 recht niedrig.
Hallo Martin,
Es steht ca. 1 Minute an der Stelle mit der Zeitzonen Erkennung
Ich habe bei mir einen Zeitserver eingetragen:
apt install ntpdate
crontab -e
@reboot ntpdate -s 0.de.pool.ntp.org
0 */6 * * * ntpdate -s 0.de.pool.ntp.org
Grüße, Gerhard
Hallo zusammen,
ich kann das Verhalten von @pitti und @mj04 so bestätigen, hier unter Ubuntu 18.04. Daher glaube ich nicht, dass es an der OS Version liegt. Das Speicherproblem tritt offensichtlich unter Windows, Raspi und Ubuntu auf.
Ein Muster kann ich auch nach Wochen des Probierens und Beobachtens nicht erkennen. Mal verhält sich das System ein- zwei Tage ruhig um dann in kürzester Zeit keinen Speicherplatz mehr zu haben, mal startet dieser Vorgang nahezu sofort nach Restart des IPS daemons.
Mein System hat 4GB Hauptspeicher, hält aber trotzdem nicht länger durch als der Raspi mit weniger.
Ich habe ein Bash Script geschrieben, welches den verfügbaren Hauptspeicher für den IPS Service überwacht und nach erreichen von max. 3,2GB wieder neu startet. Läuft alle 5 Min per cron. Zwar keine Lösung des Problems aber immerhin erfolgt ein Neustart noch bevor IPS Ausfallerscheinungen zeigt.
Viele Grüße
Georg
Gesendet von iPhone mit Tapatalk
Hallo,
komme gerade aus dem Keller. PI4 läuft provisorisch, komplett neu aufgesetzt mit owfs/symcon aktuelle Beta. Alles läuft wieder. DPD und co sei Dank ist heute alles gekommen. Bis auf die USV.
@GerhardBS ich nutze ntpdate nicht mehr. Uhrzeit wird upgedatet, Fallback NTP server sind auch parametriert.
timedatectl status liefert sauberen Status.
@bumaas ich bin beim PI3 auf 30 hoch, gefühlt war das Verhalten danach noch schlimmer. Die Neuinstallation auf dem PI4 läuft jetzt mit 40 Threads
@geolin das Reboot Skript hatte ich in der 3.x auch mal im Einsatz :rolleyes: Ansonsten bin ich da bei dir. Ich hab aktuell leider auch nicht genug Zeit, dass exakt zu beobachten.
Ich werde jetzt erstmal in Ruhe beobachten. Sonntag will ich die USV und meine Raspberrys mal sauber einbauen. Außerdem muss ich mich nochmal mit dem (nicht funktionierenden) USB Boot beim PI4 beschäftigen. Ich melde mich auf jeden Fall mit Zwischenständen.
Kleine Ergänzung:
Aktuell ist die Maximalanzahl der Threads bei 27 von 40. CPU Load beim PI3B lag bei rund 65% im Schnitt. PI4 aktuell bei 30%.
Da für das Thema so schnell keine Lösung in Sicht ist, wäre ich dankbar wenn mir jemand einen Link zu einer Anleitung für einen Watchdog auf Windows 10 Basis geben könnte.
Eine Anleitung für Raspberry hat Pitti erstellt, aber für Windows hab ich nichts gefunden als das „alte“ IPSWatchDog was seit 5 Jahren keinen Support mehr hat.
Gibt es eine kurze wirksame Variante wie von Pitti auch für Windows?
Oder habe ich in meiner Recherche was übersehen? [emoji3166]
Gesendet von iPhone mit Tapatalk
Hallo,
anbei mal der Speicherverlauf seit 17:00 Uhr (davor PI3B, ab 17:00 PI4B). Am Anfang ist der Speicher in den Keller gegangen, als ich die Variablen reaggregiert habe.Danach hat sich der Speicher „normalisiert“.
Seit 19:30 nimmt der freie Speicher bisher kontinuierlich um 20MB/h ab. Die maximale Anzahl PHP Threads bis jetzt 30. Immer zur vollen Minute gibt es da einen Peek. Dazwischen liegt der Wert bei ungefähr 10 Threads (±3 Threads). Konsole geöffnet, Webfront geöffnet. Jetzt teste ich mit geschlossener Konsole/Webfront.
Kurzes Update am Morgen:
Der freie Speicher hat kontinuierlich abgenommen. Um 4:51 hatte meine Fritzbox einen Neustart. Dadurch gab es eine kleine Störung und eine OneWire Anbindung über owfs war bis zum Reboot der Fritzbox gestört. Der Raspi ist provisorisch an der Fritzbox angeschlossen, bevor er hoffentlich an diesem Wochenende in den Serverschrank wandert an den richtigen Switch.
Jetzt habe ich gerade einen Neustart des Raspi gemacht, daher ist der freie Speicher wieder auf Startbedingung.
Bis 4:51 gab es keine Fehlermeldungim Log. Nach dem Reboot der Fritz auch keine Fehlermeldungen. Der freie Speicher scheint aber wieder genauso abzunehmen.
Gibt es zu den Abstürzen mittlerweile Erkenntnisse, wann das passiert und wie man es vermeiden kann?
Aktuell sieht es so aus, dass es durch den WebSocket Rückkanal passiert. Sofern dein IPS nach einem Neustart niemals die Konsole oder WebFront offen hatte, sollte es keinen Absturz geben.
Ich arbeite aktuell noch an einem Fix.
paresy
