サーバーのワークロード最適化のためのチューニング済みプロファイル

Linuxのデフォルト設定は、パフォーマンスではなく互換性を重視して調整されています。tunedデーモンには、特定のワークロードに合わせてCPUガバナー、I/Oスケジューラ、カーネルパラメータ、ネットワークバッファを調整する事前定義されたプロファイルが付属しています。本記事では、これらのプロファイルの仕組み、一般的なサーバーの役割に適したプロファイルの選択方法、およびカスタムプロファイルを作成してサーバー群全体に展開する方法について解説します。

プロファイルの調整方法

プロファイルとは、 /usr/lib/tuned/profiles/ (system) または /etc/tuned/profiles/ (custom) 配下のディレクトリであり、 tuned.conf ファイルが含まれています。この設定ファイルは、プラグインごとにパラメータをグループ化しています： [cpu], [disk], [sysctl], [vm], [bootloader]など。プロファイルを有効にすると、tunedデーモンは数十個の sysctl コマンドを sysfs コマンドを個別に実行するのではなく、すべてのパラメータを一括で適用します。

プロファイルは、 include ディレクティブを使用して、プロファイルは互いに継承できます。例えば、 throughput-performance profileは、例えば、 vm.swappiness Transparent Huge Pages設定のみを上書きするカスタムデータベースプロファイルのベースとして機能します。

tunedには2つのモードがあります。静的チューニングは、起動時に一度プロファイルを適用した後、システムに干渉しません。これは、省電力よりも一貫性が重視される本番サーバーに適しています。動的チューニングは、ディスク、ネットワーク、および負荷の使用状況をリアルタイムで監視し、設定をその場で調整します。パフォーマンスプロファイルは、監視によるオーバーヘッドを避けるため、デフォルトで動的チューニングを無効にします。

ワークロードに適したプロファイルの選択

tunedは、一般的なワークロードのほとんどをカバーする12種類のプロファイルを提供しています。デフォルトのプロファイルをそのまま使用するのではなく、サーバーの実際の用途に合ったものを選択してください balanced プロファイルをそのままにしないでください。

特定のデータベースエンジン向けに、tunedには以下の機能も含まれています postgresql, mssql、および oracle それらのエンジン向けに共有メモリやカーネルスケジューラパラメータを調整することで、 throughput-performance 、それらのエンジン向けに共有メモリやカーネルスケジューラのパラメータを調整することで、さらに高度な最適化を行うプロファイルも提供されます。

マルチソケットサーバーでは、NUMAトポロジーが重要になります。リモートノードへのメモリアクセスは、ローカルアクセスに比べて2～3倍遅くなる場合があります。デュアルソケットマシンでレイテンシが重要なワークロードを実行する場合は、プロファイルで自動NUMAバランス調整を無効にし、プロセスを特定のノードに手動で固定してください。

プロファイルのインストールと適用

RHEL、Rocky、AlmaLinux、またはFedoraにtunedをインストールして適用するには：

dnf install tuned
systemctl enable --now tuned

DebianおよびUbuntuでは、パッケージ名は tuned と呼ばれ、 aptでインストールします。もし power-profiles-daemon が既に実行中の場合は、競合を避けるためにマスクしてください:

systemctl mask --now power-profiles-daemon

利用可能なプロファイルを一覧表示し、ハードウェアに対して tuned が推奨するプロファイルを尋ね、プロファイルを適用し、確認します:

tuned-adm list
tuned-adm recommend
tuned-adm profile throughput-performance
tuned-adm verify

アクティブなプロファイルは /etc/tuned/active_profile に保存され、再起動後も維持されます。チューニングを完全に解除してベースラインを測定するには、以下を実行します tuned-adm off.

AI、ML、および高帯域幅ワークロード向けのカスタムプロファイルの作成

標準プロファイルで要件の90%を満たせる場合は、最も近いプロファイルを継承し、残りのパラメータを上書きするカスタムプロファイルを作成してください。ディレクトリと設定ファイルから始めます：

mkdir -p /etc/tuned/ai-gpu
cat > /etc/tuned/ai-gpu/tuned.conf <<'EOF'
[main]
summary=Custom profile for GPU training with high-bandwidth networking
include=accelerator-performance
 
[cpu]
governor=performance
 
[sysctl]
kernel.numa_balancing=0
net.core.rmem_max=268435456
net.core.wmem_max=268435456
net.ipv4.tcp_rmem=4096 87380 268435456
net.ipv4.tcp_wmem=4096 65536 268435456
 
[vm]
transparent_hugepages=never
 
[bootloader]
cmdline=hugepagesz=2M hugepages=16384 <a target="_blank" rel="noopener noreferrer" href="https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit">iommu</a>=pt
EOF
 
tuned-adm profile ai-gpu

ここで重要な設定は以下の通りです：

• numa_balancing=0 トレーニング実行中にカーネルがソケット間でメモリを移動するのを停止します。これはデュアルソケットGPUシステムにおける処理停止の一般的な原因です。
• The rmem_max および tcp_rmem の値は、ソケットバッファの上限を256MBに引き上げます。トレーニングノード間の25G、40G、または100Gインターコネクトでは、デフォルトのバッファサイズではスループットがラインレートを大幅に下回ってしまいます。
• transparent_hugepages=never は、大規模なテンソルを割り当てるPyTorchやTensorFlowのようなフレームワークにおいて、THPが引き起こすレイテンシのジッターを解消します。
• iommu=pt は、IOMMUをパススルーモードに設定します。これは、GPUおよびNICのパススルーに必要であり、ベアメタルDMAのオーバーヘッドを低減します。

以下は [bootloader] は再起動が必要です。プロファイルを有効にした後、 tuned-adm verify を実行してランタイムパラメータが適用されたことを確認し、 journalctl -u tuned エラーがないか確認します。 iostat -xz, numastatおよび関連するワークロードツール（iperf3, fio、または実際のトレーニング実行）を使用してベンチマークを実行してください。

明確にしておくべきトレードオフとして、CPUのセキュリティ緩和策を無効にすると、GPUワークロードでは約3～8%のパフォーマンス向上が見込めますが、システムコールの頻度が高いワークロードでは15～30%のパフォーマンス低下を招きます。対象システムの脅威モデルに基づいて判断してください。ファイアウォール内の専用トレーニングクラスタ内では、通常、これらを無効にする方が有利です。 マルチテナントホスト上では、有効なままにしておいてください。

サーバー群全体でのプロファイル管理

手動での tuned の適用は、サーバーが数台を超えると現実的ではなくなります。Ansible ならこれをスムーズに処理できます。1つのプレイブックで tuned をインストールし、 /etc/tuned/ 経由で template モジュール経由で適切なプロファイルを適用します。

プロファイルをインベントリ内のロールにマッピングする：

• GPUおよびAIノード: accelerator-performance、またはそれを継承するカスタムプロファイル
• データベースサーバー: throughput-performance またはエンジン固有のプロファイル
• 高帯域幅トラフィックを送信するCDNおよびエッジノード: network-throughput
• ロードバランサーの背後にあるAPIおよびWebサーバー: network-latency
• VPSおよびKVMゲスト： virtual-guest
• ハイパーバイザーホスト: virtual-host

設定のずれこそが、真の運用上の問題です。手動による sysctl 変更、新しいデフォルト設定を含むパッケージのアップグレード、あるいは別の構成管理ツールがtunedに干渉するなど、これらすべてがプロファイルの設定内容との乖離を引き起こします。Ansibleジョブをスケジュールして実行するようにしてください tuned-adm active 、 tuned-adm verify 実行するようにスケジュールし、失敗した場合はアラートを出します。「Verification failed」という行がないか /var/log/tuned/tuned.log 「Verification failed」という行がないか確認してください。

結論

tunedは、カーネルやsysctlのチューニングにおける推測作業の大部分を排除します。デフォルト設定は一般的な用途には十分であり、 accelerator-performance, throughput-performance、および network-throughput を使用すれば、設定ファイルを1つたりとも記述することなく、最適化の大部分を達成できます。

• 最も近い標準プロファイルを選び、 tuned-adm verifyを実行し、ベンチマークを実行してください
• 標準プロファイルを継承し、必要な部分のみを上書きしてカスタムプロファイルを作成してください
• GPU や高帯域幅のマシンでは、NUMA バランス、hugepages、ネットワークバッファサイズについて慎重に検討してください
• Ansibleを使用してデプロイし、スケジュールに従って監査を行い、ドリフトを捕捉する

これらの設定を実際に活用するための帯域幅の余裕を備えたベアメタル環境が必要ですか？高スループットおよびGPUワークロード向けに構築された専用サーバーについては、FDCにご相談ください。