Ok, come diceva Alessandro in realtà non siamo nemmeno riusciti a fare dei test con uWSGI e il plugin perchè da errori di Segmentation Fault usando --tornado 100 e --greenlet. Ma usando solo --tornado 100 da questo errore: *** DANGER *** tornado mode without coroutine/greenthread engine loaded !!!
Installato e abilitato con: UWSGI_EMBED_PLUGINS=tornado,greenlet pip install greenlet uwsgi Dopo aver installato i pacchetti python-greenlet e python-greenlet-dev visto che senza diceva di non trovare greenlet/greenlet.h Qui sotto mette le informazioni che penso siano utili. ######################################## # uname -a ######################################## Linux wadev 3.2.0-57-generic #87-Ubuntu SMP Tue Nov 12 21:35:10 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux ----------------- ######################################## # uwsgi.ini ######################################## [uwsgi] socket = 127.0.0.1:9090 uid = service gid = service pythonpath = /usr/local/python/Lib virtualenv = /dati/wall chdir = /dati/wall/src/test wsgi-file = uwsgi_test.py processes = 4 threads = 2 stats = 127.0.0.1:9191 tornado = 100 greenlet = ## Da risposta trovata in rete a proposito di Segmentation Fault. ;master = true ;enable-threads = true ;singe-interpreter = true ######################################## # backtrace ######################################## [uWSGI] getting INI configuration from uwsgi.ini *** Starting uWSGI 2.0 (64bit) on [Fri Jan 3 13:07:47 2014] *** compiled with version: 4.6.3 on 03 January 2014 09:42:28 os: Linux-3.2.0-57-generic #87-Ubuntu SMP Tue Nov 12 21:35:10 UTC 2013 nodename: wadev machine: x86_64 clock source: unix pcre jit disabled detected number of CPU cores: 2 current working directory: /usr/wall/wall detected binary path: /usr/wall/wall/bin/uwsgi setgid() to 1005 set additional group 27 (sudo) setuid() to 1005 your processes number limit is 15866 your memory page size is 4096 bytes detected max file descriptor number: 1024 - async cores set to 100 - fd table size: 1024 lock engine: pthread robust mutexes thunder lock: disabled (you can enable it with --thunder-lock) uwsgi socket 0 bound to TCP address 127.0.0.1:9090 fd 3 Python version: 2.7.3 (default, Sep 26 2013, 20:13:52) [GCC 4.6.3] Set PythonHome to /dati/wall Python main interpreter initialized at 0xa28aa0 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 415280 bytes (405 KB) for 8 cores *** Operational MODE: preforking+threaded *** added /usr/local/python/Lib/ to pythonpath. WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0xa28aa0 pid: 27566 (default app) !!! uWSGI process 27566 got Segmentation Fault !!! *** backtrace of 27566 *** uwsgi(uwsgi_backtrace+0x29) [0x467b69] uwsgi(uwsgi_segfault+0x21) [0x467cf1] /lib/x86_64-linux-gnu/libc.so.6(+0x364a0) [0x7fa4c9f8b4a0] uwsgi() [0x4a6494] uwsgi(uwsgi_init_all_apps+0xcf) [0x46897f] uwsgi(uwsgi_start+0xe6a) [0x4699fa] uwsgi(uwsgi_setup+0x1885) [0x46b955] uwsgi(main+0x9) [0x41e459] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7fa4c9f7676d] uwsgi() [0x41e489] *** end of backtrace *** Grazie, Luca Il giorno 03 gennaio 2014 12:50, Roberto De Ioris <robe...@unbit.it> ha scritto: > > > On Mon, Dec 30, 2013 at 05:26:57PM +0100, Roberto De Ioris wrote: > >> > Mi pare di capire che la soluzione della listen queue che mi hai > >> indicato > >> > risolverebbe questo problema. > >> > > >> > >> > >> server = HTTPServer(app) > >> server.bind(post, backlog=1) > >> > >> (prova anche con zero, su alcuni kernel funziona, anche se non ricordo > >> se > >> e' per quelli piu' recenti o quelli piu' vecchi) > > > > Purtroppo questa strada non ha funzionato. Ricordo che il probelma che > > cerchiamo di risolvere è che quando viene interrotto una chiamata > "lunga", > > nginx libera quella connessione e quindi diritta verso quel processo la > > prossima chiamata, ma il processo di fatto è occupato. > > > > La nostra simulazione è stata fatta con 2 funzioni: is_up e blocking che > > usa > > time.sleep() > > > > class IsUp(tornado.web.RequestHandler): > > def get(self): > > self.write("Is Up Porta %d" ...) > > self.finish() > > > > class Blocking(tornado.web.RequestHandler): > > def get(self, numero=10): > > time.sleep(int(numero)) > > self.write("Bloccato Porta %s\n" % options.port) > > self.finish() > > > > la chiamata usando 'wget -q -O - http://ngtest/blocking/30/' ed > > interrompendolo con Control-c. > > In un terminale separato in ciclo di 'wget -q -O - http://ngtest/is_up' > > Il ciclo si blocca nel momento della interruzione e riprende solo quando > > termita il tempo (e quindi il processo si libera) > > provate a ridurre a 3 secondi il proxy_connect_timeout di nginx, e' > probabile che abbiate sempre almeno uno slot listen_queue libero anche se > lo avete impostato a 1/0. In questo modo se la connessione non completa in > 3 secondi, nginx considera il peer morto (e passa a quello dopo se lo > avete configurato a dovere) > > > > > Credo di capire che vengono descritte più opzioni di configurazione: con > i > > greenlet ed una programmazione asincrona o con processi tornado > > indipendenti. > > guarda terrei questo approccio proprio come ultima spiaggia (e > probabilmente e' piu' semplice modificare tornado) se la osluzione sopra > non dovesse funzionare > > -- > Roberto De Ioris > http://unbit.it > _______________________________________________ > Python mailing list > Python@lists.python.it > http://lists.python.it/mailman/listinfo/python >
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python