Probleme mit Last & RAM auf vServer

Dieses Thema im Forum "Server Administration" wurde erstellt von Feanwulf, 30. März 2008.

  1. Feanwulf

    Feanwulf Member

    Hallo,

    seit ca. 4 Tagen stürzt mein Server regelmässig ab.

    Meistens ist der komplette RAM (512KB) und der eingerichtete SWAP (=2GB) aufgebraucht und der Server ist Out-Of-Memory!

    Meistens ist vorher die Last soweit in die Höhe geschossen, daß auf dem Server nichts mehr geht und nur ein Reboot hilft.

    Ich habe schon Amavis deinstalliert, auf Clamd umgestellt, die SMTP Prozesse auf 10 beschränkt. Die Apache Prozesse auf 25 Clients/Servers.

    Aber trotzdem immer das selbe - wie kann ich da auf Fehlersuche gehen?


    TOP Ausgabe vor dem Stoppen von Apache:
    Mem: 516912k total, 509792k used, 7120k free, 5276k buffers
    Swap: 2047992k total, 1388052k used, 659940k free, 31068k cached

    anscheinend laufen die Apache Prozesse mehrere Stunden obwohl ich KeepAlive = off und die Timeoutzeit runtergesetzt habe.

    TOP Ausgabe nach dem Stoppen von Apache:
    Mem: 516912k total, 229864k used, 287048k free, 9012k buffers
    Swap: 2047992k total, 306424k used, 1741568k free, 45420k cached


    Anscheinend liegt es irgendwo im Apache!
     
    Zuletzt bearbeitet: 30. März 2008
  2. Till

    Till Administrator

    Was für eine Virtualisierungslösung setzt Du ein?

    Es ist normal dass apache Prozesse recht lang laufen, da ein apache prozess für mehrere aufeinanderfolgende Page Requests genutzt wird.
     
  3. Feanwulf

    Feanwulf Member

    Mein Provider (= Arbeitgeber) setzt XEN ein!

    Ich hab das Problem auch erst seit wenigen tagen, das wundert mich am meisten. Naja wenn ihr mir die Daumen drückt hab ich ab morgen nen neuen Job und bestell mir nen RootServer bei Strato!
     
  4. Feanwulf

    Feanwulf Member

    Bei mir lag es wohl daran, daß mod_security den Server zum Absturz gebracht hatte. Modul deaktiviert und der Server schnurrt wieder wie ein Kätzchen ;)
     
  5. phor

    phor New Member

    Ich hab hier nen openVZ vServer mit 768 MB Ram und der Apache läuft irgendwie AMOK. Nach paar Minuten hat er den restlichen Ram von ca. 200MB ersatzlos mit php5-cgi Prozessen aufgefressen und irgendwann bleibt mir nichts mehr als den Server neu zu starten, weil er mangels Ram nix mehr machen kann.

    Wie kann ich das eindämmen?! Scheint mir allerdings irgendwie an openVZ zu liegen. Bei ispCP hab ich schon ähnliches beobachtet. Wohl in Verbindung mit fcgid die Probleme.

    Ist ein AMD64 System mit 64Bit Debian Lenny.

    Im error.log ist nur irgendwann out-of-memory.
     
  6. Till

    Till Administrator

    Wenn Du so wenig Ram hast dann bleibt Dir nicht viel anderes übrig als z.B. auf mod_php auszuweichen, da es die resourcen schont.
     
  7. phor

    phor New Member

    Naja, wieviel brauche ich denn?

    Auf nem anderen Server (XEN) sieht das ganze so aus:

    Code:
    # free
                 total       used       free     shared    buffers     cached
    Mem:        256216     225328      30888          0       2956      39180
    -/+ buffers/cache:     183192      73024
    Swap:       786424     155228     631196
    Der begnügt sich also mit um die 400MB - auch fcgid. Meines Erachtens gibts da irgendein Problem in Verbindung mit openVZ.
     
  8. Till

    Till Administrator

    Unter Xen hast Du swap speicher, mit dem er spitzen abfangen kann. Unter openvz ist der speicher hart limitiert ohne swap.

    Wieviel speicher Du bei suphp oder cgi brauchst das hängt ganz einfach von der Anzahl der gleichzeitigen Zugriffe auf Deinen Server ab.
     
  9. phor

    phor New Member

    Das ist mir schon klar aber das erklärt trotzdem nicht, warum bei openVZ der Speicher maßlos voll läuft und unter XEN bei nicht annähernd.
     
  10. Till

    Till Administrator

    Xen weicht dann kurzfristig auf den swap aus, wie man bei Dir oben sehen kann, openvz kann das aber nicht. Und das erklärt auch das Problem, es sind halt einfach zu viele Anfragen an Deinen Server für zu wenig freigeschalteten Ram bei OpenVZ.
     

Diese Seite empfehlen