tl_content mit vielen Einträgen sprengt Speicherlimit

[HellPat]

releated to #102

Ich kann alles synchronisieren solange ich die Tabelle tl_content ausnehmen.

@andreasisaak Habt ihr eine Idee?

[stefanheimes]

Moin,

ich hab da einen verdacht. Ich werde es die Tage einmal überprüfen und ein Update für die Dev Version erstellen.

[HellPat]

Dankeschön. Magst du den Verdacht trotzdem noch mitteilen? Melde dich einfach wenn du jemand zum testen brauchst.

[stefanheimes]

Ah sorry.

Also die Funktionen für den DB Export zeiht sich immer maximal 500 Datensätze aus der DB. Nun kann es aber sein das 500 Datensätze schon zu viel sind. Daher werde ich das Limit, wie viele Datensätze auf einmal bearbeitet werden, konfigurierbar machen. Somit kann dann jeder selbst das Limit einstellen.

Zwar wir dann die Laufzeit vom Script länger aber das kann ich dann auch nicht mehr ändern, dann muss jeder ein bissel rum Spielen bis die Optimale Einstellung gefunden wurde.

[HellPat]

Ich teste das entweder heute Nachmittag oder morgen Vormittag.
Das mit dem herumspielen finde ich nicht schlimm.

👍

[stefanheimes]

So, du kannst gerne die Dev Version einmal testen.
Die neue Einstellung ist hier zu finden:

• Unter Synchronisation => Konfiguration, links im Menü
• Unten auf der Seite "Experten-Einstellungen aktivieren" anklicken.
• Im neuen Feld "Datenbank Abfragelimit" eine kleiner Zahl eingeben.

Wie gesagt, müsstest du hier bissel testen 250 oder 100. Das sollte den Speicher schonen. Allerdings wird dann die Ausführungszeit nach oben gehen.

Generell ist zu sagen, wenn mehr Speicher zu Verfügung steht sollte der Wert nach oben gestellt werden. Ist wenig Speicher verfügbar sollte der Wert nach unten korrigiert werden. Allerdings müsste dann die max_execution_time nach oben hin angepasst werde. Diese Problem ist halt Bestandteil von Script Sprachen.

Beispiel:
tl_content => 10.000 Einträge
tl_article => 1.500 Einträge
tl_page => 1.000 Einträge

Datenbank Abfragelimit: 5.000.000

• Speicher verbrauch: 600MB
• Zeit: 80 Sekunden

Datenbank Abfragelimit: 1

• Speicher verbrauch: 23MB
• Zeit: 600 Sekunden

[andreasisaak]

Gibts da Erkenntnisse? Ich würde das Ticket gerne abschließen und eine neue Version im ER veröffentlichen.

[HellPat]

Bin im Moment dran

[HellPat]

Mhh bisher kein Erfolg. Ich muss wohl noch ein bisschen mit den Einstellungen rumspielen.

[HellPat]

Okay... muss euch leider enttäuschen. Mein Test dauert noch ein Weilchen. Ich glaube ich habe ausversehen mit zu vielen Anfragen die Firewall nervös gemacht. Host mal anbetteln dass er den Server in die Whitelist packt...

[stefanheimes]

Dann kannst ja noch frage ob er die Laufzeit vom PHP hoch setzte kann. Dann hast da vielleicht mehr Luft.

[stefanheimes]

@psren Neue Erkenntnisse ?

[HellPat]

Ich bekomme ein "gateway error 504". Hab nun beim Host ne längere Laufzeit angefordert.

[andreasisaak]

Ich verstehe das du dringend eine Lösung brauchst, ich würde nur gerne trotzdem wissen wie wir das Problem langfristig lösen können.

[HellPat]

Mhh. Wie kann ich euch helfen?

[HellPat]

Also mit 22 bei Abfragelimit bekomme ich einen 504
Mit 23 als Abfragelimit bekomme ich

Fatal error: Allowed memory size of 209715200 bytes exhausted (tried to allocate 421560482 bytes) in /cms-staging/system/modules/syncCto/SyncCtoDatabase.php on line 545

Das kommt mir aber allgemein irgendwie wenig vor. Nur hier ist die Grenze zwischen den zwei verschiedenen Fehlermeldungen.

[andreasisaak]

Na ja wenig ist das nicht. Sind ja immerhin 200 MB an Speicher.

[andreasisaak]

Können wir denn irgendwie Zugriff zum System bekommen?

[HellPat]

Das wenig war eher auf die 22/23 Abfragelimit bezogen.
Klar. Was braucht ihr alles?

[stefanheimes]

Moin,

ich werde gleich ein neuen Commit hochschieben. Es gab noch ein Problem mit dem XML Writer.

Dieser gibt seinen Speicherverbrauch nicht aus mit memory_get_usages. Dadurch konnte ich den Speicher nicht richtig berechnen und hatte am Schluss dann eine 400MB große XML Datei, die ich auf einmal versucht habe zu speichern.

Ich hab es nun ein bissel umgeschrieben und leere den Speicher öfters ohne dabei den Speicher auf den Verbrauch zu prüfen. Dadurch wird die Laufzeit zwar etwas länger, allerdings kann ich nun 1500 Abfragen auf einmal verarbeiten mir ~140MB Speicherauslastung. Bei 3000 Abfragen komm ich dann auf ~200MB.
Ich hab es dabei mit einer DB geprüft die 40500 Einträge in der tl_content hat. Das Problem hierbei ist aber nun das ich eine Laufzeit von ca. ~170 Sekunden habe.

Wenn du testet benutzt ruhig 1000 - 1500 Abfragen am Anfang. Der Speicher sollte das nun besser verkraften.
Bei 23 Abfragen rennt dir das System Stunden, wenn es nicht in eine Exception rennt.

[HellPat]

Schau ich gleich an.

[HellPat]

Okay. Eine gute und eine schlechte Nachricht.

Gut: Der Fehler wie er bisher war ist weg.
Schlecht:

Schritt 2 sagt jetzt das hier:

Abgleich der Datenbank.

Could not find start or endtag from response.

tl_files/syncCto_backups ist nicht vorhanden, obwohl debug-Modus aktiviert ist.
Was kann das nun bedeuten? Falls es für euch geschickter ist: Login habe ich an Andreas geschickt.

[andreasisaak]

Schauen wir uns morgen mal auf deinem System an.

[HellPat]

Und habt ihr hier irgendwelche neuen Erkenntnisse?

[andreasisaak]

Bisher hatten wir noch keine Zeit da reinzuschauen.

[HellPat]

Kein Problem. Falls ihr noch was benötigt sagt Bescheid :-)