Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hohe Anzahl an Dateien, sprengen PHP Speicherlimit #102

Closed
stefanheimes opened this issue Aug 9, 2012 · 13 comments
Closed

Hohe Anzahl an Dateien, sprengen PHP Speicherlimit #102

stefanheimes opened this issue Aug 9, 2012 · 13 comments

Comments

@stefanheimes
Copy link
Member

Wenn eine Contao Installation mehrere Dateien hat, wir reden hiebei um 500 und mehr Dateien, brauchen beide Systeme (Server & Client) extrem viel Speicher um die Vergleichslisten aufzubauen.

Das beste wäre wenn wir weg von Array's hin zu XML und Container Dateien (in Java POJO's) gehen.

Zwar geht dann anstelle der Speicherauslastung die Laufzeit hoch aber dies ist immer noch besser als
200MB und mehr Auslastung zu haben.

@andreasisaak
Copy link
Contributor

Es muss nur sichergestellt werden das die Auslastung parallel zur Anzahl der Dateien höher wird. Nicht das jemand mit 100 Dateien genauso lang warten muss wie jemand mit 800 Dateien.

@MacKP
Copy link

MacKP commented Oct 30, 2012

OK, das ganze passiert auch bei Vergleichstabellen (tl_content). Da brauche ich gerade für ein paar Content Elemente (Änderungen in der Tabelle 14869) knapp 310 MB.

Wäre also wirklich wichtig!

Viele Grüße

@stefanheimes
Copy link
Member Author

Das musst du bitte einmal genauer erklären, die Datenbank sollte ohne großen Speicher Verbrauch über die Bühne gehen. Es sollte nur die Laufzeit hoch gehen.

@MacKP
Copy link

MacKP commented Oct 30, 2012

Nachdem ich die Tabellen ausgewählt habe (nur noch tl_content) arbeitet der noch ein wenig an Punkt -> Abgleich der Datenbank
Dann wird mit der Fehlermeldung abgebrochen:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 188910606 bytes) in /var/www/vhosts/***/staging_wolfin/system/modules/syncCto/SyncCtoDatabase.php on line 556

*** ist dabei der Systemordner ;-)

Viele Grüße

@stefanheimes
Copy link
Member Author

Okay, das ne Aussage damit kann ich was anfangen, dankö.

@andreasisaak
Copy link
Contributor

Lösung?

@stefanheimes
Copy link
Member Author

Auslesen wie viel Speicher noch zur Verfügung steht. Davon 1/3 für die Daten benutzten. Wenn diese 1/3 erreicht wurden alle Daten schreiben.

Dann schiebe ich das Problem vom Speicher weg, hin zu der Ausführungszeit. Wird also wieder länger laufen.

@stefanheimes
Copy link
Member Author

Datei Listen als XML Speichern.
Mit XMLWriter->openURI direkt in Dateien schreiben, mit SAX (XMLReader) Stück für Stück einlesen und prüfen.

Plan:
Container zum schreiben, lesen erstellen
Funktionen auf XML/Container umbauen

Plan 2:
CSV Dateien :)

@HellPat
Copy link

HellPat commented Jun 3, 2013

Habt ihr einen Anhaltspunkt was ich für die tl_content als max_execution_time bzw memory_limit benötige wenn ich 200MB Daten in der Tabelle habe?

@HellPat
Copy link

HellPat commented Sep 26, 2013

Gibt es hier schon einen Fortschritt? Mir bleibt momentan nichts anderes übrig als die tl_content Tabelle manuell zu übertragen... Das Limit des Webhostings ist leider bereits ausgereizt.

@andreasisaak
Copy link
Contributor

Bisher leider noch nix vorzeigbares. Kannst du uns vielleicht ein Dump der DB senden, dann würden wir es damit testen.

@HellPat
Copy link

HellPat commented Sep 26, 2013

Habe ich dir per E-Mail geschickt.

@andreasisaak
Copy link
Contributor

Die Vergleichslisten werden wir mit Contao 2.11 nicht mehr performanter hinbekommen. Meine Hoffnung liegt auf Contao 3, da dort die tl_files Daten eh schon in der DB liegen. Dann geht der Vergleich der Dateien schneller. Insofern können wir hier einfach nichts mehr reißen

@psren Dein Fehler ist noch ein anderer. Schreib dafür bitte ein neues Ticket.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants