No. It's a cron script that I've been using for a while now. PHP is reporting that fclose() is properly closing the connections, but the fact that /proc/sys/net/ipv4/netfilter/ip_conntrack_count seems to grow rapidly when the script is running seems to indicate otherwise.
I recently did an update on PHP and so I suspect this is some bug that got introduced by that update. Anyone else using PHP with couchdb and notice similar problems after upgrading to PHP 5.3.16? -Tim On Mon, Sep 10, 2012 at 2:02 PM, Keith Gable <[email protected]> wrote: > Is there a similar increase in HTTP requests? It sounds to me that your web > server is executing your PHP script, which is making requests into CouchDB. > So an increase in requests would result in an increase of CouchDB requests. > > --- > Keith Gable > A+ Certified Professional > Network+ Certified Professional > Storage+ Certified Professional > Mobile Application Developer / Web Developer > > > > On Sun, Sep 9, 2012 at 9:14 PM, Tim Tisdall <[email protected]> wrote: > >> I'm using iptables on my system to block external access to everything >> except for explicit ports (http, https, ssh, etc). I'm not sure how, >> but I'm getting “nf_conntrack: table full, dropping packet.” and “TCP: >> time wait bucket table overflow” because the number of connections is >> past the maximum trackable. By listing the connections in >> /proc/net/ip_conntrack I can see a wack of entries that look like the >> following: >> >> tcp 6 54 TIME_WAIT src=127.0.0.1 dst=127.0.0.1 sport=56039 >> dport=5984 packets=7 bytes=429 src=127.0.0.1 dst=127.0.0.1 sport=5984 >> dport=56039 packets=7 bytes=19476 [ASSURED] mark=0 secmark=0 use=2 >> >> I see that it's using port 5984 which is what couchdb is on, but I'm >> not sure why this is occurring. I'm using PHP with the fsockopen() >> method described in the wiki and I do have a script running that's >> making updates to the db. However, PHP isn't multi-threaded and I'm >> making calls through the fsockopen and then closing the connection >> immediately afterwards. Does anyone know what's causing this to >> occur? Or maybe where to look further to figure this out? >> >> -Tim >>
