Danke Danke:  0
Gefällt mir Gefällt mir:  0
Dislikes Dislikes:  0
Ergebnis 1 bis 4 von 4

Thema: der Aapche und sein Speicherhandling

  1. #1

    Registriert seit
    30.03.07
    Danke (erhalten)
    0
    Gefällt mir (erhalten)
    32

    Standard der Aapche und sein Speicherhandling

    Anzeige
    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
    Bleib wer Du bist !
    Es sei denn Du kannst Superman sein, dann
    sei Superman ...

  2. #2

    Registriert seit
    15.05.14
    Danke (erhalten)
    17
    Gefällt mir (erhalten)
    99

    Standard

    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.
    Geändert von Fluffy (11.01.17 um 11:37 Uhr)
    - Politische Korrektheit ist der Tod einer Gesellschaft -
    - Niemand hat das Recht NICHT angefressen zu sein -
    - Don't be fooled... Google is evil.... and so is Alphabet -

  3. #3
    Member of Honour Avatar von Chakky
    Registriert seit
    28.10.03
    Danke (erhalten)
    15
    Gefällt mir (erhalten)
    210

    Standard

    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"
    cu
    Chakky

    we are dreaming in digital
    we are living in realtime
    we are thinking in binary
    we are talking in IP
    welcome to our world

  4. #4
    Moderator Avatar von bitmuncher
    Registriert seit
    30.09.06
    Danke (erhalten)
    120
    Gefällt mir (erhalten)
    1569

    Standard

    Anzeige
    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.

    Bitmuncher's TechBlog - My Homepage
    Denken ist manchmal so, als würde man wissen auskotzen.

    Neue Beiträge im Habo via Twitter - Das HaBo auf FB - Das HaBo bei G+

Ähnliche Themen

  1. Was mag das für ein Bauteil sein?
    Von AcoQ im Forum Off topic-Zone
    Antworten: 8
    Letzter Beitrag: 10.04.09, 00:37
  2. besoffen sein
    Von Freizeithacker im Forum Off topic-Zone
    Antworten: 42
    Letzter Beitrag: 17.07.08, 23:15
  3. PHP uns sein Login
    Von ByteSurfer im Forum Code Kitchen
    Antworten: 20
    Letzter Beitrag: 14.01.08, 21:42
  4. Musste einfach sein... ^^
    Von MJK im Forum Fun Section
    Antworten: 3
    Letzter Beitrag: 18.11.04, 12:53
  5. was kann das sein??
    Von Seo im Forum Linux/UNIX
    Antworten: 3
    Letzter Beitrag: 22.05.03, 16:51

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •