> 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.
>Add memory-report = true to your options so you will se how much memory it will use (or run ps aux). You could not have hit the RSS limit, but address space, expecially on 64bit, is easy to exhaust. -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
