Fragen und Probleme mit Edomi unter CentOS 7

[saegefisch]

Noch mal jungfräulich installiert auf einem anderen NUC:

• CentOS-7-x86_64-Minimal-1810.iso --> wollte sich auf diesem NUC nicht unmittelbar installieren lassen (GUI für Installation wurde nicht erreicht)
• CentOS-7-x86_64-Minimal-1908.iso --> lies sich wunderbar installieren --> edomi 2.00 ebenfalls
  • Neues Projekt erstellt: Fehlerfrei, kein Umlaut-Problem --> alles prima, alles flüssig
  • Backup eingespielt (das ursprünglich auf LXD angelegt wurde): Wieder massive Umlaute-Fehler, alles zäh
    • Im Projekt aus dem Backup VSE neu eingelesen und neues UE angelegt (egal, ob auf bestehender Seite oder neuen Seite): weiterhin Umlaut-Fehler

Fazit: Das Backup ist "infiziert"

Lösungsversuche:

• Browser: Projekt komplett löschen --> neues Projekt: Umlaut-Fehler bleibt
• Browser: Alles löschen "Werkseinstellungen" --> neues Projekt: Umlaut-Fehler bleibt
• Shell: sh install.sh mit Option "e" edomi neu installieren --> neues Projekt: OK
• Browser: Backup wieder einspielen: Umlaut-Fehler wieder da

Analyse: Das Problem steckt offenbar in Dateien, die nicht bei der Werkseinstellung zurück gespielt werden, wohl aber bei Option "e" bei der edomi-Neuinstallation. Wie ermittelt man das Delta der beiden Verfahren und dessen Schnittmenge mit dem, was ins Backup kommt? Darin muss die Antwort stecken.

gaert : Ist das aus Deiner Sicht Einzelschicksal oder soll ich Dir (oder will jemand anderes forschen?) mal das Backup (286MB) zukommen lassen für eigene Tests? Vielleicht würde die - vermutlich kleine - Ursache/Lösung die Installation robuster machen.

Da in das Projekt schon recht viel Zeit geflossen ist (technisch ging es ja, das Live-Projekt ist da problemlos und ich war zuversichtlich, dass es hier schon eine Lösung geben wird) und läuft leider bereits produktiv bei einem Freund im Rheinland: Das muss man doch wieder weg bekommen... nur wie...wie des-infiziert man das Projekt...?

[hartmut]

siehe #159

[Janncsi]

Ich weiß nicht, ob es eine Lösung ist, trotzdem möchte ich es beschreiben.

Meine vorherige Installation basierte in einem LXC-Container unter proxmox mit dem dort hinterlegten CentOS7-Container. Dies verursachte die bekannten Umlaut-Probleme.

Ich habe gerade das Image von gaert runtergeladen und als virtuelle Maschine im proxmox installiert. Ergebnis: Keine Probleme bei den Umlauten und keine unerwarteten Freeze's

[WagoKlemme]

Vielleicht ist ein Systemupdate die Ursache, da meine Installation schon ein paar Monate her ist und ich seit August nicht mehr upgedated habe. Die benutzte CentOS-7-x86_64-Minimal-1810.iso habe ich noch.

[saegefisch]

Danke für Dein Angebot. Wenn ich/jemand nur wüsste, wonach man suchen müsste... ich bin am Ende meines Lateins. Ursächlich ist vermutlich eine Kleinigkeit bei Zeichensätzen, die wohlmöglich zu einer schleichenden Strangulation (durch jede Aktivierung?) führt.

[WagoKlemme]

Ich habe hier Edomi 2.0 auf CentOS 7 seit August auf einem Terra Micro 5000P/i3-5010U laufen. Kein Umlauteproblem, und CentOS7 läuft bei mir definitiv flüssiger als CentOS6, bei gleicher Hardware.
Wenn ich was testen soll, bitte melden.

[root@edomi ~]# grep -ri charset /etc/httpd/
/etc/httpd/conf/httpd.conf:# Specify a default charset for all content served; this enables
/etc/httpd/conf/httpd.conf:AddDefaultCharset UTF-8
/etc/httpd/conf.modules.d/00-base.conf:#LoadModule charset_lite_module modules/mod_charset_lite.so

[Janncsi]

Ich hab mein Backup eingespielt und die Projektdatei reingeladen, jetzt läuft es wieder.

Was seltsam war: alle Backups hatten um die 50MB, bis auf das gestrige, das hatte 160MB und dieses war auch das fehlerhafte ...

EDIT: Da ich gerade nach und nach die Logikseiten in der neuen Installation freischalten und die in der alten Installation deaktivieren. Nach der 6. Projektaktivierung hängt das Ding wieder bei 2%....Ich warte wohl lieber 2 Monate bis ich auf CentOS7 weitermache....

[saegefisch]

Auf exakt gleicher HW (beide NUC I3 gleiches Baujahr/Reihe/Ausstattung):

• Produkivsystem CentOS 6.5 + edomi 1.64:
  • Öffnen von Logikseiten: sofort/unmittelbar
  • VisuSeiten: <1s
  • Universalelement bearbeiten: sofort/unmittelbar
  • Aktiviertes Projekt: flüssig
• Zweitsystem CentOS 7 + edomi 2.00 (beides von edomi-Seite) mit deutlich weniger Umfang (LBS, keine Diagramme, keine Archive,...)
  • Umlaute-Problem
  • Öffnen von Logikseiten: 2-3s
  • VisuSeiten: 2-5s
  • jedes Universal-VSE bearbeiten: 2-6s bis PopUp erscheint (mit den offenbar wachsenden Umlauten)
  • Aktiviertes Projekt: flüssig

Fazit:
- Mein aktuelles edomi 1.64 fühlt sich wie eine lokal installierte Applikation an. Es macht viel Spaß, damit unmittelbar zu arbeiten
- Das Testsystem edomi 2.00 mit dem Umlautefehler fühlt sich zäher bis zäh an. Das Öffnen der VSE ist grauselig lansgam und bremst die Arbeit spürbar. Da es die gleiche HW ist und ich davon ausgehe, dass Christian mit edomi 2.00 auf CentOS 7 keinen Bremsklotz entwickelt hat, nehme ich an (aber ohne es zu wissen/prüfen zu können), dass die - offenbar wachsende Anzahl - Umlaute-Ersatzzeichen das System tatsächlich belasten/stören. Ich mag nicht so recht glauben, dass diese Zähigkeit grundsätzlich am BS oder edomi liegt.

[Janncsi]

2% von was?

Es scheint doch nicht klar zu sein, was das Umlautproblem überhaupt ist, daher kann man auch schlecht sagen, ob das die Ursache sein kann.

Was sagt ´top´?

2% der Projektaktivierung, siehe Bild
projektaktivierung.PNG
'top' wirft mysql als größten Verbraucher aus mit 10% des Arbeitsspeichers. Ich denke nicht unbedingt, dass die Gesamtspeicherauslastung das Problem ist, sondern das der maximal erlaubte RAM genutzt wird und das ist im php direkt definiert?!
memory.png

[jonofe]

2% von was?

Es scheint doch nicht klar zu sein, was das Umlautproblem überhaupt ist, daher kann man auch schlecht sagen, ob das die Ursache sein kann.

Was sagt ´top´?

[Janncsi]

Passiert erst bei Projektaktivierung und dann schon bei 2%....

Ich habe keine LBS zugefügt nur sehr schnell nach einer Projektaktivierung nochmal eine erneute Projektaktivierung initiiert?!

Kann durch das Umlaut-Problem evtl eine solche Speicherauslastung geschehen?!

[jonofe]

Ich würde eher versuchen herauszufinden, wieso denn so viel Speicher allokiert wird. Z.B. mit ´top´ und M drücken um nach Speicher zu sortieren. Was hast du geändert bevor du den Fehler bekommen hast? Wie lange dauert es bis der Fehler nach einem Reboot auftaucht?

[Janncsi]

Ich kann seit gerade kein Projekt mehr aktivieren. Im Fehlerlog taucht folgende Meldung auf:

 [TABLE="border: 0, cellpadding: 0, cellspacing: 0"]
 	 		[TR]
 			[TD]Datei: /usr/local/edomi/www/admin/include/php/base.php | Fehlercode: 1 | Zeile: 26 | Allowed memory size of 134217728 bytes exhausted (tried to allocate 61934774 bytes)[/TD]
 			[TD]FATALERROR[/TD]
 		[/TR]
 	 [/TABLE]

Wenn man danach sucht, dann gibt es den Tipp, dass man in der php.ini das memory_limit ändert

Kann mir jemand von euch sagen, wo ich die php.ini finde? Oder befinde ich mich mit der Lösung auf dem Holzweg?

[saegefisch]

Angemerkt sei: Es trifft nicht nur VSE und LBS, sondern auch die Hilfe (siehe mein Screenshot). Selber eingebrachte Umlaute (z.B. Beschriftungen in der Visu) sind offenbar nicht betroffen, sondern eher statisch Texte von LBS, VSE und Hilfe.
Damit scheint mir die bereits geäußerte Schlussfolgerung logisch, dass es weniger mit der DB zu tun hat und vermutlich eher mit dem WebServer. Andererseits wäre dann die Verlängerung unerklärlich - wenngleich die (für mich) bisher erst ein Gefühl ist, was nicht gesichert ist. Wenn es mit der Aktivierng zu tun hätte: Warum sollte die Einfluss auf das Arbeitsprojekt haben?

gaert Da es offenbar kein Einzefall ist und statische Texte betrifft: Christian, hast Du vielleicht eine Idee dazu?

Nachtrag: Auch in der Bezeichnung der LBS...
edomi_umlaut2.PNG

gaert : Hallo Christan, darf ich das nochmal nach vorne bringen? Hast Du eine Idee, woran das liegen könnte? Danke für Deine Einschätzung.

[vento66]

Am besten irgendeinen Hochleistungsrechner mit mind. drölftausend GB RAM und von der Leistung her etwas unter Quantenqomputer jetzt mal im ernst, es bringt ja nichts mit dem Mist auf ne stärkere Maschine umzuziehen. Am besten erst mal die Ursache für die Auslastung suchen. Mein APU läuft bei ca 20% mit Peaks bis zu 70%.
Da läuft aber noch

- Homebridge
- FFServer (der braucht die meisten Resourcen)
- node red
- EIBD

zusätzlich zum EDOMI