> Hi, i was unable to test sooner because the site went up when you answer. > Now that it went down I add --harakiri-verbose and i fot the following > > *** Starting uWSGI 0.9.9.2 (64bit) on [Tue Oct 18 17:46:42 2011] *** > compiled with version: 4.5.2 on 27 September 2011 19:38:54 > detected binary path: /usr/local/bin/uwsgi > your memory page size is 4096 bytes > *** WARNING: you have enabled harakiri without post buffering. Slow > upload > could be rejected on post-unbuffered webservers *** > shared area mapped at 0x7f9670600000, you can access it with > uwsgi.sharedarea* functions. > uwsgi socket 0 bound to TCP address 127.0.0.1:9001 fd 4 > Python version: 2.7.1+ (r271:86832, Apr 11 2011, 18:37:12) [GCC 4.5.2] > Python main interpreter initialized at 0x24142d0 > your server socket listen backlog is limited to 100 connections > *** Operational MODE: preforking *** > added /opt/web2py/ to pythonpath. > WSGI application 0 (mountpoint=) ready on interpreter 0x24142d0 pid: 16069 > (default app) > *** uWSGI is running in multiple interpreter mode *** > spawned uWSGI master process (pid: 16069) > spawned uWSGI worker 1 (pid: 16076, cores: 1) > spawned uWSGI worker 2 (pid: 16077, cores: 1) > spawned uWSGI worker 3 (pid: 16078, cores: 1) > spawned uWSGI worker 4 (pid: 16079, cores: 1) > *** HARAKIRI ON WORKER 2 (pid: 16077) *** > HARAKIRI: -- syscall> 45 0xb 0x2ecd524 0x10 0x0 0x0 0x0 0x7fffb4588c20 > 0x7f9670202092 > HARAKIRI: -- wchan> sk_wait_data > HARAKIRI: --- uWSGI worker 2 (pid: 16077) WAS managing request / since Tue > Oct 18 17:46:45 2011 --- > DAMN ! worker 2 (pid: 16077) died :( trying respawn ... > Respawned uWSGI worker 2 (new pid: 16080) > >
You can interpret in this way: worker 2 blocked for more than 30 seconds waiting for network data (sk_wait_data). syscall 45 on x86_64 is __NR_recvfrom, with its first argument (the file descriptor/socket) being the 11 (0xb). So: the worker is waiting for data from socket 11, but those data did not come. Who is socket 11 ? it could be a database connection (check your db logs) or an external server connection. For sure it cannot be the uwsgi socket (being it very low in number, normally the 3). You can get the list of descriptors with ls -l /proc/<pid>/fd check for 11, you should get a number for the socket, then you can do lsof | grep <number> But i suppose you know to who your app connect to :) -- Roberto De Ioris http://unbit.it _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
