mod_wsgi (3.4-14) / Apache 2.4.12 / Red Hat (6.7) / Django 1.8.2 在负载下挂起

Question

我遇到了 mod_wsgi (3.4-14) / Apache 2.4.12 / cx_oracle 5.2 / Oracle 12 / Django 1.8.2 在更大负载下挂起的问题。 过去几个月在开发/测试中使用了该配置。

现在，当部署到生产环境时，Apache 在较大负载下会在几分钟后挂起（它适用于小负载或中等负载）。

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

这是我的配置

我正在使用 Red Hat (6.7) Software Collection 中的 Python 3.3 和 Apache 2.4.12 和 mod_wsgi-3.4-14

Apache 虚拟主机 ... WSGIDaemonProcess app.prod 进程=2 线程=25 显示名称=%{GROUP} 用户=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 的空闲内存以使 apache 正常工作。

Answer 2

现在我有以下 mod_wsgi 配置的解决方法

processes=12 threads=1 inactivity-timeout=300 maximum-requests=1000

它确实解决了问题。

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