Linuxカーネルパラメータ（sysctl）のチューニング方法

Linuxのsysctlチューニングは、サーバーの挙動を細かく調整できる一方で、理解せずに数値だけ真似すると逆効果になりやすい。特にネットワーク、メモリ、ファイルディスクリプタ、カーネル保護機能まわりは、用途によって正解が大きく変わる。重要なのは「有名な設定を全部入れる」ことではなく、現状を確認し、ボトルネックや目的に応じて、必要な項目だけを変更すること。この記事では、sysctlの基本、設定の確認方法、一時反映と永続化、よく触られる代表項目、やってはいけない変更までを順番に整理する。

sysctlとは何か

sysctlは、Linuxカーネルの動作に関するパラメータを実行中に参照・変更するための仕組み。
対象となる値は主に /proc/sys 配下にあり、たとえばネットワーク、仮想メモリ、カーネルメッセージ、セキュリティ関連などの設定が含まれる。
つまり、カーネル再コンパイルや再起動なしで、挙動の一部を動的に調整できる。

最初に理解しておくべきこと

sysctlチューニングで大事なのは、次の3点。
・一時変更と永続変更は別
・パラメータごとに効果も副作用も違う
・ワークロードに合わない設定は性能や安定性を落とす
特に、Webサーバー向けの設定、DBサーバー向けの設定、コンテナホスト向けの設定では、優先する値が変わりやすい。
「高速化」と書かれた設定をそのまま貼るのではなく、今のサーバーで何を改善したいかを先に決めた方が失敗しにくい。

現在の値を確認する方法

まずは現在値を確認する。
最も基本的なのは sysctl コマンドを使う方法。

sysctl net.ipv4.ip_forward

複数まとめて確認することもできる。

sysctl vm.swappiness
sysctl fs.file-max
sysctl net.core.somaxconn

また、/proc/sys を直接見る方法もある。

cat /proc/sys/vm/swappiness
cat /proc/sys/fs/file-max
cat /proc/sys/net/core/somaxconn

sysctl のドット区切りは、/proc/sys ではスラッシュ区切りに対応していると考えると分かりやすい。

一時的に変更する方法

まず試験的に変更したいときは、一時反映で十分なことが多い。
一時変更は再起動すると戻る。

sudo sysctl -w vm.swappiness=10

または /proc/sys へ直接書くこともできる。

echo 10 | sudo tee /proc/sys/vm/swappiness

この方法は、効果をすぐ見たいときや、設定前後でベンチマークを比較したいときに向いている。
ただし、再起動後も残したい設定なら別途永続化が必要になる。

永続化する方法

継続利用したい設定は、設定ファイルへ記述して永続化する。
一般的には /etc/sysctl.conf か /etc/sysctl.d/ 配下のファイルを使う。

sudo nano /etc/sysctl.d/99-custom.conf

たとえば次のように書く。

vm.swappiness = 10
fs.file-max = 2097152
net.core.somaxconn = 4096

書いたあとに反映する。

sudo sysctl –system

または、個別ファイルを指定して読み込むこともできる。

sudo sysctl -p /etc/sysctl.d/99-custom.conf

本番運用では、/etc/sysctl.d/ に用途別ファイルを分けた方が管理しやすいことが多い。

設定ファイルの置き場所をどう使い分けるか

小規模環境では /etc/sysctl.conf にまとめてもよいが、実務では /etc/sysctl.d/99-custom.conf のように個別ファイルへ切り出す方が分かりやすい。
理由は次の通り。
・用途ごとに整理しやすい
・どの設定を追加したか追いやすい
・構成管理ツールと相性が良い
・OS標準設定との差分が見やすい
たとえば、
・50-network-tuning.conf
・60-memory-tuning.conf
のように分けると、後から読み返しやすい。

ネットワーク系でよく見る項目

sysctlで最もよく話題になるのがネットワーク系。
代表例としては次のようなものがある。
・net.core.somaxconn
・net.ipv4.tcp_fin_timeout
・net.ipv4.tcp_tw_reuse
・net.ipv4.ip_local_port_range
・net.ipv4.tcp_max_syn_backlog
ただし、ここは「有名だから設定する」が最も危険になりやすい領域。
たとえば接続数の多いサーバーでは有効なこともあるが、アプリ側の accept キューやロードバランサ設定と噛み合っていなければ期待通りに効かないこともある。

設定例。

net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 4096

ただし、これだけで性能が上がるわけではなく、アプリやWebサーバー側の設定も合わせて確認する必要がある。

メモリ系でよく見る項目

メモリまわりでは vm.* 系がよく使われる。
その中でも頻繁に触られるのが vm.swappiness。
これはswapの使い方の傾向に影響する項目として扱われることが多い。

vm.swappiness = 10

一般的に、swapを極力抑えたい用途で値を下げることがあるが、必ず低ければ良いとは限らない。
メモリが逼迫しやすい環境や、逆にキャッシュ活用を重視したい環境では、バランスの取り方が変わる。
単に「0にすれば速い」と考えるのは危険で、swap戦略全体の一部として扱う方がよい。

ファイルディスクリプタ系でよく見る項目

大量接続や大量ファイルを扱うサーバーでは、ファイルディスクリプタ数も重要。
sysctlでは fs.file-max が全体上限の目安として使われることが多い。

sysctl fs.file-max

永続化例。

fs.file-max = 2097152

ただし、これを増やしても、
・systemd
・ulimit
・アプリ側設定
が追従していなければ実効上限は変わらないことがある。
そのため、sysctlだけ直して「増えたはずなのに足りない」となるケースは多い。

カーネルメッセージやセキュリティ系の項目

sysctlには性能だけでなく、セキュリティやカーネル動作保護に関わる項目も多い。
代表例としては次のようなものがある。
・kernel.dmesg_restrict
・kernel.kptr_restrict
・net.ipv4.conf.all.rp_filter
・net.ipv4.conf.default.rp_filter
こうした値は、性能向上目的ではなく、情報露出防止や不正なパケット制御に関わることがある。
性能目的の記事だけを見て sysctl を触ると、こうした保護系の意味を見落としやすい。

変更前後で比較する習慣を持つ

sysctlチューニングは、変更したこと自体より「本当に改善したか」を確認する方が重要。
そのため、変更前後で次のようなものを比較すると判断しやすい。
・レスポンスタイム
・接続数
・エラー率
・ロードアベレージ
・CPU使用率
・メモリ使用量
・I/O待ち
単に設定しただけで満足すると、実は性能が変わっていない、あるいは悪化しているケースも見逃しやすい。

反映後の確認方法

反映後は、値が本当に変わっているかを必ず確認する。

sysctl vm.swappiness
sysctl fs.file-max
sysctl net.core.somaxconn

または、ファイル側でも見られる。

cat /proc/sys/vm/swappiness
cat /proc/sys/fs/file-max
cat /proc/sys/net/core/somaxconn

「設定ファイルへ書いた」ことと「反映された」ことは別なので、確認を省かない方がよい。
特に sysctl --system 実行時にエラーが出ていると、一部だけ反映されていないこともある。

よくある失敗とやってはいけないこと

sysctlチューニングでよくある失敗はかなり典型的。
・意味を理解せず有名設定を丸ごと貼る
・本番でいきなり変更する
・変更前後の比較をしない
・一時変更で直ったのに永続化し忘れる
・永続化したが、再起動後に別設定で上書きされる
・古い記事の設定をそのまま使う
・ネットワーク性能改善のつもりでセキュリティ設定を崩す
とくに危険なのは、昔よく見かけた設定をそのまま流用すること。
カーネルバージョンや運用形態が違うと、推奨されにくい値もある。

設定を戻す方法も最初に考える

変更は戻せるようにしておく方が安全。
一時変更なら元の値へ再設定すればよい。

sudo sysctl -w vm.swappiness=60

永続設定なら、該当ファイルを修正または削除して再読み込みする。

sudo rm /etc/sysctl.d/99-custom.conf
sudo sysctl –system

本番では、変更前の値をメモしておく、設定ファイルをバックアップする、といった基本も重要。
戻し方が分からないまま本番へ入れるのは避けた方がよい。

実務で進めやすいチューニング手順

sysctlを実務で触るなら、次の順番がかなり進めやすい。

1. 現在値を確認する
2. 何を改善したいかを決める
3. まず一時変更で試す
4. 変更前後でメトリクス比較する
5. 効果があるものだけ永続化する
6. 設定ファイルへコメントを残す
   たとえば、こんな形でコメントを残すと後で読みやすい。

#Reduce swap aggressiveness for web workload
vm.swappiness = 10

#Increase accept queue limit for high connection load
net.core.somaxconn = 4096

コメントがあるだけで、「なぜこの値にしたのか」がかなり追いやすくなる。

まとめ

Linuxカーネルパラメータ（sysctl）のチューニングでは、
・現在値を確認する
・一時変更で試す
・効果を比較する
・必要なものだけ永続化する
という流れで進めるのが基本になる。
よく使われるのは、
・ネットワーク系
・メモリ系
・ファイルディスクリプタ系
だが、どれも「有名だから入れる」ではなく、サーバーの用途と症状に合わせて決める方が安全。
sysctlは強力な反面、雑に触ると性能悪化や安定性低下にもつながるため、変更理由と戻し方をセットで持ちながら進めることが重要になる。