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