サーバーが安定して動いているのになぜ遅いのか？
こんな経験がある。CentOSサーバーを新規セットアップしたばかりで、RAMにまだ余裕があり、CPUも30%に達していないのに、アプリケーションのレスポンスタイムが期待より高い。コードの問題ではなく、ネットワークでもない。しばらくデバッグして初めてわかった――カーネルがpower-savingモードを使っており、I/Oスケジューラが実行中のワークロードに適していない上、カーネルが実行するジョブの種類に合わせて自動調整しない細かいパラメータが数十個あったのだ。
そのとき初めてtuned-admを調べ始めた――RHEL/CentOSに標準搭載されているツールで、ワークロードの種類に応じた「プロファイル」でシステムを自動調整する。
Linuxパフォーマンス最適化の3つのアプローチとそれぞれのメリット・デメリット
Linuxのパフォーマンスを最適化するアプローチは3つある。なぜtuned-admが最も実用的な選択肢なのかを理解するために、3つを簡単に説明する。
方法1：sysctlとカーネルパラメータによる手動チューニング
/etc/sysctl.confやCPU governor、I/Oスケジューラなどを自分で調整する。メリット：各パラメータを完全にコントロールできる。デメリット：カーネル内部の深い知識が必要で、リサーチに何時間もかかり、小さなミスでサーバー全体が不安定になる可能性がある。
方法2：長年かけて積み上げた自作スクリプト
多くのシステム管理者は、新規サーバーのセットアップ時に適用する「魔法の」スクリプト集を持っている。一見良さそうだが現実は違う。スクリプトはきちんとテストされていないことが多く、新しいカーネルに対応していないし、なぜそのコードが書かれたのか誰も覚えていない。問題が起きたとき、デバッグはほぼ不可能だ。
方法3：既存プロファイルを使ったtuned-adm
Red Hatが本番環境で推奨する方法であり、具体的な理由がある。プロファイルはRed Hatのエンジニアチームによって十分にテストされ、ドキュメントが整備されており、RHEL/CentOSのメジャーリリースごとに更新される。パラメータを覚える必要も、ミスの心配もない――適切なプロファイルを選ぶだけでいい。
カーネルチューニングを深く掘り下げる時間がなければ、tuned-admは最も合理的な出発点だ。さらに細かく調整したい場合は、組み込みプロファイルを継承したカスタムプロファイルを作ることもできる――後ほど説明する。
tuned-admのインストールと確認
CentOS Stream 9ではtunedは通常インストール済みだ。インストールされていない場合：
sudo dnf install tuned -y
sudo systemctl enable --now tuned現在のプロファイルと利用可能なプロファイルの一覧を確認する：
# アクティブなプロファイルを確認
tuned-adm active
# すべてのプロファイルを一覧表示
tuned-adm listVMで実行している場合、出力は通常balancedまたはvirtual-guestになる――どちらも本番サーバーには最適ではない。
各プロファイルの解説と使うべきタイミング
throughput-performance — データベースサーバー向け
最適な用途：MySQL、PostgreSQL、MariaDB、バッチ処理、データパイプライン。
データベースサーバーには、まずこのプロファイルを試すべきだ。電源節約を完全に無効化し、CPU governorをperformanceに設定し、I/Oスケジューラを細かく調整する。CPUがスロットリングすることは決してなく、ディスクの読み書きが格段に安定する。唯一のトレードオフは消費電力が増えることだが、データセンターの物理サーバーでは問題にならない。
sudo tuned-adm profile throughput-performance
# CPU governorがperformanceに切り替わったか確認
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
# 出力: performance
# I/Oスケジューラを確認
cat /sys/block/sda/queue/scheduler
# ディスクタイプに応じて[mq-deadline]または[none]に切り替わることが多いnetwork-throughput — Webサーバー向け
最適な用途：Nginx、Apache、CDNノード、同時接続数が多いリバースプロキシ。
ネットワークバッファサイズ（受信/送信バッファ）を増やし、より多くの接続を処理できるようTCPスタックを調整する。Webサーバーには最初にこのプロファイルを適用することが多い。
sudo tuned-adm profile network-throughput
# ネットワークバッファが増加したか確認
sysctl net.core.rmem_max
sysctl net.core.wmem_max
# 値が~212992から~134217728に増加（約600倍）network-latency — APIサーバーとロードバランサー向け
最適な用途：APIゲートウェイ、ロードバランサー、リクエストごとのレスポンスタイムが重要なマイクロサービス。
network-throughputとは反対に、このプロファイルはスループットよりレイテンシを優先してTCPバッファを削減する。ペイロードが大きいリクエストが少ない場合よりも、小さいリクエストが高頻度に来る場合に適している。
sudo tuned-adm profile network-latencylatency-performance — リアルタイムアプリケーション向け
最適な用途：トレーディングシステム、ゲームサーバー、極めて低く安定したレスポンスタイムが求められるアプリケーション。
CPU C-states（CPUアイドル状態）を完全に無効化し、タスクがなくてもCPUがスリープしないようにする。結果として、レスポンスタイムが極めて安定し、スリープ状態からのCPU復帰によるレイテンシスパイクが発生しなくなる。大きなデメリット：アイドル中でもCPUは常に最大電力を消費する。
sudo tuned-adm profile latency-performancehpc-compute — HPCと機械学習向け
最適な用途：機械学習トレーニング、動画エンコード、シミュレーション、科学計算。
最も「フルスロットル」なプロファイルだ――CPUは常にperformanceモードで動作し、NUMAトポロジーが最適化され、メモリスラッシングを防ぐためにスワップが最小限に抑えられる。重い計算ワークロードを実行するなら、まずこのプロファイルを試すべきだ。
sudo tuned-adm profile hpc-compute
# スワップが減少したか確認（vm.swappiness）
sysctl vm.swappiness
# 出力: 10（デフォルトの60から変更）ユースケース別プロファイル選択ガイド
クイックリファレンス：
- Nginx/Apache Webサーバー →
network-throughput - MySQL/PostgreSQL データベース →
throughput-performance - APIゲートウェイ / ロードバランサー →
network-latency - リアルタイム / 低レイテンシアプリ →
latency-performance - ML トレーニング / HPC →
hpc-compute - クラウド上のVM →
virtual-guest（ベースとして使い、その後オーバーライド）
組み込みプロファイルでは不十分な場合のカスタムプロファイル作成
こんなケースがあった：データベースとWebサーバーを同時に実行するサーバー（小さなスタートアップのモノリシックな構成）。どのプロファイルも完全には合わない。解決策：throughput-performanceを継承したカスタムプロファイルを作り、いくつかのネットワークパラメータをオーバーライドする。
# 新しいプロファイル用ディレクトリを作成
sudo mkdir /etc/tuned/my-webdb
# 設定ファイルを作成
sudo nano /etc/tuned/my-webdb/tuned.conftuned.confの内容：
[main]
summary=Custom profile for web+database combo server
include=throughput-performance
[sysctl]
# オーバーライド: network-throughputと同様にネットワークバッファを増加
net.core.rmem_max=134217728
net.core.wmem_max=134217728
net.ipv4.tcp_rmem=4096 87380 134217728
net.ipv4.tcp_wmem=4096 65536 134217728
# データベース用にswappinessを削減
vm.swappiness=10# カスタムプロファイルを適用
sudo tuned-adm profile my-webdb
# 確認
tuned-adm active効果を確認するためのベンチマーク
プロファイルを変更したら、具体的な数値を得るために変更前後でベンチマークを取る：
# Webサーバー: wrkを使用（未インストールの場合はインストール）
sudo dnf install wrk -y
wrk -t4 -c100 -d30s http://localhost/
# ディスクI/O: fioを使用
sudo dnf install fio -y
fio --name=randread --ioengine=libaio --iodepth=16 \
--rw=randread --bs=4k --size=1G --numjobs=4 \
--runtime=30 --group_reporting実際に計測した数値によると、データベースサーバーはthroughput-performanceに切り替えた後、クエリ時間が通常15〜25%短縮される。ランダムI/Oのワークロードで最も効果が顕著だ。Webサーバーをwrkでテストすると、network-throughput適用後にスループットが約20%向上することが多い。
実運用で覚えておくべきポイント
うちの会社ではCentOS 7からAlmaLinuxへの移行を何台か実施した。毎回、tunedプロファイルの設定は初日のセットアップで行う――後回しにしない。「余裕ができたら」と思っていると、永遠に余裕ができない。
- プロファイルは再起動後も維持されるのは
tunedサービスが有効になっているときだけ。必ず実行する：systemctl enable tuned - プロファイルの変更に再起動は不要――tunedは変更を即座に適用する
- インストール後のデフォルトプロファイルは
balanced――本番環境には最適ではない - クラウドVM（AWS、GCP、Azure）では、オーバーライドを追加する前にベースプロファイルを
virtual-guestにすべきだ
# tunedが実行中か素早く確認
systemctl status tuned
# 問題がある場合はログを確認
journalctl -u tuned -n 50
# プロファイルが変更する内容の詳細を確認
tuned-adm profile-info throughput-performancetuned-admはすべてのパフォーマンス問題の万能解決策ではないが、あらゆる本番サーバーで最初にやるべきステップだ。セットアップとベンチマークにわずか5分しかかからない――その代わりに、ラップトップ向けのデフォルト設定ではなく、実際のワークロードに合った構成でシステムが動作するようになる。
