☰

Python Django-Sites auf Apache+mod_wsgi mit Nginx-Proxy: stark schwankende Leistung

tag-icon • tag-icon apache-2.2 wsgi
Python Django-Sites auf Apache+mod_wsgi mit Nginx-Proxy: stark schwankende Leistung

Ich habe eine Ubuntu 10.04-Box, auf der mehrere Dutzend Python Django-Sites mit mod_wsgi (Embedded Mode; derschnellerer Modus, wenn richtig konfiguriert). Die Leistung schwankt stark. Manchmal schnell, manchmal mit mehreren Sekunden Verzögerung. Die Smokeping-Diagramme sind überall.

Kürzlich habe ich außerdem einen Nginx-Proxy für den statischen Inhalt hinzugefügt, in der Hoffnung, dass dies die stark schwankende Leistung verbessern würde. Obwohl dies die Anzahl der Anfragen, die Apache verarbeiten muss, erheblich reduzierte, half es nicht beim Hauptproblem.

Wenn man auf Websites herumklickt, während htop ausgeführt wird, kann man feststellen, dass Anfragen manchmal fast sofort ausgeführt werden, während Apache manchmal für einige Sekunden 100 % der CPU-Leistung verbraucht. Ich verstehe wirklich nicht, woher diese Schwankung kommt.

Ich habe den mpm_worker für Apache wie folgt konfiguriert:

StartServers          1
MinSpareThreads      50
MaxSpareThreads      50
ThreadLimit          64
ThreadsPerChild      50
MaxClients           50
ServerLimit          1
MaxRequestsPerChild  0
MaxMemFree           2048

1 Server mit 50 Threads, max. 50 Clients. Munin und apache2ctl -tbeide zeigen eine konstante Präsenz von Arbeitern; sie werden nicht ständig zerstört und erstellt. Dennoch verhält es sich so.

Dassagt mir, dass ein einmal erstellter Unterinterpreter im Speicher verbleiben sollte, dennoch scheint es, als müssten Sites ständig neu geladen werden.

Ich habe auch eine Nginx+Gunicorn-Box, die ziemlich gut funktioniert. Ich würde wirklich gerne wissen, warum Apache so zufällig ist.

Dies ist eine virtuelle Hostkonfiguration:

<VirtualHost *:81>
    ServerAdmin [email protected]
    ServerName example.com

    DocumentRoot /srv/http/site/bla

    Alias /static/ /srv/http/site/static
    Alias /media/ /srv/http/site/media
    WSGIScriptAlias / /srv/http/site/passenger_wsgi.py

    <Directory />
            AllowOverride None
    </Directory>

    <Directory /srv/http/site>
            Options -Indexes FollowSymLinks MultiViews
            AllowOverride None
            Order allow,deny
            allow from all
    </Directory>

  • Ubuntu 10.04
  • Apache 2.2.14
  • mod_wsgi 2.8
  • nginx 0.7.65

Bearbeiten: Ich habe Code in die Datei settings.py einer Site eingefügt, der das Datum bei jedem Laden in eine temporäre Datei schreibt. Ich kann jetzt sehen, dass die Site nicht ständig zufällig neu geladen wird, also muss Apache es im Speicher behalten. Das ist also gut, bringt mich aber einer Antwort nicht näher ...

Edit: Ich habe gerade einen Fehler gefunden, der vielleicht auch hiermit zusammenhängt:

  File "/usr/lib/python2.6/subprocess.py", line 633, in __init__
    errread, errwrite)

  File "/usr/lib/python2.6/subprocess.py", line 1049, in _execute_child
    self.pid = os.fork()

OSError: [Errno 12] Cannot allocate memory

Der Server hat 600 von 2000 MB frei, was ausreichend sein sollte. Gibt es irgendwo ein Limit für Apache oder WSGI?

Antwort1

Haben Sie versucht, mit New Relic herauszufinden, ob es sich um ein Problem in Ihrer Webanwendung handelt? Kostenloses Kontingent verfügbar und auch eine erste vollständige Testversion. Überblick über die Vorteile:

Wenn ein bestimmtes Problem mit der Webanwendung oder dem verwendeten Backend-Dienst nicht als Problem auffällt, kann der Bericht zur WSGI-Serverkapazitätsanalyse Aufschluss darüber geben, ob Ihre Kapazitäten erschöpft sind. Er kann Ihnen auch sagen, ob Sie zu viele Ressourcen bereitstellen und verschwenden, was tatsächlich recht häufig der Fall ist.

Übrigens würde ich generell davon abraten, 50 Anfrage-Threads in einem Prozess zu verwenden. Besser sind etwa 5 Threads und mehrere Prozesse. Was genau am besten ist, hängt allerdings wirklich von der jeweiligen Anwendung ab, davon, ob sie viel CPU-gebundene Arbeit leistet und wie viele Anfragen mit langer Laufzeit verarbeitet werden müssen. Auch die Bereitstellung vieler statischer Dateien über denselben Apache kann sich darauf auswirken, wobei der Daemon-Modus von mod_wsgi möglicherweise sogar eine bessere Gesamtlösung ist.

Sie verwenden außerdem eine sehr alte mod_wsgi-Version, glauben aber nicht, dass dies ein Problem verursachen würde.

Um Probleme mit einigen C-Erweiterungsmodulen von Drittanbietern für Python zu vermeiden, legen Sie Folgendes fest, wenn dies die einzige WSGI-Anwendung auf diesem Server ist:

WSGIApplicationGroup %{GLOBAL}

Antwort2

Ich habe es behoben. Ich habe alle Produktionsseiten so umgestellt, dass sie ihren eigenen Prozess verwenden (und alle Entwicklungsseiten alle zusammen in einem Prozess), im Daemon-Modus. Die Smokeping-Diagramme sind jetzt viel besser. Die Leistung ist stabil.

Ich bin immer noch im Dunkeln darüber, warum diese Probleme im eingebetteten Modus auftraten, denn soweit ich das beurteilen kann, gab es bei mir keine Prozesserstellung/-zerstörung, aber zumindest habe ich einen besser laufenden Server.

Bearbeiten:

Als Beispiel für eine Apache-Site-Konfiguration:

WSGIDaemonProcess mysite12 processes=1 threads=10 display-name=%{GROUP}
WSGIProcessGroup mysite12

Und dann gebe ich für Sites mit niedriger Priorität Folgendes ein wsgi.conf:

WSGIDaemonProcess developmentsites processes=1 threads=15 display-name=%{GROUP}

Und dann in einer Apache-Konferenz:

WSGIProcessGroup developmentsites

Schauen Sie sich den Unterschied an (auch wegen des Nginx-Proxys):

Bildbeschreibung hier eingeben

verwandte Informationen