[Python] Deploy con nginx e proxy_pass

Ven 3 Gen 2014 13:35:02 CET

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 <roberto a 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 a lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20140103/940a7da9/attachment.html>