Question

我有一个问题，mod_wsgi（3.4-14）/ Apache 2.4.12 / cx_oracle 5.2 / Oracle 12 / Django 1.8.2挂在更大的负载下。该配置在dev / testing中使用了最近几个月。

现在，当部署到生产环境时，Apache会在更大的负载下挂起几分钟（在小负载或中等负载下工作正常）。

我有一个3个Django / Apache / mod_wsgi服务器的集群，当这个问题发生时，每个服务器在5到15分钟内停止响应（逐个）。

这是我的配置

我使用Red Hat（6.7）软件集合中的Python 3.3和Apache 2.4.12以及mod_wsgi-3.4-14

Apache虚拟主机 ... WSGIDaemonProcess app.prod processes = 2 threads = 25 display-name =％{GROUP} user = MY_USER python-path = MY_PATH WSGIProcessGroup app.prod WSGIScriptAlias / /opt/hosts/app/app/wsgi.py

Apache version
Server version: Apache/2.4.12 (Red Hat)
Server built:   Aug 11 2015 08:12:59
Server's Module Magic Number: 20120211:41
Server loaded:  APR 1.5.1, APR-UTIL 1.5.4
Compiled using: APR 1.5.1, APR-UTIL 1.5.4
Architecture:   64-bit
Server MPM:     worker
  threaded:     yes (fixed thread count)
    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="/opt/rh/httpd24/root/etc/httpd"
 -D SUEXEC_BIN="/opt/rh/httpd24/root/usr/sbin/suexec"
 -D DEFAULT_PIDLOG="/opt/rh/httpd24/root/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"

python33-mod_wsgi的-3.4-14.el6.x86_64

Django db configuration
'default': {
    'ENGINE': 'django.db.backends.oracle',
    'NAME': 'DB_NAME',
    'USER': 'webuser',
    'PASSWORD': 'webpassword',
    'HOST': '',
    'PORT': '',
    'CONN_MAX_AGE': None,
    'OPTIONS': {
        'threaded': True,
    },
},


#0  0x00007f047ff099b0 in sem_wait () from /lib64/libpthread.so.0
#1  0x00007f0474b4c6d8 in PyThread_acquire_lock_timed () from /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0
#2  0x00007f0474b2cab5 in _PyImport_AcquireLock () from /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0
#3  0x00007f0474b2cf49 in PyImport_ImportModuleLevelObject () from /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0
#4  0x00007f0474b10f8f in ?? () from /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0
#5  0x00007f0474b1baa4 in PyEval_EvalFrameEx () from /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0
#6  0x00007f0474b1b0f9 in PyEval_EvalFrameEx () from /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0
#7  0x00007f0474b1c457 in PyEval_EvalCodeEx () from /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0
#8  0x00007f0474b1aead in PyEval_EvalFrameEx () from /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0
#9  0x00007f0474b1b0f9 in PyEval_EvalFrameEx () from /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0
#10 0x00007f0474b1b0f9 in PyEval_EvalFrameEx () from /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0
#11 0x00007f0474b1b0f9 in PyEval_EvalFrameEx () from /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0
#12 0x00007f0474b1b0f9 in PyEval_EvalFrameEx () from /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0
#13 0x00007f0474b1b0f9 in PyEval_EvalFrameEx () from /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0
#14 0x00007f0474b1b0f9 in PyEval_EvalFrameEx () from /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0
#15 0x00007f0474b1c457 in PyEval_EvalCodeEx () from /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0
#16 0x00007f0474a90842 in ?? () from /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0
#17 0x00007f0474a69fd6 in PyObject_Call () from /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0
#18 0x00007f0474b11763 in PyEval_CallObjectWithKeywords () from /opt/rh/python33/root/usr/lib64/libpython3.3m.so.1.0
#19 0x00007f0474e8f6ac in ?? () from /opt/rh/httpd24/root/etc/httpd/modules/mod_python33-wsgi.so
#20 0x00007f0474e93f8b in ?? () from /opt/rh/httpd24/root/etc/httpd/modules/mod_python33-wsgi.so
#21 0x00007f0474e976c8 in ?? () from /opt/rh/httpd24/root/etc/httpd/modules/mod_python33-wsgi.so
#22 0x00007f047ff03a51 in start_thread () from /lib64/libpthread.so.0
#23 0x00007f047fc509ad in clone () from /lib64/libc.so.6

如果我减少了mod_wsgi的数量，那么问题就会消失，但性能是不可接受的

WSGIDaemonProcess app.prod processes=4 threads=1 display-name=%{GROUP} user=MY_USER python-path=MY_PATH

有人可以提出可能的原因或者我该如何调试呢？

More details on mod_wsgi mailing list

Answer 1

据我所知，获得更多公羊可以提供帮助。我曾经在我的服务器上运行多个django站点，而apache通常会不时地停止工作。它在我重新启动时曾经正常工作，但在一段时间后再次失效。检查服务器在负载下剩余多少内存：free -m。服务器应该有大约100-200mb个免费ram来使apache正常工作。

Answer 2

目前我已经解决了以下mod_wsgi配置

的问题

processes = 12个threads = 1 inactivetivity-timeout = 300 maximum-requests = 1000

它确实解决了这个问题。

但是有一个计划来解决核心问题。

mod_wsgi（3.4-14）/ Apache 2.4.12 / Red Hat（6.7）/ Django 1.8.2挂载

2 个答案: