Sorry ignore last message I had a typo in the nginx config file. On Fri, Jul 6, 2012 at 2:26 PM, Bruce Wade <[email protected]> wrote:
> For some reason when I changed from TCP to socket file I get 503 Service > Unavailable with no errors in uwsgi log: > > tail uwsgi.log > *** uWSGI is running in multiple interpreter mode *** > spawned uWSGI master process (pid: 7384) > spawned uWSGI worker 1 (pid: 7392, cores: 1) > set cpu affinity for worker 1 to 0 1 2 > spawned uWSGI worker 2 (pid: 7393, cores: 1) > set cpu affinity for worker 2 to 3 0 1 > spawned uWSGI worker 3 (pid: 7394, cores: 1) > set cpu affinity for worker 3 to 2 3 0 > spawned uWSGI worker 4 (pid: 7395, cores: 1) > set cpu affinity for worker 4 to 1 2 3 > > > > On Fri, Jul 6, 2012 at 1:49 PM, Łukasz Mierzwa <[email protected]>wrote: > >> Dnia piątek, 6 lipca 2012 12:53:25 Ryan Showalter pisze: >> > On Fri, Jul 6, 2012 at 12:21 PM, Bruce Wade <[email protected]> >> wrote: >> > > Thanks I have changed that setting. >> > > >> > > Is there anything else that jumps out from my configuration that could >> > > help >> > > performance? >> > >> > I don't have much experience managing this specific sort of setup, but >> > 4 workers to manage 500 simultaneous connections seems a little low >> > depending on how long it's taking you to serve each request. Try >> > bumping up the number of workers on each node to 8 and see if that >> > helps at all. >> >> Or let uWSGI spawn additional workers if needed: >> >> [uwsgi] >> processes = <max number of workers> >> cheaper = <mininum number workers> >> >> See http://lists.unbit.it/pipermail/uwsgi/2011-September/002625.html >> >> It's hard to saturate single core with just one worker since it might >> wait for >> external resources like memcached, db or client, 2-4 workers per core >> seems >> like a good starting point, but check how many workers can fit in ram >> before >> you start setting very high max number of workers. Once you're out of >> memory >> and you hit swap all the performance of fast server is gone. If you use >> cgroup >> memory limits in uWSGI than it will start swapping workers memory to disk >> once >> they eat all memory they can. >> If you use max-requests or memory limits in uWSGI config than check how >> long >> does it take in peak hours to hit that limit and reload worker, it might >> happen to frequently, and if your app takes to long to start it might slow >> everything down. >> Keep in mind that high number of workers may hit max database connection >> limit >> (it depends on db you use). >> As always - if you can benchmark you workers, apache benchmark or siege >> are >> good enough to get some idea of how many request per second you can get. >> >> Also - if you can change the way nginx talks to uwsgi - instead of local >> tcp >> connection use file socket - you want hammer tcp stack with a lot of >> connections. >> >> in uwsgi config use: "socket = /var/run/uwsgi.socket" >> in nginx config use: "uwsgi_pass unix:///var/run/uwsgi.socket;" >> >> Łukasz Mierzwa >> _______________________________________________ >> uWSGI mailing list >> [email protected] >> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >> > > > > -- > -- > Regards, > Bruce Wade > http://ca.linkedin.com/in/brucelwade > http://www.wadecybertech.com > http://www.fittraineronline.com - Fitness Personal Trainers Online > http://www.warplydesigned.com > > -- -- Regards, Bruce Wade http://ca.linkedin.com/in/brucelwade http://www.wadecybertech.com http://www.fittraineronline.com - Fitness Personal Trainers Online http://www.warplydesigned.com
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
