der Aapche und sein Speicherhandling

Guten Morgen,
ich habe ein, zwei Fragen und denke ich bin hier im Bereich genau richtig.

Wie genau arbeitet eine Linux Distribution in Verbindung mit einem Apache?

- bekommt der Apache einen festen Speicherbereich zugewiesen, oder ist dieser dynamisch - denn egal wieviel die VW zugeteilt bekommt, die Performance-/Abarbeitung bleibt gleich!

Und zweitens, was zum Teufel ist mit dem GarbageCollector in PHP los?

- nach einer etwas größeren Berechnung seitens des Server/PHP läuft die Arbeitsspeicherbelastung an und bleibt auch belegt nach erfolgreicher Fertigstellung des Jobs. Also er wird nicht wieder freigegeben und somit wird der Server auf lange Sicht immer langsamer.

Ich nutze PHP in der aktuellen Version und eine Debian 8/Jessie Distribution

Gibt es hier Lösungsansätze, bzw. hatte hier jemand schon die gleichen Probleme?

mfg
 
Also du kannst der VM soviel Speicher zuweisen wie du willst, solange du z.B. PHP nicht mehr Ressourcen zuteilst, passiert da nichts(Stichwort php.ini)

Je nachdem wie du Linux konfiguriert hast, werden die Speicheradressen etwas verwürfelt(relativ zu einander). aber grunsätzlich wird immer gerade eine Memorypage belegt die frei ist.
Das geht aber zu sehr in die Betriebssystemstheorie hier.

Für deine Frage wäre auch noch wichtig zu erfahren, wird das Skript im Apache selbst ausführst, oder per PHP-FPM.

BTW.: PHP5.6 und PHP7.1 sind beides aktuelle Versionen ;) .
Gruß

Fluffy

//edit abgesehen davon, das PHP den Bereich nicht freigibt, muss ja nix heißen, die GC kann ja trotzdem funktionieren, heisst ja nur das ungebrauchte Objekte entfernt werden.
Nicht das der Speicherbereich wieder von PHP freigegeben werden muss, denn sonst würde sich das OS ja dumm und dämlich arbeiten wenn du mal genau drüber nachdenkst.
 
Zuletzt bearbeitet von einem Moderator:
Was macht dein php Script? Große Bildberechnungen oder sonstiges? Evtl solltest du mir das Speichermanagement von php anschauen:

PHP: Basic memory management - Manual

Ich tippe wie immer mal aufs blaue. Du machst irgendwas mit deinen Script, das läuft in einen Timeout und der Speicher bleibt "belegt"
 
Es ist ein oft gemachter Fehler davon auszugehen, dass es nur auf die PHP-Settings selbst ankommt. Gleichermaßen wichtig sind die Worker-Settings des Apache, vor allem, wenn man PHP in Form von mod_php einbindet.

Das bedeutet in der Praxis, dass jeder Worker-Prozess im Prinzip eine "PHP-Instanz" mit sich zieht. Weise ich also PHP ein Memory-Limit von 128MB zu und lasse 10 Worker-Prozesse laufen, kann der Apache im Maximalfall allein für PHP 1280MB verbrauchen. Das bedeutet jedoch nicht, dass er das automatisch tut, denn tatsächlich wird nur so viel RAM alloziert, wie PHP tatsächlich verbraucht.

Auch wird immer davon ausgegangen, dass PHP nach der Abarbeitung seines Skripts den Speicher automatisch freigibt. Deswegen stellen viele keinen sinnvollen Wert für MaxConnectionsPerChild ein. Allzu oft sieht man hier einen Wert von 0, womit Kindprozesse niemals erneuert werden, weil man damit die ständige Geburt neuer Indianer-Kinder verhindern möchte. Gerade in Verbindung mit PHP ist das aber nicht sinnvoll. Erst wenn ein Kindprozess erneuert wird, wird der Arbeitsspeicher tatsächlich wieder freigegeben. Ansonsten müssen die Skripte diszipliniert ihre Ressourcen wieder freigeben. Gerade Dinge wie offene Socket-Connections und ähnliches stauen sich sonst gern mal im RAM an.

Deswegen sollte man gerade bei Webapps, die sehr große Datenmengen durch ihre Skripte ziehen, dafür sorgen, dass die Kindprozesse regelmässig erneuert werden, indem man ein sinnvolles Limit für MaxConnectionsPerChild definiert. Dieses sollte nicht zu niedrig sein, weil sonst das ständige Forken von Prozessen sehr auf die Auslastung des Server geht, aber auch nicht zu hoch, weil sonst ggf. zu viel RAM gefressen wird, so dass der Server irgendwann ständig am Swappen ist. Es gibt da leider keine allgemein gültige Regel für die richtige Einstellung. Man muss sie individuell an die jeweilige Webapp anpassen.
 
Zurück
Oben