2016-10-02 2 views
4

Ich teste das Limit meiner Python Flask Webanwendung, die auf einem Apache Webserver läuft, indem ich eine Anfrage mache, die über 30 Minuten dauert. Die Anfrage erfordert Tausende von Datenbankanforderungen (einer nach dem anderen) an eine MySQL-Datenbank. Ich verstehe, dass dies idealerweise als ein separater asynchroner Prozess außerhalb des Apache-Servers ausgeführt werden sollte, aber lass uns das jetzt ignorieren. Das Problem, das ich habe, ist, dass, obwohl dies vollständig läuft, wenn ich es auf meinem Mac teste, es abrupt stirbt, wenn es auf einem Linux-Server (Amazon Linux auf AWS EC2) ausgeführt wird. Ich konnte nicht genau herausfinden, was es tötet. Ich habe überprüft, dass der Server nicht über genügend Arbeitsspeicher verfügt. Der Prozess verwendet sehr wenig RAM. Ich konnte keinen Apache-Konfigurationsparameter oder irgendeine Fehlermeldung finden, die für mich Sinn ergibt (selbst nachdem Apache logLevel auf Debug gesetzt wurde). Bitte brauche ich Hilfe, wo ich hinschauen kann. Here're mehr Details über mein Setup:Apache/mod_wsgi Prozess stirbt unerwartet


Laufzeit

Server: Es nach 8mins, 27mins starb, 21mins & 22mins sind. Beachten Sie, dass die meisten dieser Läufe auf einem UAT-Server stattfanden und dies die einzige Anforderung war, die der Server verarbeitet hat.

Mac: Es lief viel langsamer, dass es auf dem Server ausgeführt wird. Der Prozess lief erfolgreich und dauerte 2 Stunden 47 Minuten.


Linux Server Details:
2 virtuelle CPUs und 4 GB RAM

OS (Ausgabe von uname -a)
Linux ip-172-31-63-211 3.14.44-32.39 .amzn1.x86_64 # 1 SMP Do 11. Juni 20.33.38 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Apache error_log:https://drive.google.com/file/d/0B3XXZfJyzJYsNkFDU3hJekRRUlU/view?usp=sharing

Apache-Konfigurationsdatei:https://drive.google.com/file/d/0B3XXZfJyzJYsM2lhSmxfVVRNNjQ/view?usp=sharing

Apache Version (Ausgabe von apachectl -V)

Server version: Apache/2.4.23 (Amazon) 
Server built: Jul 29 2016 21:42:17 
Server's Module Magic Number: 20120211:61 
Server loaded: APR 1.5.1, APR-UTIL 1.4.1 
Compiled using: APR 1.5.1, APR-UTIL 1.4.1 
Architecture: 64-bit 
Server MPM:  prefork 
    threaded:  no 
    forked:  yes (variable process count) 
Server compiled with.... 
-D APR_HAS_SENDFILE 
-D APR_HAS_MMAP 
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) 
-D APR_USE_SYSVSEM_SERIALIZE 
-D APR_USE_PTHREAD_SERIALIZE 
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT 
-D APR_HAS_OTHER_CHILD 
-D AP_HAVE_RELIABLE_PIPED_LOGS 
-D DYNAMIC_MODULE_LIMIT=256 
-D HTTPD_ROOT="/etc/httpd" 
-D SUEXEC_BIN="/usr/sbin/suexec" 
-D DEFAULT_PIDLOG="/var/run/httpd/httpd.pid" 
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status" 
-D DEFAULT_ERRORLOG="logs/error_log" 
-D AP_TYPES_CONFIG_FILE="conf/mime.types" 
-D SERVER_CONFIG_FILE="conf/httpd.conf" 

Mac Details:

Apache-Konfigurationsdatei:https://drive.google.com/file/d/0B3XXZfJyzJYsRUd6NW5NY3lON1U/view?usp=sharing

Apache Version (Ausgabe von apachectl -V)

Server version: Apache/2.4.18 (Unix) 
Server built: Feb 20 2016 20:03:19 
Server's Module Magic Number: 20120211:52 
Server loaded: APR 1.4.8, APR-UTIL 1.5.2 
Compiled using: APR 1.4.8, APR-UTIL 1.5.2 
Architecture: 64-bit 
Server MPM:  prefork 
    threaded:  no 
    forked:  yes (variable process count) 
Server compiled with.... 
-D APR_HAS_SENDFILE 
-D APR_HAS_MMAP 
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) 
-D APR_USE_FLOCK_SERIALIZE 
-D APR_USE_PTHREAD_SERIALIZE 
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT 
-D APR_HAS_OTHER_CHILD 
-D AP_HAVE_RELIABLE_PIPED_LOGS 
-D DYNAMIC_MODULE_LIMIT=256 
-D HTTPD_ROOT="/usr" 
-D SUEXEC_BIN="/usr/bin/suexec" 
-D DEFAULT_PIDLOG="/private/var/run/httpd.pid" 
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status" 
-D DEFAULT_ERRORLOG="logs/error_log" 
-D AP_TYPES_CONFIG_FILE="/private/etc/apache2/mime.types" 
-D SERVER_CONFIG_FILE="/private/etc/apache2/httpd.conf" 
+0

Mit den Informationen, die Sie bereitgestellt haben, ist das Beste, was Sie tun können, jetzt raten, da es nicht genug gibt, um weiterzumachen. Stellen Sie mindestens '' LogLevel'' für Apache auf '' info'' und sehen Sie, was mod_wsgi über Neustarts von Prozessen sagt. Überprüfen Sie auch, dass Sie tatsächlich den mod_wsgi-Daemon-Modus verwenden, wie bereits erwähnt, könnte ein Problem sein. Siehe http://modwsgi.readthedocs.io/en/develop/user-guides/checking-your-installation.html#embedded-oder-daemon-mode –

Antwort

1

Wenn Sie Embedded-Modus von mod_wsgi verwenden, die als Apache steuert die Lebensdauer von Prozessen passieren kann und sie recyceln wenn es denkt, dass ein Prozess wegen unzureichenden Datenverkehrs nicht mehr benötigt wird.

Sie denken vielleicht 'aber ich benutze Daemon-Modus und nicht eingebetteten Modus', aber die Realität ist, dass Sie nicht sind, wie Ihre Konfiguration falsch ist. Sie haben:

<VirtualHost *:5010> 
    ServerName localhost 

    WSGIDaemonProcess entry user=kesiena group=staff threads=5 
    WSGIScriptAlias "/" "/Users/kesiena/Dropbox (MIT)/Sites/onetext/onetext.local.wsgi" 

    <directory "/Users/kesiena/Dropbox (MIT)/Sites/onetext/app"> 
     WSGIProcessGroup start 
     WSGIApplicationGroup %{GLOBAL} 
     WSGIScriptReloading On 
     Order deny,allow 
     Allow from all 
    </directory> 
</virtualhost> 

Das Directory Block kein Verzeichnis nicht verwendet, die den Weg in WSGIScriptAlias übereinstimmt, so nichts davon zutrifft.

Verwendung:

<VirtualHost *:5010> 
    ServerName localhost 

    WSGIDaemonProcess entry user=kesiena group=staff threads=5 
    WSGIScriptAlias "/" "/Users/kesiena/Dropbox (MIT)/Sites/onetext/onetext.local.wsgi" 

    <directory "/Users/kesiena/Dropbox (MIT)/Sites/onetext"> 
     WSGIProcessGroup start 
     WSGIApplicationGroup %{GLOBAL} 
     Order deny,allow 
     Allow from all 
    </directory> 
</virtualhost> 

Der einzige Grund, warum es überhaupt ohne die passende gearbeitet ist, dass Sie den Zugriff auf Apache geöffnet hatten Dateien in diesem Verzeichnis zu hosten, indem:

<Directory "/Users/kesiena/Dropbox (MIT)/Sites"> 
    Require all granted 
</Directory> 

Es ist schlechte Übung, um auch DocumentRoot als übergeordnetes Verzeichnis festzulegen, in dem der Anwendungsquellcode vorhanden ist. Mit der Art, wie es geschrieben ist, gibt es ein Risiko, dass ich auf einem anderen Port oder VirtualHost reinkommen und Ihren gesamten Anwendungscode herunterladen könnte.

Kleben Sie Ihren Anwendungscode nicht unter das Verzeichnis, das unter DocumentRoot aufgeführt ist.

BTW, selbst wenn die WSGI-Anwendung im Daemon-Modus ausgeführt wird, kann Apache die Worker-Prozesse, die es zum Proxy-Request an mod_wsgi verwendet, noch immer recyceln. Selbst wenn Ihre sehr lange laufende Anfrage im WSGI-Anwendungsprozess weiterläuft, kann sie fehlschlagen, sobald sie eine Antwort sendet, wenn der Worker-Prozess in der Zwischenzeit wiederverwendet wurde, weil er zu lange ausgeführt wurde.

Sie sollten den lang andauernden Betrieb auf jeden Fall auf eine Back-End-Sellerie-Taskwarteschlange o.ä.

+0

Danke für die Tipps Graham. Es ist erwähnenswert, dass die Konfigurationsfehler, auf die Sie hinweisen, nur für die Konfiguration auf meinem Mac gelten (wo der Prozess tatsächlich erfolgreich ausgeführt wird). Der Prozess schlägt auf dem Server fehl, auf dem DocumentRoot an einem anderen Speicherort eingerichtet wurde, wie im obigen Link angegeben. – Kes115

+0

Das '' DocumentRoot'' hat nichts damit zu tun, dass es stirbt, es war der Unterschied im Verzeichnisnamen in der '' Directory'' Direktive. Die '' WSGIProcessGroup''-Direktive wurde niemals auf Anfragen an die WSGI-Anwendung angewendet. –

1

Es könnte sein, dass Sie gezwungen sind, Steckdosen zu schließen, obwohl die Zeiten, die Sie angegeben haben, nicht allzu wahrscheinlich sind. Für ein Projekt, das ich auf Azure hatte, wurde jede Verbindung, die für ungefähr 3 Minuten inaktiv war, vom System geschlossen. Ich glaube, dass diese Schließungen vor dem Server im Netzwerk-Routing durchgeführt wurden, also gab es keine Möglichkeit, sie zu deaktivieren oder das Zeitlimit zu erhöhen.

+0

Danke, aber das scheint ziemlich unwahrscheinlich.Ich testete dies, indem ich den Prozess änderte, um eine Antwort an den Client zu senden, sobald die Anfrage eingeht, und dann einen separaten Thread ausschleuste, der die Verarbeitung der Daten auf dem Server fortsetzt. Dieser separate Thread stirbt immer noch abrupt ab. – Kes115

0

Hm knifflige Problem.

Rate 1: Ich hatte einmal ein ähnliches Problem. Hast du ein wenig mit deiner KeepAlive-Zeit gespielt? Setzen Sie es auf 60 Minuten oder mehr und testen Sie, ob das Problem weiterhin besteht. Mehr Details hier https://httpd.apache.org/docs/2.4/de/mod/core.html

Rate 2: Könnte amazon "verschieben" Sie Ihre Maschine im Hintergrund, die Ihre Datenbankverbindung unterbricht oder Flasche kann das "Entladen" und "Laden" der VM nicht behandeln?

+0

Ich werde untersuchen 1. Ich bezweifle 2, weil dies konsequent passiert. Vielen Dank – Kes115

Verwandte Themen