Linux のチューニングやトラブル対応で、
- sysctl を変更した
- /etc/sysctl.conf を編集した
- net.ipv4 や vm.* を調整した
という経験は多いと思います。
一方で、
- 変更後に通信が不安定になった
- なぜか再起動後に元に戻った
- 逆に性能が悪化した
という事故も非常によく起きます。
これは カーネルパラメータの変更が「即時影響・広範囲影響・不可視影響」を持つ ためです。
本記事では、
- カーネルパラメータ変更時の基本的な考え方
- よくある事故パターン
- 安全に変更するための確認手順
- 変更が成功したと判断する基準
を、実務視点で整理します。
目次
まず理解する:カーネルパラメータ変更の特徴
Linux のカーネルパラメータは、
- OS全体に影響する
- 即座に反映されるものが多い
- 元に戻しにくい事故もある
という特徴があります。
そのため、
「とりあえず変えて様子を見る」
は非常に危険です。
注意点1:そのパラメータは「一時変更」か「永続変更」か
一時変更
sysctl -w net.ipv4.tcp_fin_timeout=30
再起動すると元に戻ります。
永続変更
/etc/sysctl.conf
/etc/sysctl.d/*.conf
永続化は影響範囲が格段に大きいため、必ず検証後に行います。
注意点2:変更前の現在値を必ず控える
変更前に以下を必ず確認します。
sysctl net.ipv4.tcp_fin_timeout
異常時に戻せることが、最大の保険です。
注意点3:関連パラメータをセットで考える
カーネルパラメータは、単体では意味を持たないことが多いです。
例:TCP系
- net.ipv4.tcp_max_syn_backlog
- net.ipv4.tcp_synack_retries
- net.core.somaxconn
1つだけ変更すると、逆に詰まりやすくなることがあります。
注意点4:ネットワーク系パラメータは即影響が出る
以下は特に注意が必要です。
- tcp_tw_reuse / tcp_tw_recycle
- rp_filter
- tcp_keepalive_* 系
通信断・片方向通信・接続不可など、即障害に直結します。
注意点5:性能が上がるとは限らない
よくある誤解として、
「数値を大きくすれば速くなる」
があります。
実際には、
- メモリ消費増加
- スケジューリング遅延
- キュー滞留
など、逆効果になるケースも多いです。
安全な変更手順(実務テンプレ)
- 現状値を確認・記録
- 変更目的を明確化
- 一時変更で検証
- 影響指標(CPU/I/O/通信)を確認
- 問題なければ永続化
変更後に必ず確認すべきポイント
- 通信エラーが増えていないか
- dmesg に警告が出ていないか
- レスポンスが悪化していないか
dmesg | tail
ss -s
vmstat 1
よくある事故パターン
- 意味を理解せずコピペ適用
- 本番で直接永続変更
- 変更履歴を残していない
「正しく変更できた」と判断する基準
- 変更目的に沿った改善が見える
- 副作用(エラー・遅延)が出ていない
- 再起動後も安定している
まとめ
- カーネルパラメータは強力だが危険
- 一時変更 → 検証 → 永続化が鉄則
- 「戻せる状態」を必ず作る
Linux のカーネルパラメータ変更は、
「調整」ではなく「設計変更」
という意識で扱うことが、事故を防ぐ最大のポイントです。
