EE stürzt kontinuierlich ab

[uwe111]

Aber Du läufst doch auf einem Raspi? Gab es da nicht Probleme mit cuxd-Timern?

Nein, gibt's nicht. Nur nach dem letzten YAHM-Update gab es generelle Verarbeitungsprobleme.
Ab der CUxD-Testversion 1.8b (Download hier: http://cuxd.de/download/) sollten die aber behoben sein.

Sind denn die cronjobs im gewöhnlichen CCU-Backup enthalten ?

Ich denke nicht. Auch von jedem CCU FW-Update werden sie überschrieben.

Viele Grüße

Uwe

[Familienvater]

Moin,

Sind denn die cronjobs im gewöhnlichen CCU-Backup enthalten ?

Ich denke nicht. Auch von jedem CCU FW-Update werden sie überschrieben.

also bei der CCU2 wird /usr/local/crontabs/root mit im Backup gesichert (bei der CCU1 war die glaube ich im ro-Bereich), ob die beim Firmwareupdate überschrieben wird, bin ich mir nicht sicher, die ist zumindest nicht in meinem Script enthalten, was meine "customstyle"-Dinge vor einem Firmwareupdate sichert.

Der Familienvater

[uwe111]

Ok, dann wurde das irgendwann geändert.
Mit dem FW-Update das müsste man dann auch nochmal testen.

Viele Grüße

Uwe

[Pietro]

ok, danke !

[Pietro]

Mittlerweile habe ich bzgl. Speicherverbrauch auch visuwin im Verdacht - dieses läuft bei mir grundsätzlich 7x24 auf einem Touchpanel in der Wand - gestern um ca. 00:42 hab ich visuwin neu gestartet und siehe da:

Ganz spannende Beobachtung:
Gestern um ca. 08:00h bleib bei mir das erste mal ein CCU-Timer "hängen" - konkret der Timer der für das Auslesen von DutyCycle und freiem Speicher zuständig ist.
Dies wäre an sich - laut Forum - ja noch nichts ungewöhnliches - habe nun mittlerweile auf einen CuxD-Timer umgestellt.

Das Spannende aber ist, dass nach dem Reaktiveren des CCU-Timers (de- und wieder aktivieren) - oder möglicherweise auch knapp vor dem Abschmieren des Timers der Speicherverbrauch stetig nach unten geht und die CCU-Last deutlich höher als vor dem Hänger ist.
Und das obwohl ich nichts, aber auch wirklich nichts geändert habe (es gab auch keinen Exec-Restart).

Der Dateianhang Capture.PNG existiert nicht mehr.

Any Ideas ?

[Familienvater]

Hi,

ich weiß nicht genau, was Du in deinem Graph genau aufzeichnest, aber es ist "normal", das eine Unix-System nur sehr wenig freien Speicher hat, weil sich der cached "alles" schnappt, was kein anderer braucht. Er gibt es aber auch wieder her, wenn den Speicher ein anderer Prozess braucht.

Du musst konkret die Größe der EE überwachen, um Aussagen über das Wachstum der EE zu treffen, der Umkehrschluss, kein freier Speicher mehr, muss also alles die EE gefressen haben gilt nicht.
Das System selbst braucht je nach IO-Zugriffen auf das Dateisystem ein paar Stunden bis ein paar Tage, bis der freie Speicher "leer" ist, aber dann ist normalerweise der cached dick und rund gefressen.

Der Familienvater

[Familienvater]

Hi,

es gibt "offizielle" Updates, zumindest HPCL-Editor, VisuWin, Modultabellen, und vielleicht ist auch schon eine neue Version der EE für die CCU im Download-Ü-Ei versteckt.

Ich habe es aber nur gesehen, noch nichts runtergeladen, oder installiert oder ausprobiert, ich weiß auch nicht, was alles neu/gefixt ist...

Der Familienvater

[Bulli]

Moin,

Sind denn die cronjobs im gewöhnlichen CCU-Backup enthalten ?

also bei der CCU2 wird /usr/local/crontabs/root mit im Backup gesichert (bei der CCU1 war die glaube ich im ro-Bereich), ob die beim Firmwareupdate überschrieben wird, bin ich mir nicht sicher, die ist zumindest nicht in meinem Script enthalten, was meine "customstyle"-Dinge vor einem Firmwareupdate sichert.
Der Familienvater

Hallo
die cronjobs sind auch nach einen Firmware Update noch da. Ich benutze schon immer cronjobs und hab schon 5-10 Firmwareupdate gemacht also kein Problem. Außerdem liegen sie in /usr/local die werden auch mit jeder Sicherung schön mitgesichert. crontabs ist nur ein link nach /user/local/crontabs.

Code: Alles auswählen

# pwd
/var/spool/cron
# ll
total 0
    227      0 drwxrwxr-x    2 root     root            60 Dec  6 07:37 .
    220      0 drwxrwxr-x    3 root     root            60 Dec  2 09:26 ..
    228      0 lrwxrwxrwx    1 root     root            19 Dec  2 09:26 crontabs -> /usr/local/crontabs
# cd /usr/local/crontabs
# ll
total 4
     65      0 drwxrwxr-x    2 root     root           224 Dec  6 07:37 .
      1      0 drwxr-xr-x    4 default  default        488 Dec  5 18:58 ..
    400      4 -rw-------    1 root     root           264 Dec  6 07:37 root

auch strange...
Bzgl. CUXD: Ansich läuft der bis dato unter Rasperrymatic problemlos bei mir - however, mit crontab fühl ich mich wohler und dann kann ich gleich ganz auf cuxd verzichten - fein, wieder ein plugin weniger.
lg Pietro

Ja und Nein.
Der CUxD kann dein System (Rega) auch Entlasten vorallem wenn du auch noch einen Raspi hast. Zwei Prozess die was tun können sind besser als einer Stichpunkt serial parallel usw....
Bei großen Internetauftritten macht man das z.B auch so. Hier läuft auf einen Server z.B ein Apache Webserver und nicht nur ein Tomcat sondern 2-x Tomcatinstanzen je nach Serverausstattung an RAM und CPU. Weil eine Tomcatinstanz halt nur 200-1000 User Performant händeln kann. Und so ist es hier auch nur in kleinen Rahmen. Thema Ausfallsicherheit LB und 2-x Server lassen wir hier mal aussen vor.



Gruß Bulli

[Familienvater]

Hi,

meine EE (immer noch 3.04) hat Seegang

graph_image.php.png (20.22 KiB) 1087 mal betrachtet

Nach dem letzten Start gestern mittag ist die Größe leicht gestiegen, aber dann wieder ein bisschen kleiner geworden...
Es hat definitiv mit dem entfernen jeglicher FHZ2000-bezogenen Objekte aus dem Projekt zu tun, inkl. der FHZ2000 aus dem Netzwerk, das war aber eigentlich auch ab dem 18. schon so gewesen. Wie es halt mit "neuen" Projekten so ist, braucht man mehrere Versuche, bis alles so tut (wobei es nur Test-Kleinigkeiten waren), und trotzdem "wild"wuchsen die Projekte vorher...

Aber 24h sind ja noch keine Laufzeit für ein Projekt, bin mal gespannt, wie "artig" sich die EE weiter verhält (oder wann EE 3.05 raus/drauf kommt).

Der Familienvater

[Pietro]

ich zeichne memfree auf.

Grundsätzlich ist mir schon klar, dass die reine Beobachtung von MemFree auf einem Linuxsystem nur bedingte Aussagekraft hat, allerdings finde ich es doch verwunderlich, dass zuerst ein paar Tage der freie Speicher nur sehr langsam weniger wird, dann plötzlich der Verbrauchskurve deutlich steiler wird und nach einem Restart von VisuWin (nicht EE!) die Verbrauchskurve wieder wesentlich flacher ist (es wurde hier aber KEIN Speicher freigegeben).

lg Pietro

Hi,

ich weiß nicht genau, was Du in deinem Graph genau aufzeichnest, aber es ist "normal", das eine Unix-System nur sehr wenig freien Speicher hat, weil sich der cached "alles" schnappt, was kein anderer braucht. Er gibt es aber auch wieder her, wenn den Speicher ein anderer Prozess braucht.

Du musst konkret die Größe der EE überwachen, um Aussagen über das Wachstum der EE zu treffen, der Umkehrschluss, kein freier Speicher mehr, muss also alles die EE gefressen haben gilt nicht.
Das System selbst braucht je nach IO-Zugriffen auf das Dateisystem ein paar Stunden bis ein paar Tage, bis der freie Speicher "leer" ist, aber dann ist normalerweise der cached dick und rund gefressen.

Der Familienvater