時間経過によるプロキシの遅延：conntrack とリソース上限を確認する

プロキシは再起動直後には応答する。数時間後、新しい接続が止まる。もう一度再起動すれば、また静かな時間が稼げる。このパターンは状態の蓄積を示すが、どの状態が原因かは特定しない。

接続追跡を使う Linux の経路では、候補の一つが conntrack テーブルである。マシン上と、通信を処理するネットワーク名前空間で、既存の次の値を確認する:

/proc/sys/net/netfilter/nf_conntrack_count
/proc/sys/net/netfilter/nf_conntrack_max

前者は割り当て済みのフローエントリを報告し、後者はその上限を定める。これは Squid の利用者数でも HTTP リクエスト数でもない。カーネルのフロー状態は、アプリケーションの稼働中の処理より長く残ることがある。

大きな数値だけでなく関係を見る

時間経過に伴う占有率を、新規接続の失敗の発生と関連するカーネルメッセージと比較する。対応する障害の証拠がない高い数値は、リクエストがタイムアウトし始めたまさにその時に何度も上限に達するテーブルとは異なる。

テーブルはプロキシ以外にも使われる。他のローカルサービス、転送トラフィック、別の混雑したネットワーク経路も寄与しうる。プロキシの再起動で症状が変わることは、Squid のオブジェクトキャッシュが原因だった証拠にはならない。

競合する説明を視野に入れておく: ファイルディスクリプタ、認証ヘルパーの待ち行列、DNS の遅延、メモリの逼迫、満杯のファイルシステムも時間とともに悪化しうる。どのリソースが増え、どの操作が最初に動かなくなるかを記録する。長命な接続が生き残り新規接続が失敗することは有用な証拠だが、それ自体は診断ではない。

上限を上げるにはメモリのコストがかかる。変更する前に、ワークロード、名前空間、利用可能な容量を確定する。タイムアウトを無差別に短縮すると有用なアイドルセッションを壊しうるし、接続状態をすべて消すと無関係な通信を乱しうる。

有用な成果は、蓄積の説明と、それに合う容量またはライフサイクルの変更である。安全に上げられるかどうかは、どのプロキシサーバーにも当てはまる性質ではない。