netfilter.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marco Padovan <evcz@evcz.tk>
Cc: netfilter@vger.kernel.org
Subject: Re: Conntrack & Unreplied exhausts hashsize
Date: Sat, 09 Jun 2012 20:15:53 +0200	[thread overview]
Message-ID: <4FD392D9.9010706@evcz.tk> (raw)
In-Reply-To: <f8da378bd8c865bf9618b0d52f7b4441@njm.linuxwall.info>

Looks like it's an intendend behaviour:

http://www.netfilter.org/documentation/FAQ/netfilter-faq-3.html#ss3.17

<<UNREPLIED entries are temporary entries, i.e. as soon as we run out of
connection tracking entries (we reach
/proc/sys/net/ipv4/ip_conntrack_max), we delete old UNREPLIED entries.
In other words: instead of having empty conntrack entries, we'd rather
keep some maybe useful information in them until we really need them.>>

when having the conntrack table full "error" did you still have
unreplied entries in the table?

Il 09/06/2012 17:12, Julien Vehent ha scritto:
> Hi everyone,
>
> I'm analyzing a configuration problem that we are encountering with
> conntrack at work. We have a farm of frontend servers that run apache.
> Those servers run into the classical table full problem:
>
>     Jun 5 09:57:51 web-front1 kernel: [7177214.445925] nf_conntrack:
> table full, dropping packet.
>
> So I started tuning the kernel of one member of the farm. This server
> has 2 interfaces: one public and one in the LAN. The problem is on the
> public interface, it seems that connections in the UNREPLIED state
> continue to grow and never get cleaned up by conntrack. Below is a
> diagram that shows the issue:
>
> http://4u.1nw.eu/conntrack_stat3.png
>
> The orange line counts connections on the public IP that are in the
> unreplied state. The script parses /etc/net/ip_conntrack every 10
> minutes (nothing fancy, see https://gist.github.com/2901349 ).
>
> My questions are:
>
> Should these UNREPLIED connection get removed from conntrack after a
> certain timeout?
>
> What is the parameter that controls this timeout ?
> I'm afraid it might be
> `net.netfilter.nf_conntrack_tcp_timeout_established = 432000`, which
> is 5 days. If this is the case, would it be safe to set this parameter
> to 300 seconds instead (5 minutes) ?
>
> Note: apache runs with `KeepAlive On` and `KeepAliveTimeout 3`, in
> case this might be relevant.
>
>
> Thanks a lot,
> Julien
>
>



  reply	other threads:[~2012-06-09 18:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-09 15:12 Conntrack & Unreplied exhausts hashsize Julien Vehent
2012-06-09 18:15 ` Marco Padovan [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-06-09 20:15 Fwd: " Julien Vehent
2012-06-12 11:22 ` Julien Vehent
2012-06-16 19:39   ` Pablo Neira Ayuso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FD392D9.9010706@evcz.tk \
    --to=evcz@evcz.tk \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).