couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Tisdall <>
Subject Re: ip_conntrack problems
Date Mon, 10 Sep 2012 15:20:24 GMT
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?


On Mon, Sep 10, 2012 at 2:02 PM, Keith Gable <> 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 <> 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= dst= sport=56039
>> dport=5984 packets=7 bytes=429 src= dst= 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

View raw message