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
