Squid の実際のファイルディスクリプタ上限を突き止める
PAM 設定を変更したり、容量レシピから固定の nofile 値をコピーしたりする前に、稼働中のプロキシのプロセス上限を読み取ります。
ログインシェルの ulimit -n を信じる前に、稼働中のデーモンを調べます。squid.service を使うインストールでは、まず次を実行します。
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.service実際のプロセス ID を使って /proc/PID/limits を読みます。マルチプロセス構成では、該当するワーカーも確認します。設定ファイルに保存された値は、このプロセスがそれを継承した証拠にはなりません。
| 制御 | 範囲 |
|---|---|
シェル ulimit と PAM limits.conf | シェルの子孫、または PAM 設定を実際に使うセッション |
systemd LimitNOFILE= | そのサービスのリソースポリシー下で起動されたプロセス |
Squid max_filedescriptors（対応している場合） | オペレーティングシステムの制約内でのアプリケーション上限 |
管理者がファイルを変更したというだけで、システムサービスが PAM の編集を取り込むわけではありません。systemd の上限を変えるのが適切な場合は、サービス固有の drop-in を使います。Squid の文書によれば、max_filedescriptors の変更には再起動が必要です。未設定のままにすると OS のソフト上限を継承します。
上限はユーザー数ではなくディスクリプタ数で見積もります。クライアントは複数のソケットを保持でき、外向き接続、ログ、ヘルパーパイプもディスクリプタを消費します。上限を上げれば、起こりうるディスクリプタごとに固定の RAM を即座に確保することなく、より多くの消費を許せます。ソケットあたりの古いメモリ見積もりも 65,535 も、万能の容量要件でも Linux の天井でもありません。
サービス変更後は、新しいプロセスの上限を意図した値と比較します。そのはるか下で障害が起きるなら、実際に枯渇しているリソースを調べます。