> Hello! > > I am using uwsgi-1.9.10 on FreeBSD. > > My uwsgi.ini is the following: > [uwsgi] > buffer-size = 65535 > carbon = w.x.y.z:2003 > carbon-id = xxx > carbon-no-workers = true > chdir = /var/chroot/uwsgi > enable-threads = true > harakiri = 10 > harakiri-verbose = true > listen = 1024 > master = true > max-requests = 10000 > module = frontend.wsgi > no-orphans = true > processes = 32 > vacuum = true > > uwsgi is running on 16-core CPU machine and usual LA is ~3. > These 32 processes is enough to process all the incoming requests (more > that enough actually). > > Now I bump 'processes' parameter to, say, 128. The incoming request rate > does not change, so I assume that > these 128 workers will process request as 32 processes did, just each > worker will receive 4 times less requests and will sleep more waiting for > next request. > > But what I see is that LA on that machine raise to 30 (up from 3), and CPU > time raise from ~15%user+5%system to > 40% user + 30% system. > > Why?? > > In similar scenario when running Apache in pre-fork mode it does not > matter how much MinSpareServers I have (1 or 100), > CPU time is utilized equally. Why is it not the case with uwsgi? > > > Thanks in advance. > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >
Best candidate could be your server swapping out as 128 uwsgi processes can consume a huge amount of ram. Less common could be thundering herd (http://uwsgi-docs.readthedocs.org/en/latest/articles/SerializingAccept.html) but on virtualized kernels and sysvipc locking i have received some report in the past. -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
