Open Source

Open Source

Posts 1-10 of 10
  • Franz F. Esberger
    Franz F. Esberger    Group moderator
    The company name is only visible to registered members.
    apache2 segmentation faults
    Hallo,

    Hat jemand aus dieser geschätzten Runde Erfahrung mit dem apache2 im Lastbereich ~2Mio Zugriffe tgl ?

    Hatte unter SLES9 (auf einem INTL XEON 3Ghz mit 4GB RAM) apache2 (2.0.49) (prefork) gemeinsam mit php5.0.4 (als apache modul), mod_perl, mod_ssl, mod_auth_ldap und psql 8.1 betrieben, was trotz versuchen mit dem apache 2.0.57 und verschiedenen versionen von php5 unter Last immer in Segmentation Faults endete.

    Auch der Versuch PHP5 per FastCGI zu betreiben, bzw. PHP4 einzusetzen führte zu keiner Verbesserung.
    Es kamen immer fertige Packete zum Einsatz, die Konfigurationen können bei eingehendem Interesse nachgereicht werden.

    Hat irgend jemand eine ähnliche Konstellation unter dem erwähnten Lastbereich (gerne auch darüber ;)) ) am (performanten) Laufen ?

    Meine nun seit Monaten stabile und hochperformante "Lösung" habe ich im selbst kompilieren von apache 1.3.37 und allen benötigten Modulen (php5,perl,ldap,auth_ldap,ssl,...) gefunden.

    Bitte um Eure geschätzten Kommentare die mir beweisen das der apache2 auch für produktive Hochlastumgebungen eingesetzt werden kann und wird, und somit um den nötigen Auftrieb diesem Stück Software nochmal "ne Chance" zu geben (beispielsweise durch ./configure; make; make install;).

    MfG
    FranzF.
    • 30 Nov 2006, 11:44 am
  • Wolfgang Wiese
    Wolfgang Wiese
    The company name is only visible to registered members.
    Re: apache2 segmentation faults
    Wie sieht denn die Load aus?

    Ich hatte vor kurzem erst ein ähnliches Problem mit einem etwas älteren Server,
    auf dem plötzlich aufgrund eines Projektes 200 komplexe Schreiboperationen (auf eine Mediawiki-Installation)
    dauerhaft und nahezu gleichzezitg kamen.

    Etwas geholfen haben die üblichen Dinge: MaxSparseServer runter, Timeouts kleiner, etc pp.
    Dabei war die Kiste nicht wegen der I/O am Schwitzen (wegen den ausgelagerten Filesystem) und auch nicht wegen der Datenbankconnects (zu einen ausgelagerten Datenbankserver), sondern wegen der CPU-Last....
    Aber letztlich waren da snur Tropfen auf den heißen Stein;
    Bei uns haben wir die Situation nur durch eine stärkere Kiste beheben können..

    Wobei in dem Bereich von Millionen und mehr Zugriffen auf viele (Hunderte) virtuelle Hosts ich auch mit Sun Architektur bessere Erfahrungen hab als mit SLES...
    • 30 Nov 2006, 1:03 pm
  • Franz F. Esberger
    Franz F. Esberger    Group moderator
    The company name is only visible to registered members.
    Re^2: apache2 segmentation faults
    <snip>
    Wie sieht denn die Load aus?
    </snip>

    Im "Normalbetrieb" lag die Load bei ~1.5, also keine Tragik, bis zum Zeitpunkt X, an dem die Load immer wieder sukzessive hochging, bis alle 4 CPU's komplett belegt sind (Werte über 100 warn da keine Seltenheit) - und nur ein Restart des apache2 Abhilfe schaffen konnte... Es war uns allerdings nicht möglich den verantwortlichen Prozess (trotz CoreDump usw.) zu identifizieren.

    <snip>
    Ich hatte vor kurzem erst ein ähnliches Problem mit einem etwas älteren Server,
    auf dem plötzlich aufgrund eines Projektes 200 komplexe Schreiboperationen (auf eine Mediawiki-Installation)
    dauerhaft und nahezu gleichzezitg kamen.
    </snip>

    Die Serverhardware ist den Anforderungen imho gewachsen, die Load liegt jetzt mit dem Apache 1.3 ebenfalls zwischen 1 und 1.5.

    <snip>
    Etwas geholfen haben die üblichen Dinge: MaxSparseServer runter, Timeouts kleiner, etc pp.
    </snip>

    Ich vergaß zu erwähnen dass ich auch an diesen Parametern gedreht habe, ich hatte testweise sogar die "worker" Variante im Einsatz, ohne Erfolg.

    <snip>
    Dabei war die Kiste nicht wegen der I/O am Schwitzen (wegen den ausgelagerten Filesystem) und auch nicht wegen der Datenbankconnects (zu einen ausgelagerten Datenbankserver), sondern wegen der CPU-Last....
    </snip>

    Die Box hängt zwar an nem SAN, I/O ist aber in Ordnung, Datenbankconnect sind wie gesagt nur localhost ...

    <snip>
    Wobei in dem Bereich von Millionen und mehr Zugriffen auf viele (Hunderte) virtuelle Hosts ich auch mit Sun Architektur bessere Erfahrungen hab als mit SLES...
    <snip>

    Absolut. SUN Architektur läuft und läuft, full ACK - aber mal abgesehen davon: Der SLES läuft ja nun seit dem Umstieg auf den apache1.3 problemlos durch, worum's mir geht ist ja dass - in meinem Fall - trotz viel Testen und Schrauben der apache2 einfach nicht performant und stabil zu kriegen war - ich aber grade bei einer so massiv eingesetzten Software wie dem httpd2 gerne wissen würde wie/ob andere damit klar kommen.

    Deswegen auch dieser Thread, zu dem sich hoffentlich noch andere Meinungen gesellen werden ...
    • 30 Nov 2006, 2:04 pm
  • Daniel Triendl
    Daniel Triendl
    The company name is only visible to registered members.
    Re^3: apache2 segmentation faults
    Hallo!

    Das letzte mal wo ich mit Segmentation Faults zu tun hatte lag es an einem (wahrscheinlich) defekten RAM Modul. Wahrscheinlich deshalb, weil ein Memtest des Rechners keine Fehler lieferte, aber ein Umzug auf eine baugleiche Maschine den Fehler behoben hat.

    Was ich eigentlich vorschlagen wollte war der Einsatz eines schlankeren Server anstatt eines Apache. Z.B. lighttpd http://www.lighttpd.net/ zeigt in dem Größenbereich in den Sie den Server betreiben eine wesentlich besser Performance als der Apache

    -- Daniel
    • 13 Dec 2006, 8:19 pm
  • Jörg Wendland
    Jörg Wendland    Premium Member
    The company name is only visible to registered members.
    Re^3: apache2 segmentation faults
    Hallo,
    im init-Skript des Apache mit 'ulimit -c unlimited' eine eventuelle
    Größenbeschränkung für core-files aufheben und in der httpd.conf
    mittels 'CoreDumpDirectory' (siehe http://httpd.apache.org/docs/2.0/mod/mpm_common.html#coredum...)
    ein Verzeichnis für Coredumps festlegen. Sobald Segfaults im Betrieb auftreten, wird Apache
    dann seinen core dumpen und dieser lässt sich dann mit gdb ganz fein auswerten, um
    überhaupt feststellen zu können, wo die Segfaults auftreten:

    $ gdb /usr/sbin/apache2 /path/to/coredump
    (gdb) bt full
    [...] backtrace hier

    Noch mehr Info hier: http://httpd.apache.org/dev/debugging.html

    Viele Grüße,
    Jörg
    • 14 Dec 2006, 09:09 am
  • Franz F. Esberger
    Franz F. Esberger    Group moderator
    The company name is only visible to registered members.
    Re^4: apache2 segmentation faults
    <snip>
    Das letzte mal wo ich mit Segmentation Faults zu tun hatte lag es an einem (wahrscheinlich) defekten RAM Modul. Wahrscheinlich deshalb, weil ein Memtest des Rechners keine Fehler lieferte, aber ein Umzug auf eine baugleiche Maschine den Fehler behoben hat.
    </snip>

    Das war einer meiner ersten Gedanken, konnte das Verhalten allerdings auf einer anderen Maschine reproduzieren - das bei beiden die Bausteine hinüber sind/waren ist unwahrscheinlich.

    <snip>
    Was ich eigentlich vorschlagen wollte war der Einsatz eines schlankeren Server anstatt eines Apache. Z.B. lighttpd http://www.lighttpd.net/ zeigt in dem Größenbereich in den Sie den Server betreiben eine wesentlich besser Performance als der Apache
    </snip>

    Guter Punkt, eine Alternative über die ich ebenfalls schon nachgedacht habe. LDAP-Auth, SSL, php und perl unter FastCGI - eigentlich wäre alles da um eine Testumgebung aufzubauen und das Verhalten in meinem speziellen Fall zu untersuchen. Hast du bereits gute Erfahrungen mit lighttpd gemacht ? Bin vor Monaten über mininova draufgestossen - aber einen echten Praxisbericht (ausser den Lobpreisungen auf der Projectsite) habe ich noch nicht in die Finger bekommen ...
    • 14 Dec 2006, 09:57 am
  • Franz F. Esberger
    Franz F. Esberger    Group moderator
    The company name is only visible to registered members.
    Re^4: apache2 segmentation faults
    <snip>
    Sobald Segfaults im Betrieb auftreten, wird Apache
    dann seinen core dumpen und dieser lässt sich dann mit gdb ganz fein auswerten, um
    überhaupt feststellen zu können, wo die Segfaults auftreten:
    </snip>

    Wie weiter oben schon erwähnt, wir konnten trotz Backtrace nicht ausmachen wo sich der Fehler befindet - deswegen ja auch meine resignierende Rückkehr zum 1.3er apache.

    Die Traces deuten auf Probleme im php-Modul hin, aber wie erwähnt haben andere Versionen von PHP bzw die FastCGI Variante keine Besserung gebracht.

    Das mühsame am Testen ist ja die Tatsache das die SegFaults nur bei "realer" Hochlast auftreten. Nehme ich einen baugleichen Server und versuche Hochlast zu "simulieren", also nicht im produktiven System zu testen, läuft der httpd2 wie ein Kätzchen. Das lässt natürlich die Vermutung aufkommen dass durch ein (wahrscheinlich php) Skript oä. ein Speicherfehler verursacht wird - aber wie gesagt, trotz Backtrace und Logging von Skriptstart/endpunkten mit zugehöriger PID um über diesen Zugang ein mögliches Fehlerhaftes Skript zu identifzieren, gelang es nicht festzustellen was genau die Segfaults auslöst.

    Mit dem 1.3er gibts keinen Segfault.

    In welcher Grössenordnung betreibt ihr den apache2 ? Keine Probleme so wie ich sie schildere ?
    • 14 Dec 2006, 10:11 am
  • Post visible to registered members
  • Jörg Wendland
    Jörg Wendland    Premium Member
    The company name is only visible to registered members.
    Re^5: apache2 segmentation faults
    Hallo,

    Franz F. Esberger schrieb:
    Das mühsame am Testen ist ja die Tatsache das die SegFaults nur bei "realer" Hochlast auftreten. Nehme ich einen baugleichen Server und versuche Hochlast zu "simulieren", also nicht im produktiven System zu testen, läuft der httpd2 wie ein Kätzchen. Das lässt natürlich die Vermutung aufkommen dass durch ein (wahrscheinlich php) Skript oä. ein Speicherfehler verursacht wird - aber wie gesagt, trotz Backtrace und Logging von Skriptstart/endpunkten mit zugehöriger PID um über diesen Zugang ein mögliches Fehlerhaftes Skript zu identifzieren, gelang es nicht festzustellen was genau die Segfaults auslöst.
    Sowas liegt meistens in den Tiefen von PHP begraben, ich hoffe, Ihr
    betreibt den Apache 2 mit mpm_prefork, PHP ist nämlich alles andere
    als threadsafe und das führt sehr häufig zu solchen lastbedingten
    Crashes. Das größte Problem, das sich in diese Kategorie sortieren
    lässt, waren segfaults aufgrund des Einsatzes von APC, die wir nur
    durch langwieriges Herumexperimentieren lokalisieren konnten und
    seit Ersatz von APC durch eaccelerator nicht mehr aufgetreten sind.

    In welcher Grössenordnung betreibt ihr den apache2 ? Keine Probleme so wie ich sie schildere ?
    Die größte hier laufende PHP-Applikation macht etwa 300.000 Page Impressions
    pro Stunde. Keine Segfaults. Läuft auf Debian mit Apache 2.0 und eaccelerator.

    Viele Grüße,
    Jörg
    • 17 Dec 2006, 2:39 pm
  • Franz F. Esberger
    Franz F. Esberger    Group moderator
    The company name is only visible to registered members.
    Re^6: apache2 segmentation faults
    Jörg Wendland schrieb:
    Sowas liegt meistens in den Tiefen von PHP begraben, ich hoffe, Ihr
    betreibt den Apache 2 mit mpm_prefork, PHP ist nämlich alles andere
    als threadsafe und das führt sehr häufig zu solchen lastbedingten
    Crashes.
    Natürlich, wir betrieben eben aus der "Threadsafe-Problematik", auf die ja auf php.net und apache.org gleichermassen hingewiesen wird, den httpd2 mit mpm_prefork.

    Die größte hier laufende PHP-Applikation macht etwa 300.000 Page Impressions pro Stunde. Keine Segfaults. Läuft auf Debian mit Apache 2.0 und eaccelerator.
    Danke, sowas in der Art wollte ich hören. Es geht ja doch.
    Debian - Sarge oder schon die "frozen" Etch ? However, I'll give it a spin.
    • 18 Dec 2006, 12:11 pm