Linuxカーネルチューニング入門｜sysctl・パラメータ調整でサーバー性能を最適化

「サーバーのレスポンスが遅い」「アクセスが集中すると処理が追いつかない」――中小企業のIT担当者であれば、こうした悩みに直面したことがあるのではないでしょうか。ハードウェアの増強はコストがかかりますが、Linuxカーネルのチューニングによって、既存のサーバーリソースを最大限に活用できる可能性があります。

本記事では、Linuxカーネルチューニングの基礎知識から、sysctlを用いた具体的なパラメータ調整の方法まで、実務で使える内容を体系的に解説します。初めてカーネルチューニングに取り組むエンジニアの方にもわかりやすいよう、ステップバイステップで進めていきます。

Linuxの基本をまだ押さえていない方は、まずLinuxとは？初心者向け基礎解説をご覧ください。

Linuxカーネルチューニングとは？基本概念を理解する

Linuxカーネルは、OSの中核を担うソフトウェアです。ハードウェアとアプリケーションの間で、メモリ管理、プロセススケジューリング、ネットワーク通信、ファイルシステムの制御など、あらゆる処理を担当しています。

カーネルチューニングとは、このカーネルの動作を制御するパラメータ（カーネルパラメータ）を調整し、特定のワークロードに合わせてサーバー性能を最適化することです。

なぜカーネルチューニングが必要なのか

Linuxカーネルのデフォルト設定は、幅広い用途に対応するための汎用的なものです。しかし、実際のサーバー運用では用途が明確に定まっていることが多いため、用途に合わせたチューニングが有効になります。

Webサーバー: 同時接続数が多い場合、ネットワーク関連のパラメータ調整が効果的
データベースサーバー: メモリやディスクI/O関連のパラメータが重要
アプリケーションサーバー: プロセス管理やスケジューリングの最適化が効く
ファイルサーバー: ファイルシステムやキャッシュの設定が性能に直結

特に中小企業では、限られたサーバーリソースの中で最大限のパフォーマンスを引き出すことが重要です。ハードウェア増強の前に、まずカーネルチューニングで改善できる余地がないか検討することをおすすめします。

カーネルパラメータの仕組み

Linuxカーネルのパラメータは、/proc/sys/ディレクトリ配下に仮想ファイルとして公開されています。このディレクトリ構造は以下のように分類されています。

/proc/sys/kernel/: カーネル全般の設定
/proc/sys/net/: ネットワーク関連の設定
/proc/sys/vm/: 仮想メモリ関連の設定
/proc/sys/fs/: ファイルシステム関連の設定

これらのパラメータは、sysctlコマンドを使って確認・変更できます。Linuxのディレクトリ構造について詳しくは、Linuxディレクトリ構造ガイドを参照してください。

sysctlコマンドの基本的な使い方

sysctlは、カーネルパラメータをランタイムで確認・変更するためのコマンドです。まずは基本的な操作方法を押さえましょう。

現在の設定値を確認する

全パラメータを一覧表示するには、以下のコマンドを実行します。

# すべてのカーネルパラメータを表示
sysctl -a

# 特定のパラメータを確認
sysctl net.ipv4.tcp_max_syn_backlog

# キーワードで絞り込み
sysctl -a | grep tcp_max

パラメータの数は数百〜数千にのぼるため、目的のパラメータを特定するためにgrepと組み合わせて使うのが実務では一般的です。コマンドの組み合わせ方はLinux実践コマンドガイドでも詳しく解説しています。

パラメータを一時的に変更する

sysctlコマンドでパラメータを変更すると、即座に反映されます。ただし、この変更は再起動すると元に戻る一時的なものです。

# 一時的にパラメータを変更
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=4096

# 変更を確認
sysctl net.ipv4.tcp_max_syn_backlog

一時的な変更はテスト時に便利です。効果を確認してから永続化する運用がおすすめです。

パラメータを永続化する

再起動後も設定を維持するには、/etc/sysctl.confまたは/etc/sysctl.d/ディレクトリ内の設定ファイルに記述します。

# /etc/sysctl.d/99-custom.conf を作成
sudo vi /etc/sysctl.d/99-custom.conf

# 以下の内容を記述
net.ipv4.tcp_max_syn_backlog = 4096
net.core.somaxconn = 4096

# 設定を即座に反映
sudo sysctl -p /etc/sysctl.d/99-custom.conf

/etc/sysctl.d/ディレクトリに個別の設定ファイルを置く方法が推奨されています。ファイル名の先頭に数字を付けることで読み込み順序を制御できます。テキストエディタの使い方はVim入門チュートリアルを参考にしてください。

ネットワーク関連のチューニングパラメータ

Webサーバーやアプリケーションサーバーを運用する場合、ネットワーク関連のチューニングが最も効果的なケースが多いです。ここでは、代表的なパラメータとその調整方法を解説します。

TCP接続のバックログ設定

同時接続数が多いサーバーでは、TCP接続のバックログ（待ち行列）の上限が重要です。

# SYN受信時のバックログキューの最大長
net.ipv4.tcp_max_syn_backlog = 4096

# listenソケットのバックログの最大値
net.core.somaxconn = 4096

tcp_max_syn_backlogはTCPハンドシェイク中の半開き接続の上限、somaxconnはlistenシステムコール時に指定できるバックログの最大値です。アクセスが集中するサーバーでは、デフォルト値（128〜1024程度）では不足するケースがあります。

TCP接続の再利用とタイムアウト

短時間で大量の接続が発生する環境では、TIME_WAIT状態のソケットが大量に溜まり、新しい接続が確立できなくなることがあります。

# TIME_WAITソケットの再利用を有効化
net.ipv4.tcp_tw_reuse = 1

# FINタイムアウトの短縮（デフォルト60秒）
net.ipv4.tcp_fin_timeout = 30

# キープアライブの間隔調整
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 60
net.ipv4.tcp_keepalive_probes = 5

注意点として、tcp_tw_reuseはクライアント側（接続を開始する側）でのみ有効です。また、NATを使用している環境では副作用が生じる可能性があるため、適用前にテストを行ってください。

ネットワークバッファの調整

ネットワーク帯域幅が広い環境や、大量のデータを転送する場合は、バッファサイズの調整が有効です。

# TCP受信バッファ（最小・デフォルト・最大）
net.ipv4.tcp_rmem = 4096 87380 16777216

# TCP送信バッファ（最小・デフォルト・最大）
net.ipv4.tcp_wmem = 4096 65536 16777216

# コア層の受信/送信バッファ最大値
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

バッファサイズを大きくしすぎるとメモリ消費量が増加するため、サーバーの搭載メモリ量とのバランスを考慮して設定します。ネットワーク関連のコマンドはLinuxネットワークコマンドも併せて参照してください。

メモリ・仮想メモリ関連のチューニング

メモリ管理の最適化は、データベースサーバーやキャッシュサーバーなど、メモリを大量に使用するワークロードで特に効果を発揮します。

スワップの制御（vm.swappiness）

vm.swappinessは、カーネルがどの程度積極的にスワップを使用するかを制御するパラメータです。値は0〜100で設定します。

# デフォルト値の確認
sysctl vm.swappiness

# データベースサーバー向け（スワップを抑制）
sudo sysctl -w vm.swappiness=10

# メモリに余裕がある場合（スワップをほぼ使わない）
sudo sysctl -w vm.swappiness=1

値が高い（60〜100）: 積極的にスワップを使用。メモリを他の用途に開放しやすい
値が低い（1〜10）: できるだけ物理メモリを使用。スワップによるI/O遅延を抑制
値が0: スワップを完全に無効化するわけではない。メモリ不足時にはスワップが発生する

データベースサーバーでは、スワップによる性能劣化が大きいため、10以下に設定するのが一般的です。

ページキャッシュの制御

ファイルI/Oが多いワークロードでは、ページキャッシュ（ディスクデータのメモリキャッシュ）の制御が重要です。

# ダーティページの割合（メモリ全体に対するパーセンテージ）
vm.dirty_ratio = 20

# バックグラウンドでの書き出しを開始する閾値
vm.dirty_background_ratio = 5

# ダーティページの書き出し間隔（センチ秒）
vm.dirty_writeback_centisecs = 500

# ダーティページの有効期限（センチ秒）
vm.dirty_expire_centisecs = 3000

dirty_ratioはプロセスがダーティページの書き出しを待たされる閾値、dirty_background_ratioはバックグラウンドでの書き出しが始まる閾値です。書き込みが多い環境ではこれらの値を適切に調整することで、I/Oの安定性が向上します。

OOM Killerの制御

メモリが枯渇した際にカーネルが自動的にプロセスを強制終了させる仕組みがOOM Killer（Out Of Memory Killer）です。重要なプロセスが意図せず終了されるのを防ぐために、以下の設定が有効です。

# メモリのオーバーコミットの制御
# 0: ヒューリスティックによるオーバーコミット（デフォルト）
# 1: 常にオーバーコミットを許可
# 2: オーバーコミットを禁止
vm.overcommit_memory = 0

# オーバーコミット比率（overcommit_memory=2の場合に有効）
vm.overcommit_ratio = 80

また、特定のプロセスのOOMスコアを調整することも可能です。

# 特定プロセスのOOMスコアを調整（-1000〜1000）
# -1000: OOM Killerの対象外にする
echo -1000 > /proc/$(pidof mysqld)/oom_score_adj

プロセス管理の基礎はLinuxプロセス管理ガイドで詳しく解説しています。

ファイルシステム関連のチューニング

ファイルディスクリプタの上限やinotifyの設定は、多数のファイルを扱うサーバーで特に重要です。

ファイルディスクリプタの上限

同時に多数のファイルやソケットをオープンするサーバーアプリケーション（Nginx、Node.jsなど）では、ファイルディスクリプタの上限を引き上げる必要があります。

# システム全体のファイルディスクリプタ上限
fs.file-max = 2097152

# 現在の使用状況を確認
cat /proc/sys/fs/file-nr

file-nrの出力は「使用中のファイルディスクリプタ数 / 割り当て済みだが未使用の数 / 上限値」の3つの値です。使用中の数が上限に近い場合は引き上げが必要です。

プロセス単位のファイルディスクリプタ上限は、/etc/security/limits.confやsystemdのユニットファイルで設定します。

# /etc/security/limits.conf
* soft nofile 65536
* hard nofile 65536

# systemdのユニットファイルでの設定例
[Service]
LimitNOFILE=65536

systemdの詳細はsystemdサービス管理ガイドを参照してください。

inotifyの上限

ファイル変更を監視するアプリケーション（開発ツール、監視ツールなど）が多い環境では、inotifyの上限を引き上げます。

# ユーザーあたりのinotifyインスタンスの最大数
fs.inotify.max_user_instances = 1024

# ユーザーあたりのinotify watchの最大数
fs.inotify.max_user_watches = 524288

開発環境ではホットリロード機能を使うフレームワークが多く、大量のファイルを監視するためにこの設定が必要になるケースがよくあります。

チューニングの手順とベストプラクティス

カーネルチューニングは闇雲に行うと逆効果になることがあります。以下の手順に沿って、計画的に進めましょう。

ステップ1: 現状のボトルネックを特定する

チューニングの前に、まずサーバーの現状を把握します。パフォーマンス監視ツールを使って、どこにボトルネックがあるかを特定しましょう。

# CPU使用率の確認
top -bn1 | head -5

# メモリ使用状況
free -h

# ディスクI/Oの確認
iostat -x 1 5

# ネットワークの接続状況
ss -s

# TIME_WAIT状態のソケット数
ss -ant | grep TIME-WAIT | wc -l

パフォーマンス監視の詳細については、Linuxパフォーマンス監視ガイドを参考にしてください。

ステップ2: 変更前のベースラインを記録する

チューニング効果を正確に測定するために、変更前のパフォーマンスデータを必ず記録しておきます。

# 現在のカーネルパラメータをバックアップ
sysctl -a > /tmp/sysctl-before-tuning.txt

# ベンチマーク結果を記録（Apache Benchの例）
ab -n 10000 -c 100 http://localhost/ > /tmp/benchmark-before.txt

ステップ3: 一度に1つずつ変更する

複数のパラメータを同時に変更すると、どの変更が効果をもたらしたのか（あるいは問題を引き起こしたのか）が判断できません。一度に変更するパラメータは1つ（または関連する少数のグループ）に限定しましょう。

ステップ4: テスト環境で検証する

本番環境に適用する前に、必ずテスト環境で検証します。負荷テストツールを使用して、変更が期待通りの効果をもたらすか確認してください。

ステップ5: 永続化して監視を継続する

効果が確認できたパラメータを/etc/sysctl.d/に記述して永続化し、その後も継続的にパフォーマンスを監視します。ワークロードの変化に応じて、チューニングの見直しが必要になることもあります。

実践例：Webサーバー向けチューニング設定

ここでは、NginxなどのWebサーバーを運用する場合の実践的なチューニング設定例を紹介します。

# /etc/sysctl.d/99-web-server.conf

# --- ネットワーク関連 ---
# TCP接続のバックログを拡張
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 4096

# ネットワークバッファの拡張
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# TIME_WAIT対策
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30

# キープアライブ設定
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 60
net.ipv4.tcp_keepalive_probes = 5

# ローカルポート範囲の拡張
net.ipv4.ip_local_port_range = 1024 65535

# --- メモリ関連 ---
# スワップの抑制
vm.swappiness = 10

# ダーティページ設定
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5

# --- ファイルシステム関連 ---
# ファイルディスクリプタ上限
fs.file-max = 2097152

この設定をファイルに保存した後、以下のコマンドで反映します。

sudo sysctl -p /etc/sysctl.d/99-web-server.conf

Nginxのセットアップと組み合わせる場合は、Nginx構築ガイドの内容と合わせて最適化を進めてください。

チューニング時の注意点とセキュリティへの配慮

カーネルチューニングは性能向上に効果的ですが、設定を誤るとシステムの安定性やセキュリティに影響を及ぼす可能性があります。以下の点に注意してください。

セキュリティ関連のパラメータ

パフォーマンスのためにセキュリティ関連のパラメータを緩和するのは避けるべきです。以下はセキュリティのために有効にしておくべき設定です。

# ICMPリダイレクトの無効化
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0

# ソースルーティングの無効化
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

# SYN Cookieの有効化（SYN Flood攻撃への対策）
net.ipv4.tcp_syncookies = 1

# IPスプーフィング対策
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

セキュリティの強化については、Linuxセキュリティ強化ガイドおよびLinuxファイアウォール設定ガイドも併せて参照してください。

よくある失敗パターン

根拠なく値を大きくしすぎる: バッファサイズを過大に設定すると、メモリが圧迫されて逆にパフォーマンスが低下します
本番環境で直接変更する: テスト環境で検証せずに本番に適用すると、予期しない問題が発生するリスクがあります
変更内容を記録しない: 何を変更したか記録しておかないと、問題発生時の切り分けが困難になります
ネット上の設定をそのままコピーする: サーバーの用途やスペックは環境ごとに異なるため、他所の設定が自社環境に適合するとは限りません

変更管理のすすめ

チューニング設定ファイルは、Gitなどのバージョン管理システムで管理することを強く推奨します。いつ、誰が、何を、なぜ変更したかが追跡でき、問題発生時のロールバックも容易になります。

# チューニング設定のGit管理例
cd /etc/sysctl.d/
sudo git init
sudo git add .
sudo git commit -m "Initial commit: default sysctl settings"

# 変更時
sudo git add 99-web-server.conf
sudo git commit -m "Add web server tuning parameters"

バックアップとリストアの考え方についてはLinuxバックアップ・リストアガイドも参考になります。