Estou hospedando um aplicativo que consiste em vários módulos do Python. Até agora usamos o Apache no modo de trabalho MPM e o mod_wsgi, que é um ambiente de trabalho.
Agora queremos verificar se o nginx + uwsgi pode ser um ambiente com maior desempenho. Python é o Python 2.6.6 e o uwsgi é 2.0.7. Eu tenho a seguinte configuração do uWSGI para meu aplicativo (exemplo reduzido):
[uwsgi]
chdir = /path/to/app
chmod-socket = 777
no-default-app = True
socket = /tmp/socket.sock
master = 1
processes = 4
threads = 2
enable-threads = true
touch-reload=/root/uwsgi.ini
manage-script-name = True
mount = /accounts=account.py
[... several more mount directives ...]
mount = /ping=ping.py
[... several more mount directives ...]
mount = /subscriptions=subscription.py
callable = application
enable-logging = 1
plugin = /usr/lib/uwsgi/stats_pusher_statsd
stats-push = statsd:graphite-int.cern.ch:8125:uwsgi-test
enable-metrics = 1
memory-report = 1
stats = /tmp/stats.sock
Quando eu começo o uWSGI assim, no começo tudo fica bem para mim:
[uWSGI] getting INI configuration from rucio.wsgi.ini
*** Starting uWSGI 2.0.7 (64bit) on [Mon Aug 25 19:15:07 2014] ***
compiled with version: 4.4.7 20120313 (Red Hat 4.4.7-4) on 22 August 2014 22:51:22
os: Linux-2.6.32-431.3.1.el6.x86_64 #1 SMP Mon Jan 6 11:34:51 CET 2014
nodename: rucio-server-dev-ngnix
machine: x86_64
clock source: unix
detected number of CPU cores: 4
current working directory: /root
detected binary path: /usr/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
uWSGI running as root, you can use --uid/--gid/--chroot options
*** WARNING: you are running uWSGI as root !!! (use the --uid flag) ***
your processes number limit is 63837
your memory page size is 4096 bytes
detected max file descriptor number: 4096
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 inherited UNIX address /tmp/rucio.sock fd 3
Python version: 2.6.6 (r266:84292, Jan 23 2014, 10:39:35) [GCC 4.4.7 20120313 (Red Hat 4.4.7-4)]
Python main interpreter initialized at 0x26b1c00
python threads support enabled
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 415360 bytes (405 KB) for 8 cores
*** Operational MODE: preforking+threaded ***
initialized 108 metrics
mounting account.py on /accounts
WSGI app 0 (mountpoint='/accounts') ready in 1 seconds on interpreter 0x26b1c00 pid: 2839
[... several more mount outputs like the one above ...]
mounting ping.py on /ping
WSGI app 8 (mountpoint='/ping') ready in 2 seconds on interpreter 0x9b020b0 pid: 2839
[... several more mount outputs like the one above ...]
mounting trace.py on /traces
WSGI app 15 (mountpoint='/traces') ready in 2 seconds on interpreter 0xf393210 pid: 2839
*** uWSGI is running in multiple interpreter mode ***
gracefully (RE)spawned uWSGI master process (pid: 2839)
spawned uWSGI worker 1 (pid: 2986, cores: 2)
spawned uWSGI worker 2 (pid: 2988, cores: 2)
spawned uWSGI worker 3 (pid: 2990, cores: 2)
spawned uWSGI worker 4 (pid: 2992, cores: 2)
metrics collector thread started
*** Stats server enabled on /tmp/rucio-stats.sock fd: 16 ***
Mas assim que a primeira solicitação chega, independentemente do ponto de montagem solicitado, recebo o seguinte Traceback (o exemplo é um GET / ping):
!!! uWSGI process 2988 got Segmentation Fault !!!
*** backtrace of 2988 ***
/usr/bin/uwsgi(uwsgi_backtrace+0x29) [0x46c8d9]
/usr/bin/uwsgi(uwsgi_segfault+0x21) [0x46ca61]
/lib64/libc.so.6() [0x38bf8329a0]
/usr/lib64/libpython2.6.so.1.0(PyObject_Call+0x3a) [0x38c2c43c4a]
/usr/lib64/libpython2.6.so.1.0(PyEval_CallObjectWithKeywords+0x43) [0x38c2ccfc93]
/usr/bin/uwsgi(python_call+0x1f) [0x47a0bf]
/usr/bin/uwsgi(uwsgi_request_wsgi+0x132) [0x47c602]
/usr/bin/uwsgi(wsgi_req_recv+0x92) [0x420352]
/usr/bin/uwsgi(simple_loop_run+0xc5) [0x464265]
/usr/bin/uwsgi(uwsgi_ignition+0x254) [0x468074]
/usr/bin/uwsgi(uwsgi_worker_run+0x330) [0x468400]
/usr/bin/uwsgi(uwsgi_run+0x3e5) [0x468865]
/lib64/libc.so.6(__libc_start_main+0xfd) [0x38bf81ed1d]
/usr/bin/uwsgi() [0x41d189]
*** end of backtrace ***
DAMN ! worker 2 (pid: 2988) died :( trying respawn ...
Respawned uWSGI worker 2 (new pid: 3003)
O que eu acho é a parte mais interessante, é que se eu remover todos os outros pontos de montagem e, por exemplo, manter apenas
mount = /ping=ping.py
tudo funciona como esperado. Para garantir que esse erro não esteja relacionado ao nosso aplicativo, também testei o exemplo "Hello World" fornecido no site uWSGI. Mas o comportamento permaneceu o mesmo. Um ponto de montagem está funcionando bem, mais do que um causa esse segfault.
Além disso, assim que eu removo a configuração de threads threads = 2 (não os threads ativados!), ela também funciona bem com vários pontos de montagem. Eu, portanto, suspeito que o erro é realmente restrito a ter vários pontos de montagem no modo multithread. E lembre-se, ele funciona no modo de trabalho do Apache MPM, então eu não espero que o aplicativo seja o motivo (pelo menos não neste caso: D)
Gostaria realmente de descobrir isso, já que não seria uma comparação justa entre os nós do Apache e os nós nginx / uwsgi se apenas o Apache fosse capaz de multithreading, certo?
Se você precisar de mais informações, por favor me avise e terá prazer em fornecê-la. Obrigado por qualquer dica ou idéia, e apenas por ler isso até agora você já é um herói do fórum todos os dias; -)
Felicidades, Ralph
Experimente este patch
mas pense duas vezes antes de seguir tal abordagem. Ter vários aplicativos no mesmo espaço de endereço do processo pode parecer legal, mas, mais cedo ou mais tarde, você pagará por uma implementação abaixo do ideal (muitos casos de canto e soluções alternativas ao usar vários threads com vários intérpretes no CPython)
Se funcionou bem no mod_wsgi, muito provavelmente funcionará com o uWSGI também, mas considere dividir cada ponto de montagem em um processo dedicado.