Ouch - what could be taking so much memory? What is address space usage?
*** Stats server enabled on /tmp/web2py.stats.socket fd: 16 ***
mapping worker 1 to CPUs: 0
mapping worker 4 to CPUs: 0
{address space usage: 278118400 bytes/265MB} {rss usage: 24510464
bytes/23MB} [pid: 3391|app: 0|req: 1/1] 192.168.2.3 () {42 vars in 809
bytes} [Wed Nov 27 14:57:35 2013] GET /everest3/default/user/login =>
generated 14415 bytes in 1091 msecs (HTTP/1.1 200) 6 headers in 309 bytes
(1 switches on core 0)
...The work of process 3391 is done. Seeya!
worker 3 killed successfully (pid: 3391)
3391 is taking 23 MB.
On Wed, Nov 27, 2013 at 2:53 PM, Łukasz Mierzwa <[email protected]> wrote:
> Add --memory-report to see rss/vss usage, it's more likely that you hit
> the virtual memory limit (--limit-as)
>
>
> 2013/11/27 Jayadevan Maymala <[email protected]>
>
>> Hi,
>> I don't think it takes that much memory. In fact, it should be at most a
>> few KBs. Please see output form my log -
>> spawned uWSGI worker 3 (pid: 3264, cores: 1)
>> spawned uWSGI worker 4 (pid: 3265, cores: 1)
>> mapping worker 4 to CPUs: 0
>>
>> INFO:web2py.app.sherrpa:192.168.2.3-eeec5900-328c-4ee0-ba45-bcb9f3e67664~s_user_id~1~accessed~user~login~GET~~
>> [pid: 3263|app: 0|req: 1/1] 192.168.2.3 () {42 vars in 719 bytes} [Wed
>> Nov 27 14:48:15 2013] GET /everest3/user/login => generated 64 bytes in
>> 6343 msecs (HTTP/1.1 404) 4 headers in 222 bytes (1 switches on core 0)
>> ...The work of process 3263 is done. Seeya!
>> [pid: 3264|app: 0|req: 1/2] 192.168.2.3 () {42 vars in 673 bytes} [Wed
>> Nov 27 14:48:21 2013] GET /favicon.ico => generated 50 bytes in 2 msecs
>> (HTTP/1.1 400) 3 headers in 116 bytes (1 switches on core 0)
>> ...The work of process 3264 is done. Seeya!
>> [pid: 3262|app: 0|req: 1/3] 192.168.2.3 () {42 vars in 703 bytes} [Wed
>> Nov 27 14:48:21 2013] GET /favicon.ico => generated 50 bytes in 1 msecs
>> (HTTP/1.1 400) 3 headers in 116 bytes (1 switches on core 0)
>> ...The work of process 3262 is done. Seeya!
>> worker 1 killed successfully (pid: 3262)
>> Respawned uWSGI worker 1 (new pid: 3281)
>> worker 2 killed successfully (pid: 3263)
>> Respawned uWSGI worker 2 (new pid: 3282)
>> worker 3 killed successfully (pid: 3264)
>> mapping worker 1 to CPUs: 0
>> mapping worker 2 to CPUs: 1
>> Respawned uWSGI worker 3 (new pid: 3283)
>> mapping worker 3 to CPUs: 2
>>
>>
>> Nothing really happened in between - other than loading a page with a few
>> KBytes.
>>
>>
>>
>> On Wed, Nov 27, 2013 at 2:42 PM, Roberto De Ioris <[email protected]>wrote:
>>
>>>
>>> > Hi,
>>> > I see many entries like this -
>>> > [pid: 3167|app: 0|req: 4/5] 192.168.2.3 () {46 vars in 820 bytes} [Wed
>>> Nov
>>> > 27 14:38:04 2013] GET /everest3/connections/mycxns.load/recommended =>
>>> > generated 985 bytes in 62 msecs (HTTP/1.1 200) 6 headers in 309 bytes
>>> (1
>>> > switches on core 0)
>>> > worker 4 killed successfully (pid: 3162)
>>> > Respawned uWSGI worker 4 (new pid: 3171)
>>> > mapping worker 4 to CPUs: 0
>>> >
>>> > Why are workers getting killed like this?
>>> > My parameters are -
>>> > socket = /var/www/web2py/logs/%n.socket
>>> > pythonpath = /var/www/web2py/
>>> > mount = /=wsgihandler:application
>>> > processes = 4
>>> > master = true
>>> > harakiri = 90
>>> > reload-mercy = 80
>>> > cpu-affinity = 1
>>> > stats = /tmp/%n.stats.socket
>>> > max-requests = 2000
>>> > limit-as = 512
>>> > reload-on-as = 256
>>> > reload-on-rss = 192
>>>
>>> here you ar telling uWSGI to kill workers using more than 192M of RSS
>>> memory, whenever a worker hit the limit it is recycled.
>>>
>>>
>>> --
>>> Roberto De Ioris
>>> http://unbit.it
>>> _______________________________________________
>>> uWSGI mailing list
>>> [email protected]
>>> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
>>>
>>
>>
>> _______________________________________________
>> uWSGI mailing list
>> [email protected]
>> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
>>
>>
>
>
> --
> Łukasz Mierzwa
>
> _______________________________________________
> uWSGI mailing list
> [email protected]
> http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
>
>
_______________________________________________
uWSGI mailing list
[email protected]
http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
