Download-Produkt / Auswahl leer

[Ricks]

Hallo zusammen und ein gutes neues Jahr.

Wenn doch nur ein einziges Update mal problemlos verlaufen würde... :-(

Also, ich habe auf folgende Versionen aktualisiert:
Contao 4.8.7
Isotope 2.6.4

Wenn ich nun im Shop zu einem Produkt einen Download anlegen möchte, also einen Anhang definieren, und entsprechend auf "Auswahl ändern" klicke, dann erscheint ein leeres Fenster (siehe Anlage).

Außerdem ist das BE total langsam, was aber schon vorher regelmäßig der Fall war, nur nicht so extrem. Ich glaube, das System ist mit ein paar Tausend Dateien (jpg, mp4) schlichtweg überfordert.

Hat jemand eine Idee, warum die auszuwählenden Download-Dateien nicht mehr angezeigt werden?

Danke!

[Stefko]

Ahoi,

entferne in der Benutzerverwaltung mal das Häckchen bei "Vorschaubilder anzeigen" und lösche gleichzeitig auf der selben Seite die Caches bei "Daten bereinigen".
Geht es dann?

[Ricks]

Ahoi,

entferne in der Benutzerverwaltung mal das Häckchen bei "Vorschaubilder anzeigen" und lösche gleichzeitig auf der selben Seite die Caches bei "Daten bereinigen".
Geht es dann?

Danke für Deinen Tipp, aber das Häkchen habe ich schon vor geraumer Zeit entfernt, und Cache auch vorhin nochmals gelöscht. Die Seite hängt gerade bis zum Timeout.

Aber auch bevor sie hing, war das Datei-Auswahlfenster leer. Die Dateien befinden sich in Ordnern mit jeweils ca. 1500 Dateien. Ein Ordner mp4, ein Ordner jpg. Und wenn ich in der Dateiverwaltung die Verzeichnisse aufrufe, dann ist Ende, nichts geht mehr. Und zwar nicht nur kurz sondern dann für mind. 15 Minuten.

Doch abgesehen von der katastrophalen Performance ist das leere Auswahlfenster bei den Produkt-Downloads neu.

[Ricks]

Die Benutzung des BE legt die gesamte Website lahm. Auch der Aufruf der Produkte führt zum Timeout und völliger Überlastung. Ich vermute fast, dass nach dem Update die bestehenden Performance-Probleme verstärkt wurden und daher vielleicht auch das Auswahlfenster leer bleibt.

[Ricks]

Im Error Log stehen Dinge wir:

An exception occurred in driver: SQLSTATE[HY000] [1203] User dbxxxxxx already has more than 'max_user_connections' active connections at /Pfad/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:106, Doctrine\\DBAL\\Driver\\PDOException(code: 1203): SQLSTATE[HY000] [1203] User dbxxxxxx already has more than 'max_user_connections' active connections at /Pfad/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:31, PDOException(code: 1203): SQLSTATE[HY000] [1203] User dbxxxxxx already has more than 'max_user_connections' active connections at /Pfad/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:27)"} []

[Stefko]

Hast Du einen SSH-Zugang?
Dann führe auf der Kommandozeile doch mal ein

vendor/bin/contao-console contao:filesync

aus und lösche zuvor sämtliche Chaches nochmals.

[Ricks]

Hast Du einen SSH-Zugang?
Dann führe auf der Kommandozeile doch mal ein

vendor/bin/contao-console contao:filesync

aus und lösche zuvor sämtliche Chaches nochmals.

SSH Zugang habe ich jetzt nicht, bin ich auch leider nicht vertraut mit, aber ich hatte auch schon eine Dateisynchronisation durchgeführt.

[Stefko]

(...) aber ich hatte auch schon eine Dateisynchronisation durchgeführt.

und die funktionierte, brach also nicht ab oder blieb hängen?

[Ricks]

und die funktionierte, brach also nicht ab oder blieb hängen?

Doch, blieb sie ;-)

Zwischenzeitlich war die Performance mal wieder okay, und das Problem des leeren Auswahlfensters blieb. Die entsprechende Seite hängt dann auch nicht, sondern das Fenster öffnet zügig, aber ist leer. Es sieht nicht so aus, als ob er da lädt, es ist einfach leer. Das ist definitiv neu, nach dem Update. Wüsste auch nicht, was für Rechte da vielleicht eine Rolle spielen, zumal wir nichts geändert haben.

[Stefko]

Hmmm, das an irgendwelchen Rechten liegt, glaube ich weniger. Ich tippe/vermute das Problem eher an der Performance des Servers. Erzähle doch da mal was dazu, welcher Hoster, was für ein Paket? Und was für eine PHP-Version?

[Ricks]

Bin per SSH drin und hänge nun hier:

(12:24:58) [bin] contao-console contao:filesync
-bash: contao-console: command not found
(12:25:44) [bin]

Wie muss ich es eingeben? Danke sehr für Deine Hilfe!

[Ricks]

Erzähle doch da mal was dazu, welcher Hoster, was für ein Paket? Und was für eine PHP-Version?

Managed Server bei Domainfactory.

Intel Core i5
3,2 GHz oder größer
4 CPU-Kerne
16 GB Arbeitsspeicher

Die Website hat nicht viele Zugriffe zeitgleich, und für das Handling eines BE sollte das eigentlich reichen.

[Stefko]

Du musst in das Contao Root-Verzeichnis (also NICHT /web sondern eines darüber und dann

vendor/bin/contao-console contao:filesync

eingeben.
Je nach Konfiguration des Servers musst du noch ein

php

voranstellen.
Also auf einem Ionos-Server müsste ich

php7.3-cli vendor/bin/contao-console contao:filesync

eingeben

[Ricks]

Befehl bei DF ist: php7-73LATEST-CLI vendor/bin/contao-console contao:filesync

Nachdem er 30 Minuten synchronisiert hat, ist das Problem leider noch nicht behoben. Noch immer ist die Auswahl leer. Danke trotzdem für Deine Zeit und guten Tipps.

[Ricks]

Oh, ssh hat hat folgendes ausgeworfen:

Warning: require(/PFAD/var/cache/prod/ContainerVI8HDuD/removed-ids.php): failed to open stream: No such file or directory in /PFAD/var/cache/prod/ContainerVI8HDuD/appContao_ManagerBundle_HttpKernel_ContaoKernelPro dContainer.php on line 435

Fatal error: require(): Failed opening required '/PFAD/var/cache/prod/ContainerVI8HDuD/removed-ids.php' (include_path='.:/usr/local/lib/php') in /PFAD/var/cache/prod/ContainerVI8HDuD/appContao_ManagerBundle_HttpKernel_ContaoKernelPro dContainer.php on line 435

In appContao_ManagerBundle_HttpKernel_ContaoKernelPro dContainer.php line 435:

Compile Error: require(): Failed opening required '/PFAD/var/cache/prod/ContainerVI8HDuD/remo
ved-ids.php' (include_path='.:/usr/local/lib/php')


contao:filesync [-h|--help] [-q|--quiet] [-v|vv|vvv|--verbose] [-V|--version] [--ansi] [--no-ansi] [-n|--no-interaction] [-e|--env ENV] [--] <command>

[zonky]

ggf. mal

php7-73LATEST-CLI vendor/bin/contao-console contao:filesync -vvv 

aufrufen "-v" gibt mehr Infos aus - "je mehr Vaus, um so mehr Infos"

PS: ich hatte mal den Fall, dass ich eine "handvoll" Dateien als Videos mit über 2GB (je Datei) hatte - das hat die ganze Sync-Geschichte zum Absturz gebracht

[Ricks]

PS: ich hatte mal den Fall, dass ich eine "handvoll" Dateien als Videos mit über 2GB (je Datei) hatte - das hat die ganze Sync-Geschichte zum Absturz gebracht

Und was hast Du getan? Die Datein gelöscht oder gibts eine Lösung? Ich meine, das sollte ein CMS/Shop schon abkönnen, ein paar tausend files verwalten, oder eben einige große Dateien.

Ich setze gerade eine neue, saubere Installation auf, importiere alles und schaue, ob das Problem zu lösen ist oder System-immanent ist, was dann ein echtes Problem wäre.

Ich starte jetzt erst einmal keinen Sync-Prozess mehr, denn der legt jedes Mal den kompletten Server mit sämtlichen Websites lahm.

Danke nochmals für Deine Hilfe. Und sollte ich eine Lösung finden, werde ich es hier posten.

[zonky]

ist noch eine 3.5er Version...

spätestens ab 4.9 kann man Dateien (und/oder Ordner?) vom Sync ausschließen

[Stefko]

(...) eine "handvoll" Dateien als Videos mit über 2GB (je Datei) hatte - das hat die ganze Sync-Geschichte zum Absturz gebracht

Stimmt, da war was ... es gab in den letzten ein/zwei Wochen auch einen Thread hier im Forum, wo Dateien >2GB Probleme machten ... wenn ich mich nicht komplett irre, wurden die dann als Ordner in der Dateiverwaltung dargestellt.

[Ricks]

ist noch eine 3.5er Version...

spätestens ab 4.9 kann man Dateien (und/oder Ordner?) vom Sync ausschließen

Ah, okay. Aber das Problem ist leider nicht der sync sondern das Contao sich per se enorm verlangsamt, wenn in der Dateiverwaltung viele Files sind oder große. Das Problem mit den großen Dateien hatte ich übrigens auch schon.

So etwas kann ein ganzes Projekt zunichte machen, wenn das dann nicht lösbar ist. Im aktuellen Fall ein Shop. Man könnte die Dateien auf diverse Unterordner aufteilen, aber das würde bedeutet bei hunderten von Produkten die Download-Anhänge manuell neu zuzuordnen. Das kann man einem Kunden nicht wirklich plausibel machen ;-)

[zonky]

ich würde aber dennoch mal andere Server austesten - DF ist nicht gerade für einen "Geschwindigkeitsrausch" bekannt...

z.B. lokal, sofern Du Linux hast (unter Win/Mac brauchst Du nicht testen) - oder mal bei All-inkl...

[Ricks]

ich würde aber dennoch mal andere Server austesten - DF ist nicht gerade für einen "Geschwindigkeitsrausch" bekannt...

Ja, auch das werde ich mal prüfen, danke!

[Ricks]

So, Fazit: Saubere neue Installation bringt nichts. Sobald man im BE eine Seite/Funktion aufruft, die das Dateisystem nutzt ist Ende. Ob Download-Auswahl oder Dateiverwaltung, das System ist überfordert und danach für Minuten down. Ist von Version zu Version langsamer geworden, jetzt geht nichts mehr.

Eigentlich müsste dieser Thread in die Rubrik Bilder/Dateien.

[zonky]

So, Fazit: Saubere neue Installation bringt nichts. Sobald man im BE eine Seite/Funktion aufruft, die das Dateisystem nutzt ist Ende. Ob Download-Auswahl oder Dateiverwaltung, das System ist überfordert und danach für Minuten down. Ist von Version zu Version langsamer geworden, jetzt geht nichts mehr.

Eigentlich müsste dieser Thread in die Rubrik Bilder/Dateien.

selber Server oder wo getestet?

[Ricks]

selber Server oder wo getestet?

Ja, selber Server.

Ich teste noch einen anderen Server, was bleibt auch sonst Aber das kann doch nicht der richtige Weg sein. Das sollte ein CMS schon bewältigen können, das quasi alleine auf einem eigenen Server läuft. Da passiert wirklich nicht viel, wenig Zugriffe, nur eben die Dateien liegen dort. Und es hat sich definitiv nach dem Update vor ein paar Tagen erneut verschlechtert. Vorher ging es zumindest noch, wenn auch langsam. Aber jetzt ist Stillstand. Wie will man so etwas einem Kunden erklären? Aktuell ist der Shop nicht mehr administrierbar.

[folkfreund]

Ich hatte ein ähnliches Problem schon vor längerer Zeit mit einer 4.4 (mit vielen, aber nicht riesig großen Dateien, beobachtet bei uberspace und bei WebGo)
Das scheint an der Berechnung der Hashes für das DB-basierte Filesystem zu liegen. Diese Operation für alle Dateien braucht einfach ihre Zeit, die evtl. sogar die Skriptlaufzeit überschreitet.

Ich bin mir nicht sicher, aber ist es vielleicht möglich, dass du die Dateien auf mehrere Ordner verteilst und die Synchronisation einzeln je Ordner aufrufst?

[zonky]

du könntest im app_dev-Modus bei "Performance" nachsehen wer oder was so rumeiert - ggf. bringt das schon eine Idee... ansonsten müsste man mal mit blackfire.io oder sowas rein gucken

[MacKP]

Im Error Log stehen Dinge wir:

An exception occurred in driver: SQLSTATE[HY000] [1203] User dbxxxxxx already has more than 'max_user_connections' active connections at /Pfad/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:106, Doctrine\\DBAL\\Driver\\PDOException(code: 1203): SQLSTATE[HY000] [1203] User dbxxxxxx already has more than 'max_user_connections' active connections at /Pfad/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:31, PDOException(code: 1203): SQLSTATE[HY000] [1203] User dbxxxxxx already has more than 'max_user_connections' active connections at /Pfad/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:27)"} []

Hallo Ricks,
das Problem kenne ich von Mittwald (da warens nur 80 gleichzeitige Zugriffe, was bei einer gut besuchten Seite oft vorgekommen ist...). Dort musste ich auf ein anderes Paket umstellen (90,- Euro pro Monat), da dort das limit nicht gesetzt war von max_user_connections.
Bei df hatte ich das Problem noch nicht. Dort habe ich aber auch keine Kunden mehr, die größere Installationen haben.
Das Problem: Zu viele gleichzeitige Zugriffe auf die DB von Contao (sei es durch die Dateiverwaltung oder/und Besucher oder sonstige Operationen).
Du könntest dazu mal den Suppport von DF bemühen.. eventuell hat sich da auch nur etwas festgefahren, weswegen du jetzt immer wieder in dieses Problem rennst.
Ansonsten müstest du gucken, ob du das Limit eventuell hoch setzen kannst oder von denen hoch setzen lassen kannst.

Viele Grüße

[Ricks]

Du könntest dazu mal den Suppport von DF bemühen.. eventuell hat sich da auch nur etwas festgefahren, weswegen du jetzt immer wieder in dieses Problem rennst.
Ansonsten müstest du gucken, ob du das Limit eventuell hoch setzen kannst oder von denen hoch setzen lassen kannst.

Merci, das mache ich.

[Ricks]

Domainfactory hat die max_user_connections und die max_connections verdoppelt. Dadurch hängt der Server zwar nicht mehr so lange, aber das Grundproblem bleibt. Contao ist nicht in der Lage einen Ordner mit 1000+ Dateien zu öffnen. Die Dateiverwaltung hängt sich dann auf, und wenn man im Shop einem Produkt einen Download zuweisen möchte, so passiert das Gleiche, weil das System dazu ja auch die Ordnerstruktur laden muss.

Es ist eine neue, saubere Installation, und der filesync via SSH hat auch fehlerfrei funktioniert (allerdings in 1 Std. 20 Minuten)

Okay, nun bleibt nur noch ein leistungsstärkerer Server. Was okay ist, wenn es dann funktioniert. Aber das weiß man erst, wenn man ihn gebucht hat.

Danke nochmals an Euch alle für den diversen Input!

[zonky]

A) Contao ist nicht in der Lage einen Ordner mit 1000+ Dateien zu öffnen. Die Dateiverwaltung hängt sich dann auf, und wenn man im Shop einem Produkt einen Download zuweisen möchte, so passiert das Gleiche, weil das System dazu ja auch die Ordnerstruktur laden muss.

B) Okay, nun bleibt nur noch ein leistungsstärkerer Server. Was okay ist, wenn es dann funktioniert. Aber das weiß man erst, wenn man ihn gebucht hat.

zu A) bleibt die Frage, wer hier die "Schnecke" ist... ein PHP-Script oder der File-Zugriff direkt..?

zu B) bei vielen Providern gibt es einen "Testmonat"

[Ricks]

DF schreibt:

"Ursprung der gestrigen Festplattenauslastung war der Aufruf des Skriptes "PFAD/web/app.php". Dieses scheint Teil einer Contao-Installation zu sein und ruft laut Inhalt lediglich die "index.php" im gleichen Verzeichnis auf.

Leider ist hierbei nicht ersichtlich, ob dabei weitere Skripte/Prozesse angestoßen wurden. Aufgrund der Überlastung wurde jedoch in Abstimmung mit Ihnen der Prozess des Skriptaufrufes beendet, sodass die Festplattenauslastung und somit wieder die Serverlast gesunken ist."

**

Nach telefonischer Rückfrage hat DF nochmals erläutert, dass Auslöser des Stillstands eine Festplattenauslastung und keine CPU-Auslastung ist. Also Schreib- und Leseprozesse, was immer Contao da macht.

[zonky]

... k.A. - ggf. hat @toflar noch eine Idee

[Ricks]

zu B) bei vielen Providern gibt es einen "Testmonat"

Da es eine Festplattenauslastung ist, hilft mehr CPU leider nicht. Da müsste man dann ein System mit Loadbalancing buchen. Aber das sehe ich jetzt noch nicht. Im FE läuft alles rund, es passiert nur beim Administrieren im BE.

[zonky]

Da es eine Festplattenauslastung ist, hilft mehr CPU leider nicht. Da müsste man dann ein System mit Loadbalancing buchen. Aber das sehe ich jetzt noch nicht. Im FE läuft alles rund, es passiert nur beim Administrieren im BE.

hilft SSD? - wäre dennoch die Frage, wer da "ständig" im BE auf die Dateien zugreift

[Ricks]

hilft SSD? - wäre dennoch die Frage, wer da "ständig" im BE auf die Dateien zugreift

DF meint, sie haben keine Festplatten, die da helfen würden. "Ständig" ist der Zugriff ja nicht, nur bei Aufruf der Dateistruktur. Ansonsten läuft das BE rund.

[zonky]

"Ständig" ist der Zugriff ja nicht, nur bei Aufruf der Dateistruktur. Ansonsten läuft das BE rund.

vielleicht kann man das ja irgendwie cachen - ich würde dazu mal ein Issue auf Github schreiben...

[Ricks]

Das von DF ins Spiel gebrachte Loadbalancing bringt natürlich auch nichts, hatte nicht nachgedacht. Dabei würde nur die CPU-Last verteilt, oder beim Ausliefern von Daten auch von verschiedenen, gespiegelten Festplatten bereitgestellt. Aber dieses Schreiben und Lesen, das Contao beim Abruf der Dateistruktur veranstaltet, muss natürlich auf einer Platte erfolgen.

[zonky]

ja, das LB soll ja nur viele Anfragen (FE) auf verschiedene Server verteilen - hat m.E. mit dem Problem nix zu tun

ich denke, ein Caching könnte das Problem umschiffen

[folkfreund]

Ich hake nochmal wegen der Synchronisation der Dateiverwaltung ein, die ja in dem betroffenen System noch nicht abgeschlossen ist.
Kann es sein, dass darum schon beim Öffnen der Dateiverwaltung im BE irgendwas passiert, das z.B. die Hashes nachrechnet oder überprüft? Oder bin ich da völlig auf dem Holzweg?

Weitere Frage: wie sind denn die 1000+ Dateien auf den Server gekommen, alle gleichzeitig oder nacheinander? Könnte es helfen, zunächst mit nur, sagen wir, 100 Dateien zu synchronisieren und dann jeweils weitere Files zu ergänzen und neu zu synchronisieren?