Gheorghe Chirica | 22 Nov 16:06 2014
Picon

Map routes rules python functions

Hi.

I'm trying to create a simple test app using routing. What I want to accomplish is the following:
- have a list of rules defined.
- each rule map to specific python func
- when rules is matched, call the func(possible pass the params from matching rule $1, $2...)

I found some old, dusty docs, but seems that uwsgi.fastfuncs is no more supported.
 
Can you guid how to accomplish this? I know this is possible. Why? Well in uWSGI all is possible :).


Thx.
_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
Jody McIntyre | 21 Nov 20:39 2014

Server hangs after harakiri; debugging harakiri events in general

Hi,

Our uWSGI server hangs (stops serving any requests until it's
restarted) about once a week, generally after a harakiri event.  Can
anyone help troubleshoot this?  Also how can I debug harakiri events
in general?  Most of them don't cause the server to hang, but I don't
understand what's causing them.  The requests printed when the worker
dies are all normal parts of our app that are accessed hundreds of
times per day without incident.

uWSGI version is 2.0.8.
OS is Ubuntu 14.04 LTS.
CPU is x86_64 - Intel(R) Xeon(R) CPU E5-2670 v2  <at>  2.50GHz on Amazon EC2.
Webserver is nginx, load balancer is haproxy.

Config is below.

Logs from a harakiri that caused the server to hang:

Thu Nov 20 15:09:29 2014 - *** HARAKIRI ON WORKER 8 (pid: 5046, try: 1) ***
HARAKIRI: -- syscall> 7 0x7fffafe0e9c0 0x1 0xffffffff 0x8 0x1040bc8
0x1 0x7fffafe0e9a0 0x7f3afea6cfbd
HARAKIRI: -- wchan> poll_schedule_timeout
Thu Nov 20 15:09:29 2014 - HARAKIRI !!! worker 8 status !!!
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 0] 127.0.0.1 - GET
/acct_quota since 1416495853
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 1] 127.0.0.1 - POST /pullf/
since 1416495854
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 2] 127.0.0.1 - GET / since 1416495861
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 3] 127.0.0.1 - GET / since 1416495853
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 4] 127.0.0.1 - POST /signin/
since 1416495865
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 5] 127.0.0.1 - POST
/clientresp since 1416495856
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 6] 127.0.0.1 - POST /pullf/
since 1416495858
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 7] 127.0.0.1 - GET
/~Dreamshot/495/percentage-of-bachelors-degrees-conferred-to-women-in-the-usa-by-major-1970-2012/
since 1416495852
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 8] 127.0.0.1 - POST
/stylethemes/ since 1416495858
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 9] 127.0.0.1 - POST
/clientresp since 1416495854
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 10] 127.0.0.1 - POST
/clientresp since 1416495856
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 11] 127.0.0.1 - GET
/acct_quota since 1416495860
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 12] 127.0.0.1 - POST
/signin/ since 1416495866
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 13] 127.0.0.1 - POST
/clientresp since 1416495865
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 14] 127.0.0.1 - POST /pullf/
since 1416495853
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 15] 127.0.0.1 - GET
/%7Ehianalytics/189/ since 1416495852
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 16] 127.0.0.1 - POST /pullf/
since 1416495851
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 17] 127.0.0.1 - POST
/signin/ since 1416495868
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 18] 127.0.0.1 - POST
/clientresp since 1416495866
Thu Nov 20 15:09:29 2014 - HARAKIRI [core 19] 127.0.0.1 - GET
/getsources?fid=&extrarefs=Doktorigi%3A8 since 1416495868
Thu Nov 20 15:09:29 2014 - HARAKIRI !!! end of worker 8 status !!!
DAMN ! worker 8 (pid: 5046) died, killed by signal 9 :( trying respawn ...
Respawned uWSGI worker 8 (new pid: 10985)
monitor (pid=10985): Starting stack trace monitor.
WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter 0xa3dd80
pid: 10985 (default app)

When the server is able to successfully restart the worker, the
message looks similar.  Here's our latest:

Fri Nov 21 18:36:12 2014 - *** HARAKIRI ON WORKER 5 (pid: 23549, try: 1) ***
HARAKIRI: -- wchan> futex_wait_queue_me
Fri Nov 21 18:36:12 2014 - HARAKIRI !!! worker 5 status !!!
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 0] 127.0.0.1 - GET /plot
since 1416594367
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 1] 127.0.0.1 - POST
/getuser/ since 1416594367
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 2] 127.0.0.1 - POST
/user_account_actions since 1416594370
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 3] 127.0.0.1 - GET /plot
since 1416594366
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 4] 127.0.0.1 - POST /pullf/
since 1416594368
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 5] 127.0.0.1 - POST
/clientresp since 1416594368
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 6] 127.0.0.1 - GET
/python/3d-plots-tutorial/ since 1416594368
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 7] 127.0.0.1 - POST
/getuser/ since 1416594370
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 8] 127.0.0.1 - POST
/getuser/ since 1416594367
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 9] 127.0.0.1 - POST
/getuser/ since 1416594368
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 10] 127.0.0.1 - POST
/getuser/ since 1416594368
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 11] 127.0.0.1 - POST
/svgtopdf/ since 1416594371
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 12] 127.0.0.1 - POST
/clientresp since 1416594366
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 13] 127.0.0.1 - GET
/quandl?code=WORLDBANK/UZB_SP_RUR_TOTL_ZS since 1416594368
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 14] 127.0.0.1 - GET
/~martin.2098/20/-line0-css-penthouse-line0-line0 since 1416594367
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 15] 127.0.0.1 - POST
/user_account_actions since 1416594368
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 16] 127.0.0.1 - GET /plot
since 1416594368
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 17] 127.0.0.1 - GET /plot
since 1416594367
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 18] 127.0.0.1 - POST
/clientresp since 1416594371
Fri Nov 21 18:36:12 2014 - HARAKIRI [core 19] 127.0.0.1 - POST
/getnotifs/ since 1416594367
Fri Nov 21 18:36:12 2014 - HARAKIRI !!! end of worker 5 status !!!
DAMN ! worker 5 (pid: 23549) died, killed by signal 9 :( trying respawn ...
Respawned uWSGI worker 5 (new pid: 24129)
monitor (pid=24129): Starting stack trace monitor.
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0xae8aa0
pid: 24129 (default app)

Configuration from --show-config:

;uWSGI instance configuration
[uwsgi]
show-config = true
emperor = /etc/streambed_uwsgi.ini
;end of configuration

Contents of /etc/streambed_uwsgi.ini:

[uwsgi]

uid = www-data
gid = www-data

chdir = /var/www/streambed/shelly
module = apache.wsgi
socket = /var/run/streambed.sock
chown-socket = www-data
logto = /var/log/uwsgi/streambed
pidfile = /var/run/streambed.pid

master = true
# Conventional SIGTERM behaviour - needed for runit:
die-on-term = true
# Clean up on exit:
vacuum = true

# 10 processes, 20 threads each:
processes = 10
threads = 20

buffer-size = 32768

# Load the app in each worker process, rather than in the master process:
lazy = true
# Maximum time to service a request (seconds):
harakiri = 300
harakiri-verbose = true
# Reload each process after this number of requests:
max-requests = 10000
# Save HTTP bodies larger than this to disk (bytes):
post-buffering = 1000000

# Stats socket
stats = /var/run/uwsgi/streambed.stats

Thanks for any hints or suggestions on either of these issues!

Jody McIntyre
Plotly Engineering
daedae11 | 19 Nov 10:38 2014

Question about --processes and --threads

Hi, I'm a new comer for uwsgi.

I'm confused about the two question a whole day:
1. I wonder about the difference between argument "--processes 4" and argument "--processes 2 --threads 2".
2. Why should we use nginx + uwsgi , since uwsgi support http and cluster?

help, please


_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
Matt Gushee | 19 Nov 09:27 2014
Picon

Confused about the uWSGI protocol

Hello, list--

I am considering developing a uWSGI library (i.e. to support app
development) for the Racket language, but I am having a little trouble
finding the information I need to do that.

I've read the 'uwsgi Protocol' page on readthedocs.org, but it only
describes the packet encoding. Okay, I've also seen the "magic
variables" page; but those don't seem to be sufficient to build
anything practical. It seems to me that I need to know the
representation of requests and responses, right? I can't find any
documentation that addresses that. Is that outside the scope of uwsgi,
or is there indeed part of the protocol that is undocumented?

I suppose I can study some code - in fact, I'm planning to look at the
Python module anyway - but I suspect I will not be able to tell by
reading that code what is part of the protocol and what is an
implementation detail.

Can anyone help me find the missing knowledge? Many thanks!

--
Matt Gushee
Alexander Demenshin | 16 Nov 17:38 2014
Picon

How to periodically reload idle workers (when they are always active)?

Hi,

I am looking for a way to reload active (but idle) PSGI workers 
periodically
(to keep everything fresh), but so far I found no reliable way to do so.

What I need, basically, is a hook that will be called once worker
is inactive (no activity within N seconds).

Unfortunately, --idle doesn't work this way (and has a problem: #776),
timers are plagued by #58 so could not be used in any of cheaper modes.

Of course, I could monitor workers outside - using stats server, for 
instance,
then send SIGHUP to inactive ones, but this does not look clean enough 
to me,
especially because a worker may get (or start processing) request
exactly when I send SIGHUP.

Any ideas and suggestions are very welcome :)

Thank you!

--

-- 
Best regards,
Alexander.
}--) - Viktor | 16 Nov 12:01 2014
Picon

plenty of uwsgi processes

Hi,

I'm running OpenERP/Odoo (version 7) with uwsgi.

The emperor uwsgi is started by supervisord.
This is the vassals ini file:

[uwsgi]
socket = 127.0.0.1:9090
module = wsgi:application
chdir = /home/openerp/v7_openerp
home = /home/openerp/.virtualenvs/v7_openerp
;pythonpath = /home/openerp/.virtualenvs/v7_openerp/lib/python2.7/site-packages
env = OPENERP_CONFIGRC=/home/openerp/etc/v7_openerp_rc
processes = 2
threads = 1
enable-thread = true
memory-report = true
stats = 127.0.0.1:9191
vacuum = True
master-fifo = /tmp/uwsgi.v7.fifo
lazy-apps = true
uid = openerp
gid = openerp

As expected uwsgitop shows 2 nodes. This stays as is.

If I open htop, and filter on the uwsgi processes for v7_openerp, I see 3 processes. Two of these have the process numbers shown under uwsgitop, the third is mysterious to me.

After the first request another 13 uwsgi vassal processes show up in htop, but not in uwsgitop. The number of uwsgi processes increases with each request.

Do you have an idea how to avoid this scenario and stick with the 2 processes that even uwsgitop knows about, and that I've set up in my configuration file?

_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
Tim Tisdall | 14 Nov 21:05 2014
Picon

py-auto-reload-ignore

I noticed the "py-auto-reload-ignore" option today and was trying to get it to work.  However, when I tried to use it I get the following repeated over and over again:

!!! uWSGI process 10145 got Segmentation Fault !!!
*** backtrace of 10145 ***
/sites/metrics_dev/env/bin/uwsgi(uwsgi_backtrace+0x2e) [0x48414e]
/sites/metrics_dev/env/bin/uwsgi(uwsgi_segfault+0x21) [0x4842d1]
/lib/x86_64-linux-gnu/libc.so.6(+0x321e0) [0x7f84bc50b1e0]
/lib/x86_64-linux-gnu/libc.so.6(+0x11405a) [0x7f84bc5ed05a]
/sites/metrics_dev/env/bin/uwsgi(uwsgi_python_autoreloader_thread+0xcd) [0x49a36d]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x6b50) [0x7f84bdbd7b50]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f84bc5b57bd]
*** end of backtrace ***
DAMN ! worker 1 (pid: 10145) died, killed by signal 11 :( trying respawn ...

The setting is being done in an ini file with the following value:

py-auto-reload-ignore = mainserver.ap_server

I'm not really sure the proper syntax for this option, but as it mentions "module" I tried using the python import syntax for specifying a module.

-Tim
_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
Roman Naumenko | 14 Nov 19:24 2014

Best practices for application code patching, upgrades

Hi,

Is there any good reading how application code should be patched in 
relation to database migration?
The requirements are to maintain uninterrupted service for end users.
We're almost there with multi-zone configuration, haproxy loadbanacers.
But sometime application requires DB migration and it means app servers 
should be shutdown. What design would you consider in this case?

Thanks,
--Roman
Rui Pacheco | 13 Nov 09:31 2014

Re: uWSGI Digest, Vol 62, Issue 11

Found it - the server name was wrong in the Flask config.

> On 12 Nov 2014, at 12:00, uwsgi-request@... wrote:
> 
> Send uWSGI mailing list submissions to
> 	uwsgi@...
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
> or, via email, send a message with subject or body 'help' to
> 	uwsgi-request@...
> 
> You can reach the person managing the list at
> 	uwsgi-owner@...
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of uWSGI digest..."
> 
> 
> Today's Topics:
> 
>   1. Server can't see app and I can't figure out why (Rui Pacheco)
>   2. Re: Server can't see app and I can't figure out why
>      (Damjan Georgievski)
>   3. Monitoring utilization of uwsgi workers (George Necula)
>   4. Re: Monitoring utilization of uwsgi workers (Dincer Kavraal)
>   5. Memory leak when streaming in psgi (uwsgi 2.0.8)
>      (aldem-uwsgi@...)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 11 Nov 2014 15:34:47 +0100
> From: Rui Pacheco <rui@...>
> To: uwsgi@...
> Subject: [uWSGI] Server can't see app and I can't figure out why
> Message-ID: <8BF08864-BD3D-4203-A900-96B7E85DC49C@...>
> Content-Type: text/plain; charset=utf-8
> 
> I have a Flask app running behind uwsgi 2.0.8. Startup logs seem to be ok except for a problem: whenever I hit
a URI on my app I always get a 404. I can see in the uwsgi logs that 0 bytes were returned and on the nginx logs
that the URI was not found. To confuse things further, this happens in my test server but not my production server.
> 
> What?s the best way to debug this?
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 11 Nov 2014 15:58:07 +0100
> From: Damjan Georgievski <gdamjan@...>
> To: uWSGI developers and users list <uwsgi@...>
> Subject: Re: [uWSGI] Server can't see app and I can't figure out why
> Message-ID:
> 	<CAEk1YH7Vc5_o_vQBrD3itdqxddoMqf56zgvqVo4ZnzjBDRNJXQ@...>
> Content-Type: text/plain; charset=UTF-8
> 
> On 11 November 2014 15:34, Rui Pacheco <rui@...> wrote:
>> I have a Flask app running behind uwsgi 2.0.8. Startup logs seem to be ok except for a problem: whenever I
hit a URI on my app I always get a 404. I can see in the uwsgi logs that 0 bytes were returned and on the nginx logs
that the URI was not found. To confuse things further, this happens in my test server but not my production server.
>> 
>> What?s the best way to debug this?
> 
> post your nginx (if you use it) and uwsgi config files,
> also the full log output of uwsgi.
> 
> 
> 
> 
> -- 
> damjan
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 11 Nov 2014 11:01:03 -0800
> From: George Necula <necula@...>
> To: uwsgi@...
> Subject: [uWSGI] Monitoring utilization of uwsgi workers
> Message-ID:
> 	<CACzrfmWNu08uwq3wx2qoWTNU-a6q-pKjTDa8Si9ZDhW9PGzknQ@...>
> Content-Type: text/plain; charset="utf-8"
> 
> Hi,
> 
>  I would like to monitor in a given time interval (e.g., 1min, 5min,
> 15min) the utilization of the worker pool. I think that this can be
> reflected by some moving average of how many tasks are either waiting or
> being processed (like is done for CPU load in Unix systems). If this
> average approaches the number of processes I know that I need to do
> something.
> 
>  Alternatively, I could use a measure of what percentage of the time
> interval there was an available worker.
> 
>  Note that CPU utilization of the machine is not enough, because some of
> my tasks have a fair bit of IO.
> 
>  I suspect that this can be done with the stats, snmp, or metrics
> subsystems, but the documentation is very sparse. I see things like "By
> default uWSGI creates a lot of metrics (and more are planned)" (metrics
> page). But where are these metrics explained.
> 
> Thanks,
> George.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.unbit.it/pipermail/uwsgi/attachments/20141111/27007a9d/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 11 Nov 2014 21:39:05 +0200
> From: Dincer Kavraal <dkavraal@...>
> To: uWSGI developers and users list <uwsgi@...>, George
> 	Necula <necula@...>
> Subject: Re: [uWSGI] Monitoring utilization of uwsgi workers
> Message-ID: <etPan.546265d9.6b8b4567.2ae@...>
> Content-Type: text/plain; charset="utf-8"
> 
> Not exact answer to your question. But, you might missed this one:?
> [2]?http://stackoverflow.com/questions/17163091/how-to-read-uwsgi-stats-output
> 
> At least you could combine the information here [1] with the given description on stack overflow answer [2]
> 
> [1]?http://uwsgi-docs.readthedocs.org/en/latest/StatsServer.html
> 
> 
> Hope helps.
> 
> Dincer
> 
> 
> On 11 Nov 2014 at 21:01:54, George Necula (necula@...) wrote:
> 
> Hi,
> ?
> ? I would like to monitor in a given time interval (e.g., 1min, 5min, 15min) the utilization of the worker
pool. I think that this can be reflected by some moving average of how many tasks are either waiting or being
processed (like is done for CPU load in Unix systems). If this average approaches the number of processes I
know that I need to do something.?
> 
> ? Alternatively, I could use a measure of what percentage of the time interval there was an available worker.?
> 
> ? Note that CPU utilization of the machine is not enough, because some of my tasks have a fair bit of IO.
> 
> ? I suspect that this can be done with the stats, snmp, or metrics subsystems, but the documentation is very
sparse. I see things like "By default uWSGI creates a lot of metrics (and more are planned)" (metrics
page). But where are these metrics explained.?
> 
> Thanks,
> George.?
> _______________________________________________  
> uWSGI mailing list  
> uWSGI@...  
> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi  
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.unbit.it/pipermail/uwsgi/attachments/20141111/1132a053/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 5
> Date: Wed, 12 Nov 2014 00:28:18 +0100
> From: aldem-uwsgi@...
> To: uwsgi@...
> Subject: [uWSGI] Memory leak when streaming in psgi (uwsgi 2.0.8)
> Message-ID: <63047a8aca64ee8ecd2ad6b4c639e582@...>
> Content-Type: text/plain; charset=US-ASCII; format=flowed
> 
> Hi,
> 
> Perhaps, I am doing something wrong, but this code:
> 
> ---snip---
> use strict;
> use warnings;
> 
> sub streamer {
>     my $responder = shift;
>     my $writer = $responder->([200, ['Content-Type' => 'text/plain']]);
>     $writer->write("Oops...\n");
>     $writer->close();
> }
> 
> my $app = sub {
>     my $env = shift;
>     return \&streamer;
> };
> ---snip---
> 
> when run as: uwsgi --http-socket :9090 --http-socket-modifier1 5 --psgi 
> psgi-streamer.pl --master --disable-logging
> and tortured with: ab -n1000000 -c64 http://127.0.0.1:9090/
> 
> produces memory leak - ca. 100M consumed after 1 million requests (-c is 
> irrelevant, actually).
> 
> When $writer is not used (i.e. $responder called with content), and also 
> without streaming (just return with content from app), there is no leak.
> 
> uswsgi 2.0.8, compiled on CentOS 7 with "-b psgi" (no Plack::Util 
> installed).
> 
> So, is it me or a bug? :)
> 
> Regards,
> Alexander.
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> uWSGI mailing list
> uWSGI@...
> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
> 
> 
> End of uWSGI Digest, Vol 62, Issue 11
> *************************************

--
Rui Pacheco
rui@...
aldem | 12 Nov 00:28 2014
Picon

Memory leak when streaming in psgi (uwsgi 2.0.8)

Hi,

Perhaps, I am doing something wrong, but this code:

---snip---
use strict;
use warnings;

sub streamer {
     my $responder = shift;
     my $writer = $responder->([200, ['Content-Type' => 'text/plain']]);
     $writer->write("Oops...\n");
     $writer->close();
}

my $app = sub {
     my $env = shift;
     return \&streamer;
};
---snip---

when run as: uwsgi --http-socket :9090 --http-socket-modifier1 5 --psgi 
psgi-streamer.pl --master --disable-logging
and tortured with: ab -n1000000 -c64 http://127.0.0.1:9090/

produces memory leak - ca. 100M consumed after 1 million requests (-c is 
irrelevant, actually).

When $writer is not used (i.e. $responder called with content), and also 
without streaming (just return with content from app), there is no leak.

uswsgi 2.0.8, compiled on CentOS 7 with "-b psgi" (no Plack::Util 
installed).

So, is it me or a bug? :)

Regards,
Alexander.
George Necula | 11 Nov 20:01 2014
Picon

Monitoring utilization of uwsgi workers

Hi,
 
  I would like to monitor in a given time interval (e.g., 1min, 5min, 15min) the utilization of the worker pool. I think that this can be reflected by some moving average of how many tasks are either waiting or being processed (like is done for CPU load in Unix systems). If this average approaches the number of processes I know that I need to do something. 

  Alternatively, I could use a measure of what percentage of the time interval there was an available worker. 

  Note that CPU utilization of the machine is not enough, because some of my tasks have a fair bit of IO.

  I suspect that this can be done with the stats, snmp, or metrics subsystems, but the documentation is very sparse. I see things like "By default uWSGI creates a lot of metrics (and more are planned)" (metrics page). But where are these metrics explained. 

Thanks,
George. 
_______________________________________________
uWSGI mailing list
uWSGI@...
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi

Gmane