You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Tim Tisdall <ti...@gmail.com> on 2012/09/10 04:14:37 UTC
ip_conntrack problems
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
Re: ip_conntrack problems
Posted by Tim Tisdall <ti...@gmail.com>.
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 <ti...@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 <ti...@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
>>>
Re: ip_conntrack problems
Posted by Tim Tisdall <ti...@gmail.com>.
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 <ti...@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
>>
Re: ip_conntrack problems
Posted by Keith Gable <zi...@ignition-project.com>.
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 <ti...@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
>