Apache/mod_wsgi進程意外死掉

我正在測試運行在Apache Web服務器上的Python Flask Web應用程序的限制，通過發出需要超過30分鐘才能完成的請求。請求需要成千上萬的數據庫請求（一前一後）到MySQL數據庫。我明白這一點最好應運行的Apache服務器之外的單獨的異步處理，但讓我們忽略了現在。我遇到的問題是，雖然這個時候我測試了我的Mac上運行完全，它在Linux服務器（AWS上亞馬遜EC2的Linux）上運行時，它突然死亡。我一直無法弄清楚究竟是什麼殺了它。我檢查過服務器沒有用完內存。該過程使用很少的RAM。我已經無法找到任何Apache的配置參數，或者對我來說很有意義（甚至apache的日誌級別設置爲調試後）的錯誤信息。請問我需要尋求幫助。關於我的設置我這裏還有更多的細節：Apache/mod_wsgi進程意外死掉

運行時間

服務器：之後8分鐘，27mins死亡，分別21mins & 22mins。請注意，大多數這些運行的是一個UAT服務器上，這是服務器正在處理的唯一請求。

的Mac：它跑慢得多，它在服務器上運行。該過程成功運行，耗時2小時47分鐘。

Linux服務器細節：
2個虛擬CPU和4GB RAM

OS（的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 error_log：https://drive.google.com/file/d/0B3XXZfJyzJYsNkFDU3hJekRRUlU/view?usp=sharing

Apache的配置文件：

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"

來源

2016-10-02 Kes115

隨着您提供的信息，現在最好的人都可以做的事情是猜測，因爲沒有足夠的可以繼續下去。至少爲Apache設置''LogLevel''爲''info''並查看mod_wsgi關於進程重啓的說明。另外請確認您已經使用了mod_wsgi守護進程模式，正如已經指出的那樣可能是一個問題。請參閱http://modwsgi.readthedocs.io/en/develop/user-guides/checking-your-installation.html#embedded-or-daemon-mode –

如果您正在使用的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任務隊列或類似的位置。

來源

2016-10-03 06:07:11

謝謝Graham提示。值得注意的是，你指出的配置錯誤只適用於我的mac上的配置（該過程實際運行成功）。該過程在DocumentRoot設置爲不同位置的服務器上失敗，如上面的鏈接所示。 – Kes115

「DocumentRoot」與它死去無關，它是目錄名稱在「Directory」指令中的不匹配。「WSGIProcessGroup」指令從未應用於對WSGI應用程序的請求。 –

您可能正在使用強制套接字關閉，儘管您給出的時間看起來不太可能。對於我在Azure上進行的項目，任何閒置約3分鐘的連接都會被系統關閉。我相信這些關閉是在網絡路由中的服務器之前完成的，因此無法禁用它們或增加超時。

來源

2016-10-03 20:49:52

謝謝，但這似乎不太可能。我通過修改進程來測試這個過程，以便在請求進入後立即向客戶端發送響應，然後分離出一個單獨的線程繼續處理服務器上的數據。這個單獨的線程仍然突然死亡。 – Kes115

Hm棘手的問題。

猜測1：我曾經有過類似的問題。你有沒有玩過KeepAlive時間？將其設置爲60分鐘或更長時間並測試以確定問題是否持續。更多細節在這裏https://httpd.apache.org/docs/2.4/de/mod/core.html

猜測2：可能亞馬遜「移動」你的機器在後臺，這會中斷你的數據庫連接或燒瓶無法處理VM的「卸載」和「加載」？

來源

2016-10-11 21:19:43 chickahoona

我會調查1.我懷疑2，因爲這一貫發生。謝謝 – Kes115

Apache/mod_wsgi進程意外死掉

回答

相關問題