Linuxカーネルパラメータ変更時の注意点

  • URLをコピーしました!

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:性能が上がるとは限らない

よくある誤解として、

「数値を大きくすれば速くなる」

があります。

実際には、

  • メモリ消費増加
  • スケジューリング遅延
  • キュー滞留

など、逆効果になるケースも多いです。

安全な変更手順(実務テンプレ)

  1. 現状値を確認・記録
  2. 変更目的を明確化
  3. 一時変更で検証
  4. 影響指標(CPU/I/O/通信)を確認
  5. 問題なければ永続化

変更後に必ず確認すべきポイント

  • 通信エラーが増えていないか
  • dmesg に警告が出ていないか
  • レスポンスが悪化していないか
dmesg | tail
ss -s
vmstat 1

よくある事故パターン

  • 意味を理解せずコピペ適用
  • 本番で直接永続変更
  • 変更履歴を残していない

「正しく変更できた」と判断する基準

  • 変更目的に沿った改善が見える
  • 副作用(エラー・遅延)が出ていない
  • 再起動後も安定している

まとめ

  • カーネルパラメータは強力だが危険
  • 一時変更 → 検証 → 永続化が鉄則
  • 「戻せる状態」を必ず作る

Linux のカーネルパラメータ変更は、

「調整」ではなく「設計変更」

という意識で扱うことが、事故を防ぐ最大のポイントです。

目次