Apache/mod_wsgi 进程意外终止

Question

我正在通过发出一个需要 30 多分钟才能完成的请求来测试在 Apache Web 服务器上运行的 Python Flask Web 应用程序的限制。该请求需要向 MySQL 数据库发送数千个数据库请求(一个接一个)。我知道这应该理想地作为 apache 服务器之外的一个单独的异步进程运行，但现在让我们忽略它。我遇到的问题是，尽管在我的 mac 上测试它时它完全运行，但在 linux 服务器(AWS EC2 上的 Amazon linux)上运行它时它突然死了。我一直无法弄清楚究竟是什么杀死了它。我已经检查过服务器没有耗尽内存。该过程使用很少的 RAM。我找不到任何对我有意义的 Apache 配置参数或任何错误消息(即使在将 apache logLevel 设置为调试之后)。请我需要关于在哪里看的帮助。以下是有关我的设置的更多详细信息:

运行时间

服务器:它分别在 8 分钟、27 分钟、21 分钟和 22 分钟后死亡。请注意，大多数这些运行都在 UAT 服务器上，这是服务器正在处理的唯一请求。

苹果机:它在服务器上运行的速度要慢得多。该过程成功运行，耗时 2 小时 47 分钟。

Linux 服务器详情:
2 个虚拟 CPU 和 4GB RAM

操作系统 ( uname -a 的输出)
Linux ip-172-31-63-211 3.14.44-32.39.amzn1.x86_64 #1 SMP Thu Jun 11 20:33:38 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Apache 错误日志: https://drive.google.com/file/d/0B3XXZfJyzJYsNkFDU3hJekRRUlU/view?usp=sharing

Apache 配置文件: https://drive.google.com/file/d/0B3XXZfJyzJYsM2lhSmxfVVRNNjQ/view?usp=sharing

Apache 版本 ( 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 详细信息:

Apache 配置文件: https://drive.google.com/file/d/0B3XXZfJyzJYsRUd6NW5NY3lON1U/view?usp=sharing

Apache 版本 ( 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"  

Answer 1

如果您正在使用 mod_wsgi 的嵌入式模式，这可能会发生，因为 Apache 控制进程的生命周期，并且如果它认为由于流量不足而不再需要某个进程，则可以回收它们。

您可能会想“但我使用的是守护程序模式而不是嵌入式模式”，但事实是您并不是因为您的配置是错误的。你有:

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

那个Directory块不使用与 WSGIScriptAlias 中的路径匹配的目录，所以它都不适用。

用:

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

它在没有匹配的情况下工作的唯一原因是您已经通过以下方式打开了对 Apache 的访问以托管该目录中的文件:

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

同时设置 DocumentRoot 是不好的做法成为应用程序源代码所在位置的父目录。按照它的写法，我可能会进入不同的端口或 VirtualHost。并下载所有应用程序代码。

不要将您的应用程序代码粘贴在针对 DocumentRoot 列出的目录下.

顺便说一句，即使您在守护进程模式下运行 WSGI 应用程序，Apache 仍然可以回收它用于将请求代理到 mod_wsgi 的工作进程。因此，即使您的长时间运行的请求在 WSGI 应用程序进程中继续运行，如果工作进程由于运行时间过长而在此期间被回收，它在开始发送响应时可能会失败。

您绝对应该将长时间运行的操作转移到后端 Celery 任务队列或类似任务。