exactly. My partner got this error, and then googled, and then we reached the above parameter.
Actually the story like this: 1. user said slow, slow, slow 2. nginx flooded with "upstream connection timed out" 3. I checked uwsgi log, found some of errors, fixed it; found more, fix more, and this loop lasted days. Till yesterday, I thought there was no relevance with uwsgi, memcached, db, redis, or anything backend because uwsgi were idle 4. so I thought nginx must have had something wrong, reload, restart, check connections, workers, proxy_read_timeout, etc. no luck. 5. checked ulimit -n, which reported 1024, the default one. I have 8 nginx workers, so connections should reach to 1024 * 8, I thought that could be ok as nginx never said too many open files. Anyway, I changed it to 4096. NO luck. 6. check connections number, and the state, then problem appears. upstream connections were all in syn_sent state, then timeout happends. Only 2 or 3 of 300 connections are in established state. We wanted to know why. One of my friends told my part to use tcpdump, the magic tool I never dare to try once. 7. Then we go to syslog and found the following error, and finally we resolved the problem we felt very happy, and we know knowledge is so important. Thanks for all your helps and suggestions, and I'll try my best to bring uwsgi into China, where I can hardly find a uwsgi user. On Wed, Nov 14, 2012 at 11:40 PM, Aarni Koskela <[email protected] > wrote: > Btw: Did you also happen to get “kernel: ip_conntrack: table full, > dropping packet.” in the syslog while this happened?**** > > -- *吴焱红(Samuel)* 博客: blog.shanbay.com
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
