Einiges kann man sich doch denken: PHP.ini: [output_buffering](http://php.net/manual/de/outcontrol.configuration.php#ini.output-buffering)=Off * Beim Start Ausgaben nach /dev/null umleiten, Fehler und Notizen in ein Logfile umleiten, welches von Logroate behandelt wird. * Kann man das output_buffering nicht setzen, dann regelmäßig [ob_clean()](http://php.net/manual/de/function.ob-clean.php) anwenden. Im aufgerufenen Skript: ~~~php <?php #… # ob_clean(); # optional # ?> "PHP"-Tag NICHT schließen ~~~ * Keine Arrays, die immer größer werden, verwenden. * Bei Bedenken: Ein mit [nohub](https://wiki.ubuntuusers.de/nohup/) oder [batch](https://linux.die.net/man/1/batch) gestartetes, ewig laufendes Shell-Skript startet das PHP-Skript (welches selbst NICHT ewig läuft) immer wieder neu und sorgt so neben den Ausgabeumleitungen auch für den Neustart von PHP und also Vermeidung des "heap-overflow". Will man den Job killen muss dann natürlich das Shell-Skript gekillt werden. Optimal schreibt es hierzu die PID in eine Datei mit bekannten Name und startet nicht, wenn diese Datei existiert. Der Job-Killer muss also auch die Datei löschen. * ist das PHP-Skript ein "ewiger Selbstläufer", dann sollte man seine Variablen innerhalb des `while(true) { … }` mit `unset()` aufräumen lassen. Das gilt auch für Objektvariablen.

Einiges kann man sich doch denken: PHP.ini: [output_buffering](http://php.net/manual/de/outcontrol.configuration.php#ini.output-buffering)=Off * Beim Start Ausgaben nach /dev/null umleiten, Fehler und Notizen in ein Logfile umleiten, welches von Logroate behandelt wird. * Kann man das output_buffering nicht setzen, dann regelmäßig [ob_clean()](http://php.net/manual/de/function.ob-clean.php) anwenden. Im aufgerufenen Skript: ~~~php <?php #… # ob_clean(); # optional # ?> "PHP"-Tag NICHT schließen ~~~ * Keine Arrays, die immer größer werden, verwenden. * Bei Bedenken: Ein mit [nohub](https://wiki.ubuntuusers.de/nohup/) oder [batch](https://linux.die.net/man/1/batch) gestartetes, ewig laufendes Shell-Skript startet das PHP-Skript (welches selbst NICHT ewig läuft) immer wieder neu und sorgt so neben den Ausgabeumleitungen auch für den Neustart von PHP und also Vermeidung des "heap-overflow". Will man den Job killen muss dann natürlich das Shell-Skript gekillt werden. Optimal schreibt es hierzu die PID in eine Datei mit bekannten Name und startet nicht, wenn diese Datei existiert. Der Job-Killer muss also auch die Datei löschen. * ist das PHP-Skript ein "ewiger Selbstläufer", dann sollte man seine Variablen innerhalb des `while(true) { … }` mit `unset()` aufräumen lassen.

Einiges kann man sich doch denken: PHP.ini: [output_buffering](http://php.net/manual/de/outcontrol.configuration.php#ini.output-buffering)=Off * Beim Start Ausgaben nach /dev/null umleiten, Fehler und Notizen in ein Logfile umleiten, welches von Logroate behandelt wird. * Kann man das output_buffering nicht setzen, dann regelmäßig `[ob_clean()](http://php.net/manual/de/function.ob-clean.php)` anwenden. Im aufgerufenen Skript: ~~~php <?php #… # ob_clean(); # optional # ?> "PHP"-Tag NICHT schließen ~~~ * Keine Arrays, die immer größer werden, verwenden. * Bei Bedenken: Ein mit [nohub](https://wiki.ubuntuusers.de/nohup/) oder [batch](https://linux.die.net/man/1/batch) gestartetes, ewig laufendes Shell-Skript startet das PHP-Skript (welches selbst NICHT ewig läuft) immer wieder neu und sorgt so neben den Ausgabeumleitungen auch für den Neustart von PHP und also Vermeidung des "heap-overflow". Will man den Job killen muss dann natürlich das Shell-Skript gekillt werden. Optimal schreibt es hierzu die PID in eine Datei mit bekannten Name und startet nicht, wenn diese Datei existiert. Der Job-Killer muss also auch die Datei löschen. * ist das PHP-Skript ein "ewiger Selbstläufer", dann sollte man seine Variablen innerhalb des `while(true) { … }` mit `unset()` aufräumen lassen.