If anyone else comes across this, this seemed to help:

iptables -t raw -A PREROUTING -i lo -j NOTRACK
iptables -t raw -A OUTPUT -o lo -j NOTRACK

On top of already having a rule for "-A INPUT -i lo -j ACCEPT" and "-A
OUTPUT -j ACCEPT".  This way ip_conntrack isn't involved when making
connections to couchdb on the loopback connection.  I was making many
rapid connections and quickly using up all the space in the hash
tables for ip_conntrack.

-Tim

On Mon, Sep 10, 2012 at 3:20 PM, Tim Tisdall <tisd...@gmail.com> wrote:
> 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 <zi...@ignition-project.com> 
> 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 <tisd...@gmail.com> 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
>>>

Reply via email to