Just remove this limit if you are not sure what it means, rss limit alone is good enough.
2013/11/27 Jayadevan Maymala <[email protected]> > 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 > > -- Łukasz Mierzwa
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
