incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Tisdall <tisd...@gmail.com>
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?

-Tim

On Mon, Sep 10, 2012 at 2:02 PM, Keith Gable <ziggy@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 <tisdall@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
>>

Mime
View raw message