netfilterのconntrack_maxとhash sizeの関係

netfilterに片足を突っ込んでしまってから、あまり気にかからないところが気になるようになってしまいました。墓穴を掘り続ける日々が続いています。

今回はconntrack_maxとhash size(conntrack_buckets)の関係についてです。

先に書いておきます。メモリ容量から逆算するconntrack_maxとhash sizeの計算公式はココに書いてあります。チューニングの推奨値とは別の疑問です。

conntrackテーブルにある[ASSURED]の数が実質の上限数を左右するところまでは、なんとなくつかんでいたんですが、負荷の高いGWでもピークで1万本程度と、限界値となるパラメータの設定値についてあまり気にしていませんでした。

疑問を持ったきっかけは、今週うっかりapサーバが[ASSURED]なconntrackテーブルを10万本もっていることに気づいてしまったことです。
大半がnginx->apacheのローカルホストからローカルホストへのリバースプロクシのconntrackテーブルでした。

apサーバはpuppetを通るとconntrack_maxを、特に何も考えずに524288に設定されるようになっているのですが、ぐぐったらすぐに出てくる某所に書いてあるconntrack_max / 8だと65536でドロップが出るはずですが、まったくでていません。

なんとなく調べた結果は以下のような感じです。

・conntrack_max / 8 は最初に書いたwikiにあるように、hash sizeの推奨値であって、上限値ではない。
・あくまでconntrack_maxの値が上限値。

ヒントはnetfilterのソース読んだり、よく分からないwikiでみつけたのですが、大量に保持しているconntrackテーブルに対して、hash size(conntrack_buckets)はconntrackテーブルをハッシュ化してすばやく検索できるようにするもの(?)といった感じです。
conntrack_maxだけでかくしても問題ないけど、検索するためのハッシュ領域が少なすぎて効率が悪いという内容みたいですね。

iptablesでゴリゴリFWしている場合は、conntrackテーブルを活用したほうが効率がいいはずですが、gwでマスカレードだけしてるとか、apサーバではそもそもconntrackテーブルを大量にを保持するだけCPUとメモリの無駄になっているかもしれません。

conntrackのタイムアウトを短めにしてCPUとメモリを節約したほうがパフォーマンスがよくなるかもしれませんね。
もう少し調べないとだめです。

コメントを残す

メールアドレスが公開されることはありません。


*