Comment 2 for bug 1441363

I strongly disagree with the first part of this recommendation. Disabling conntrack in modern Linux is essentially an old hack devised for old Linux to improve performance on extremely busy servers which are dedicated to a single, dumb task from a networking perspective. It's not necessary and definitely not the Right™ way to solve the problem.

I also dislike the idea of removing conntrack/lxc* as it reduces the deployment and expansion flexibility of an object server, which is definitely not aligned with the goals of this project architecture.

You have a few simple options here:

A) If you have lots of TW connections lingering and you're running into the nf_conntrack_max or running out of available sockets, set the tcp_tw_reuse sysctl (as suggested in the second part of this recommendation) in order to allow the kernel to reclaim sockets in TW when it's safe to do so per the protocol. I should note that this is *only* safe to do so when conntrack *is* enabled, because a reused TW port-pair has the potential to still receive late traffic and conntrack is the mechanism which recognizes that traffic as INVALID and drops it appropriately. Not having conntrack on while also reusing TWs can cause actual data crossover from old, closing connections into new sockets, eventually.

B) Up the conntrack limit

C) Set the tcp_tw_recycle sysctl, if you *really* need aggressive connection closing. This can confuse or utterly break the remote ends of connections, so it's not recommended unless these boxes are so incredibly busy they're utterly buckling under the speed of connections/sec, in which case this still really isn't the right solution -- the right solution is to load-balance and scale the architecture appropriately.

My recommendation is A, and B if also necessary if-and-only-if there are enough valid, active connections that even reusing TW sockets hits the conntrack limit. I strongly advise against C in almost any circumstance, and certainly in this one.