"Memory size exhausted", die Zweite.

[Anton Korduan]

Hallo!

Mein Programm führt ein PHP-Script aus, welches e-Mails sozusagen an eine Newsletterliste versendet.

Ich erhielt die Meldung:
Fatal error: Allowed memory size of 104.857.600 bytes exhausted (tried to allocate 14.351.104 bytes) in /kunden/222772_84172/_e_shepherd.de/system/_mysql_wrapper.inc.php on line 104

In der PHP.INI war eingetragen: memory_limit = 100M

Has jetzt auf 150M erhöht.

Bestimmt ist es nicht optimal, "einfach immer nur" das Limit zu erhöhen.

Daher zwei Fragen:

Welche Nachteile hat es, wenn ich das Speicherlimit erhöhe?
Und welche Grenze gibt es hier (hägt wahrscheinlich mit den Nachteilen zusammen)?

Danke und herzliche Grüße,
Anton

[Nils Dornblut]

Hallo!

Mein Programm führt ein PHP-Script aus, welches e-Mails sozusagen an eine Newsletterliste versendet.

Ich erhielt die Meldung:
Fatal error: Allowed memory size of 104.857.600 bytes exhausted (tried to allocate 14.351.104 bytes) in /kunden/222772_84172/_e_shepherd.de/system/_mysql_wrapper.inc.php on line 104

In der PHP.INI war eingetragen: memory_limit = 100M

Has jetzt auf 150M erhöht.

Bestimmt ist es nicht optimal, "einfach immer nur" das Limit zu erhöhen.

Sie stellen damit dem Skript mehr Ressourcen zur Verfügung. Solange der Tarif das unterstützt, ist das kein Problem. Kann einfach so gemacht werden.

Welche Nachteile hat es, wenn ich das Speicherlimit erhöhe?

Es werden mehr Ressourcen auf dem Webserver verwendet, aber das ist in dem Sinne jetzt kein Nachteil.

Und welche Grenze gibt es hier (hägt wahrscheinlich mit den Nachteilen zusammen)?

Das hängt von Ihrem Tarif ab und findet sich in der Leistungsbeschreibung. Beispiel hier:



Wenn Sie in der php.ini über den Wert erhöhen, kann es sein, dass das Skript mit einem 500er Fehler abbricht.

Mit freundlichen Grüßen

Nils Dornblut

[Anton Korduan]

Vielen Dank für Ihre Rückmeldung, Herr Dornblut.

Ich habe noch einen alten Tariv: "ManagedHosting - domain*go-Edition Professional".
Dort sind bei DF-ScriptPower 128 MB RAM angegeben.

Dann riskiere ich mit meiner Eingabe von 150 MB den Abbruch, den Sie beschrieben haben.

Nur zur Sicherheit: Dann sehe ich das richtig, dass ich am Besten bzw. als Maximalwert 128 setzen darf / sollte?

Danke und herzliche Grüße,
Anton

[masterframe]

Ich habe noch einen alten Tariv: "ManagedHosting - domain*go-Edition Professional".
Dort sind bei DF-ScriptPower 128 MB RAM angegeben.

In der PHP.INI war eingetragen: memory_limit = 100M
Has jetzt auf 150M erhöht.

Das ist so eine Eigenart der alten dF - Tarife, dass man unter gewissen Voraussetzungen tatsächlich kurzfristig mehr Ram und eine längere Skript-Laufzeit als im Tarif angegeben nutzen kann. Im alten Forum gab es dazu einige Threads.

Fakt ist aber, dass man sich auf die "Mehrleistung" nicht verlassen kann & sollte.

Fatal error: Allowed memory size of 104.857.600 bytes exhausted (tried to allocate 14.351.104 bytes) in /kunden/222772_84172/_e_shepherd.de/system/_mysql_wrapper.inc.php on line 104

104 + 14 = 128 😉

Nur zur Sicherheit: Dann sehe ich das richtig, dass ich am Besten bzw. als Maximalwert 128 setzen darf / sollte?

Damit wird dein Skript aber wahrscheinlich nicht funktionieren. Du solltest lieber mal prüfen warum dein Skript unglaubliche 128 MB Ram benötigt. Klingt zwar nach PC-Maßstäben nach wenig, für ein PHP Skript sind 128 MB aber schon _sehr_ viel.

[Anton Korduan]

Danke für Deine Unterstützung, masterframe!

Damit wird dein Skript aber wahrscheinlich nicht funktionieren. Du solltest lieber mal prüfen warum dein Skript unglaubliche 128 MB Ram benötigt. Klingt zwar nach PC-Maßstäben nach wenig, für ein PHP Skript sind 128 MB aber schon _sehr_ viel.

Ja, darüber habe ich natürlich als erstes nachgedacht.

Habe auch schon eine Ahnung ...

Folgende Situation:

Ich lese aus der MySQL-Datenbank alle offenen Versandaufträge ein.
(Eine große Abfragen mit vier JOINs)

In obigem Fall hat ein Kunde gut 3.000 Nachrichten in Auftrag gegeben.

Dann arbeite ich 20 davon ab (schön langsam) und beim nächsten Skriptaufruf nach 5 Minuten via Cronjob kommt der nächste 20er-Stapel dran.

Vermutlich sollte ich mit dem LIMIT-Befehl in meiner MySQL-Query arbeiten - das würde vermutlich den Speicherbedarf begrenzen, richtig?

[masterframe]

LIMIT ist definitiv gut.
Wenn du nur 20 Ergebnisse benötigst kannst du dir tatsächlich 2980 sparen.

Läuft das Skript denn fehlerfrei durch wenn es nur 500 Nachrichten sind?

[Anton Korduan]

Läuft das Skript denn fehlerfrei durch wenn es nur 500 Nachrichten sind?

Ja, ich hatte vorher ja das Memory-Limit auf 150 gesetzt und dann liefen auch die gut 3.000 problemlos durch.

Danke für Deine Unterstützung.

[masterframe]

Kannst du den SQL Query und die dazugehörigen PHP Schnipsel hier posten?
Dann gucke ich gerne mal drüber.
Vielleicht fällt mir (und anderen) etwas auf...

[Anton Korduan]

Kannst du den SQL Query und die dazugehörigen PHP Schnipsel hier posten?
Dann gucke ich gerne mal drüber.
Vielleicht fällt mir (und anderen) etwas auf...

Danke für Dein Angebot!

Die Query ist nicht so kompliziert und das mit dem LIMIT ist einfach eine super Lösung.
Ich denke nicht, dass da sonst noch was zu machen ist.

Aber gerne hier die Query:

SELECT

*,
P.`email` AS manual_email,
K.`email` AS kunden_email,
K.`anrede_variante` AS kunden_anrede,
L.`landingpage_impressum`,
L.`standard_anrede_variante`

FROM

`Groupmess_Pipeline` P

INNER JOIN `Groupmess_Templates` T ON (T.`groupmess_id` = P.`groupmess_id`)
LEFT JOIN `Verlauf` V ON (V.`verlauf_id` = P.`verlauf_id`)
LEFT JOIN `Kunden` K ON V.`kunden_id` = K.`kunden_id`
LEFT JOIN `Listen_IDs` L ON V.`listen_id` = L.`listen_id`

WHERE

P.`tosend` = 1 AND
(

T.`groupmess_txt` > ""
OR
T.`groupmess_txt2` > ""

)

AND

(

K.`email` > ""
OR
P.`email` > ""

)

ORDER BY
P.`send_failed`, P.`erstellungsdatum`

LIMIT 50;

Habe jetzt eben LIMIT 50 drangehängt, dadurch müsste das passen.

So oder so: Dankeschön :-)

[Nils Dornblut]

Das ist so eine Eigenart der alten dF - Tarife, dass man unter gewissen Voraussetzungen tatsächlich kurzfristig mehr Ram und eine längere Skript-Laufzeit als im Tarif angegeben nutzen kann. Im alten Forum gab es dazu einige Threads.

Fakt ist aber, dass man sich auf die "Mehrleistung" nicht verlassen kann & sollte.

Es werden da unterschiedlichen Berechnungen wirksam, genaue Details liegen mir diesbezüglich auch nicht vor. Richtig in jedem Fall ist, dass man sich darauf nicht verlassen sollte,

104 + 14 = 128 😉

Die Fehlermeldung sagt immer nur etwas über den aktuellen Bedarf der Allokierung aus und nichts über den Gesamtbedarf. Das wäre dann auch Weissagerei sozusagen. Software ernährt sich da sozusagen in Stücken und versucht sich das zu nehmen was sie gerade meint noch zu brauchen.

Damit wird dein Skript aber wahrscheinlich nicht funktionieren. Du solltest lieber mal prüfen warum dein Skript unglaubliche 128 MB Ram benötigt. Klingt zwar nach PC-Maßstäben nach wenig, für ein PHP Skript sind 128 MB aber schon _sehr_ viel.

Ja, viele Skripte sind da in der letzen Zeit extrem hungrig geworden.

Mit freundlichen Grüßen

Nils Dornblut

[Nils Dornblut]

Aber gerne hier die Query:

SELECT

*,
[...]
LIMIT 50;

Habe jetzt eben LIMIT 50 drangehängt, dadurch müsste das passen.

Sind die Daten per * alle nötig bzw. überschaubar? Ansonsten klar, das mit dem Limit sollte passen und es wesentlich effizienter machen in jederlei Beziehung. Indexeauf die where-Bedingungen sind gesetzt? Nur falls das Query langsam läuft.

Mit freundlichen Grüßen

Nils Dornblut

[masterframe]

Die Fehlermeldung sagt immer nur etwas über den aktuellen Bedarf der Allokierung aus und nichts über den Gesamtbedarf. Das wäre dann auch Weissagerei sozusagen. Software ernährt sich da sozusagen in Stücken und versucht sich das zu nehmen was sie gerade meint noch zu brauchen.

Ich wollte mit meiner Rechnung nur sagen, dass 104 MB belegt waren und weitere 14 angefordert wurden und somit der verfügbare Speicher komplett belegt war.

[_top_]

...
104 + 14 = 128 😉
...

Ich glaube mein Taschenrechner ist kaputt. Der zeigt mir ein anderes Ergebnis...

[masterframe]

Ach verdammt, du hast natürlich recht.
Das kommt davon wenn man nur halbherzig nachrechnet 😜

[Anton Korduan]

Sind die Daten per * alle nötig bzw. überschaubar? Ansonsten klar, das mit dem Limit sollte passen und es wesentlich effizienter machen in jederlei Beziehung. Indexeauf die where-Bedingungen sind gesetzt? Nur falls das Query langsam läuft.

Mit freundlichen Grüßen

Nils Dornblut

Ja, *-Daten sind überschaubar bzw. nötig - aber stimmt, das ist immer eine beliebte "Bequemlichkeits-Schlamper-Quelle" für Ressoucenverschwendung.

Duch die Indizes sind gesetzt.

Vielen Dank für Ihre Hinweise, Herr Dornblut.