I successfully managed to install: NGINX + uWSGI + Flask on a CentOS 6.x server
but I still have some doubts in terms of configuration:
1) I am running NGINX as a service: service nginx start/stop/restart
if I type "ps aux | grep nginx", I can see 2 processes:
- (by user root) master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
- (by user nginx) worker process
is that OK?
2) I setup a virtualenv for Flask and installed the uWSGI package under such virtualenv.
Currenty I am starting the uWSGI manually by typing "uwsgi /somedir/uwsgi.ini", where uwsgi.ini is as follows:
chdir = /myappdir
uid = pyuser
chmod-socket = 666
socket = /tmp/uwsgi.sock
module = run
callable = app
virtualenv = /myappdir/myvirtualenv
Is it possible to start uWSGI as a service, similarly to NGINX (as described at point 1) ? Is such case should the user be root or non-root?
3) When I start the uWSGI, I am currently getting the following warning:
*** Python threads support is disabled. You can enable it with --enable-threads ***
I realized that in the "uwsgi.ini" configuration file you can also configure a number of processes and threads. Considering the server I am running has just 1 core, can I set up multiple processes and threads? and if so, how many?
3b) On the NGINX configuration file "/etc/nginx/nginx.conf" it is also possible to specify "worker_processes", which by default are 1. Can I increase that, or it can be higher than 1 only for multicore servers?
4) Beside the threads support disabled, when I start the uWSGI I also get these warnings. What do they mean?
*** WARNING: you are running uWSGI without its master process manager ***
*** Operational MODE: single process ***
*** uWSGI is running in multiple interpreter mode ***
I've moved the most important points from the comments.
Yep, that's the normal behavior. Nginx's master process needs root privileges to manage listening sockets on the machine. This forum thread states that you can change it, but it may cause problems. However, Nginx does allow to change the owner of the worker processes.
It depends on how the uWSGI was installed. If uWSGI was installed via apt-get
you can start (stop, restart) it
like this:
service uwsgi <action>
You installed uWSGI via pip
, so the daemonize option will do
the trick:
/path/to/uwsgi --daemonize /path/to/logfile
You can start it under any user you want, BUT if you decide to run it under root, you should specify the gid and uid options. uWSGI's best practices page says:
Common sense: do not run uWSGI instances as root. You can start your uWSGIs as root, but be sure to drop privileges with the uid and gid options.
Also take a look at master-as-root option.
You can create as many processes and threads as you want, but it should depend on how many requests you're trying to process (concurrent or per second). You can read about this here. I would try different configurations and choose which one works better.
3b. Basically, worker_processes
helps to handle concurrent
requests. See this question.
*WARNING: you are running uWSGI without its master process manager*
You didn't specify a master
option in your .ini file. While master
process is certainly unnecessary, it is very useful. It helps to
effectively control workers and respawn them when they die.
3b) When your nginx consumes a lot of CPU, you can use multi-core with worker_process
.
Basically, Python application is much slower than nginx reverse proxy. So one nginx process is enough.
But some nginx options (e.g. gzip: on;
and gzip_proxied: any
) consumes some CPU.
Watch top command output. If nginx process consumes lot of CPU, you can increase worker_process.
When using nginx as reverse proxy, worker_process should <= number of CPU cores.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With