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

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

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システムにおける処理停滞の一般的な原因です。
• この 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、あるいは実際のトレーニング実行）を使用して、変更前後のベンチマークを実行してください。

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

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

手動でのtunedの適用は、サーバーが数台を超えると現実的ではなくなります。Ansibleならこれをスムーズに処理できます。1つのプレイブックでtunedをインストールし、 /etc/tuned/ via the 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 cronで実行するようにスケジュールし、失敗時にはアラートを発行します。「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にご相談ください。