beim löschen von abonnenten out of memory problem

hallo,

ich habe einen newsletter mit einer gruppe von ~6500 abonnenten. wenn ich die gruppe in der avisota abonnentenverwaltung löschen möchte bekomme ich auf dem strato-webspace der seite:

Code:

---

Fatal error: Out of memory (allocated 24641536) (tried to allocate 47 bytes) in /mnt/webg/d1/22/6546/htdocs/system/libraries/Database.php on line 151

---

auf meinen eigenen all-inkl webspace den ich zum gegentesten nutzte:

Code:

---

ALL-INKL:
Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 80 bytes) in /www/htdocs/domain/system/drivers/DB_Mysql.php on line 342

---

da ich den fehler bei beiden anbietern habe, vermute ich ein problem bei avisota. beide webspace pakete befinden sich in mittlerer preislage, für den betrieb von contao langten die spezifikationen bisher (lt. contao-check und erfahrungen beim betrieb)

freue mich sehr über hinweise ;)
ich weiß nicht ob ich da überhaupt was gegen unternehmen kann, z.b. durch eine anfrage ob man den memory erhöhen könnte, oder ob avisota ein generelles problem hat.

Das ist in dem Fall wohl eher ein Contao Problem.
Versuch mal die Abonnenten vorher zu löschen (also in 500er Blöcken, das ist das Maximum was Contao bei "Alle anzeigen" anzeigt).
Das sollte funktionieren.

Du hast mehrere Möglichkeiten das zu testen bzw. nach zu vollziehen!

Zum einen gibt es eine Erweiterung für Contao (phpinfo), die Dir Informationen alla phpinfo.php zur Verfügung stellt ohne sie von Außen erreichbar zu machen.
Dort wirst Du einen Eintrag memory_limit finden.

Andere Möglichkeit, Du kannst Dir eine phpinfo auf den Server laden und aufrufen (löschen nicht vergessen :) )

Zu guter Letzt zeigt Dir auch der Contao-Check das memory_limit.

Lösungswege, die bei All-Inclusive funktionieren sollten:

1. .htaccess Eintrag: php_value memory_limit 32M (mit dem Wert etwas rumspielen, einige Anbieter lassen das zu, oft nur bis zu einem Maximalwert)
2. mit PHP: ini_set('memory_limit', '32M');
3. php.ini: memory_limit = 16M; (natürlich nur, wenn Du da Zugriff drauf hast)
4. Supportanfrage stellen, All Inclusive ist da recht Kulant

Ob das unbedingt ein Fehler von Avisota ist kann ich nicht nachvollziehen.
Bei Tests, nicht unter Avisota, lösche ich oft weit mehr als 500 Einträge und Contao läuft da nicht in einen Fehler. Das funktioniert aber auch nur mit einer entsprechenden Serverkonfiguration.

Wenn die Lösungen alle nicht helfen, mal ein Ticket für Avisota erstellen, dann dürfte es auch daran liegen. ;)

Was natürlich sein könnte, dass er beim löschen ein Problem mit der Blacklist bekommt.
Eventuell versucht er alle Einträge in die Blacklist zu schreiben und hängt sich dabei dann am Speicherlimit auf.

Das kann natürlich sein!
Nur warum schreibt er es überhaupt in die Blackliste, wenn doch nur der Abonnent gelöscht werden soll?
Löschung heißt ja nicht gleich Sperrung! Verstehe ich zumindest unter einer Blackliste.

Vor allem, da die Blacklist pro Verteiler gilt und nicht Systemweit. Aber das liegt daran, dass Contao beim löschen den delete_callback für jeden einzelnen Eintrag triggert. Das müsste man mal prüfen, ob man das abfangen kann...

hallo ihr beiden:)

erstmal lieben dank für die schnellen antworten. :)

durch das löschen in 500er päckchen ist es möglich die abo-gruppe zu leeren. desweitern kann ich bestätigen das die gelöschten einträge wohl in der blacklist landen, da ein blick in die tl_avisota_recipient_blacklist tabelle zeigt, das diese sich gut gefüllt hat.

bei allinkl habe ich mit solchen dingen gute erfahrungen gemacht. ich habe vorhin nach erstellung des des beitrages eine mail an den strato support geschrieben, da ich was strato angeht grüner hinter den ohren bin. möglicherweise lässt sich eine erhöhung des memory erwirken. ich gehe andernfalls auch nochmal den tipps von Thomas nach, danke dafür.

beim löschen von 500er einheiten von abonnenten habe ich am ende auch etwas über 1500 belassen und konnte dann auch die gruppe löschen. jedenfalls scheint es einfach so zu sein das ab einer gewissen menge contao ins schaufen kommt. das löschen von einigen hundert ist wohl kein problem, aber 6500 erstmal schon.
ich schreibe einen neuen beitrag, falls sich der memory erhöhen lies und es etwas brachte

inzwischen habe ich schonmal etwas weitergeforscht und die angabe memory_limit 104M in der phpinfo liest sich für mich ja ganz ordentlich.

Hast Du den Wert selber definiert oder wird der so zur Verfügung gestellt?

Zitat:

---

Zitat von Thomas

Hast Du den Wert selber definiert oder wird der so zur Verfügung gestellt?

---

hallo thomas,

der wert ist aktuell lt. phpinfo(); ausgabe definiert (nach deiner antwort habe ich mal selber eine phpinfo datei erstellt). ich habe diesen nicht selber verändert und weis nicht ob dies nun einen erhöhten wert durch den strato-support darstellt,
von diesem habe ich leider noch keine antwort vorliegen.

viele grüße
chris

Lässt sich vielleicht jetzt nicht mehr nachvollziehen, dazu hätte man vorher den Wert mal ausgeben lassen sollen.
Ist das Problem denn jetzt Geschichte oder tritt es immer noch auf?

Zitat:

---

Zitat von Thomas

Lässt sich vielleicht jetzt nicht mehr nachvollziehen, dazu hätte man vorher den Wert mal ausgeben lassen sollen.
Ist das Problem denn jetzt Geschichte oder tritt es immer noch auf?

---

derzeit habe ich einen versand am laufen und probiere es danach im laufe des abends/der nacht nochmal und melde mich hier :)