uwsgi respawning

1,164 views
Skip to first unread message

Jayadevan M

unread,
Nov 27, 2013, 7:04:23 AM11/27/13
to web...@googlegroups.com
Hi,
I used
https://github.com/web2py/web2py/blob/master/scripts/setup-web2py-nginx-uwsgi-centos64.sh
to set up our environment. Probably because of the setting
reload-on-as = 256,
I see many entries like
"{address space usage: 284729344 bytes/271MB} {rss usage: 22147072 bytes/21MB} [pid: 26452|app: 0|req: 1/3] 198.98.51.23 () {38 vars in 516 bytes} [Wed Nov 27 17:30:45 2013] GET /fastenv => generated 16005 bytes in 415 msecs (HTTP/1.1 404) 7 headers in 343 bytes (1 switches on core 0)
...The work of process 26452 is done. Seeya!
worker 14 killed successfully (pid: 26452)
Respawned uWSGI worker 14 (new pid: 26575)"
Such 'respawning' - is this normal/OK?

Niphlod

unread,
Nov 27, 2013, 2:25:31 PM11/27/13
to web...@googlegroups.com
as long as you indeed want to relaunch any process going upper that limit (that, as every other "template" is a rule of thumb) yes. Alter it if you feel that your app needs more memory

Jayadevan M

unread,
Nov 27, 2013, 11:27:42 PM11/27/13
to web...@googlegroups.com
OK. My real doubt is more about how uwsgi works. It scanned through many files and probably loaded quite a bit of those in memory. When a new process is spawned, will this (buffer) be passed to that? If so, it is better to increase the limit. On the other than hand, if it is some bootstrap process that is taking memory and other processes that come along won't take a lot of memory, I would rather let this die and spawn a new one.


--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to a topic in the Google Groups "web2py-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/web2py/4-bmQ6_iWQQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to web2py+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Roberto De Ioris

unread,
Nov 27, 2013, 11:30:11 PM11/27/13
to web...@googlegroups.com

> OK. My real doubt is more about how uwsgi works. It scanned through many
> files and probably loaded quite a bit of those in memory. When a new
> process is spawned, will this (buffer) be passed to that? If so, it is
> better to increase the limit. On the other than hand, if it is some
> bootstrap process that is taking memory and other processes that come
> along
> won't take a lot of memory, I would rather let this die and spawn a new
> one.


Unless you enable caching or queueing, or other shared memory features,
the memory usage of uWSGI itself is between 800k and 1.8 megs. All of the
other memory is related to the language vm (python) and your app.


What you need to check if the memory usage grows after each request. In
such a case you a have a leak to spot in your app.
--
Roberto De Ioris
http://unbit.it

Jayadevan M

unread,
Nov 27, 2013, 11:44:12 PM11/27/13
to web...@googlegroups.com
In my case, the rss is pretty OK (a 4 GB machine, 12 workers). But address space is high -
{address space usage: 284536832 bytes/271MB} {rss usage: 22073344 bytes/21MB}


Roberto De Ioris

unread,
Nov 27, 2013, 11:50:06 PM11/27/13
to web...@googlegroups.com

> In my case, the rss is pretty OK (a 4 GB machine, 12 workers). But address
> space is high -
> {address space usage: 284536832 bytes/271MB} {rss usage: 22073344
> bytes/21MB}

And why you are worried ? It is virtual memory, i could allocate 2GB of
address space without wasting more than few k of real memory with a simple
mmap() call.

There is nothing wrong in high virtual memory usage, you should only care
about RSS. If you want to limit memory usage on Linux use cgroups (they
are way better and works on real memory and swap)

If you are asking who is mapping that virtual memory, run cat
/proc/<pid>/maps
and you will get the whole memory mapping.

Jayadevan M

unread,
Nov 27, 2013, 11:57:35 PM11/27/13
to web...@googlegroups.com
Oh, OK. Will do. Thank you.


Reply all
Reply to author
Forward
0 new messages