LinuCレベル4 システムアーキテクト 性能・拡張性の設計 問29
性能・拡張性の設計／性能の改善2ソケット構成のNUMAアーキテクチャを持つサーバーでデータベースプロセスを運用している。numastatコマンドで確認したところ、データベースプロセスがリモートNUMAノードのメモリを頻繁にアクセスしていることが応答時間の不安定さの原因になっていることが分かった。改善策として最も適切なものはどれか。
当サイトのオリジナル問題（LinuCレベル4 システムアーキテクトの出題範囲「性能・拡張性の設計」に対応。実際の試験問題ではありません）
- Avm.swappinessを0に設定してスワップを実質無効化し、メモリの余裕を確保する
- Bcgroupのcpusetサブシステムでデータベースプロセスに使わせるCPUコアを制限し、専用リソースを確保する
- Cnumactl --cpunodebind=0 --membind=0でプロセスを起動しCPUとメモリをNUMAノード0に固定する
- DHugePagesを有効化してデータベースのバッファプールを大きなページサイズで確保し、TLBミスを減らす
正解：C
解説
numactlコマンドの--cpunodebind=Nと--membind=Nオプションを組み合わせると、指定したNUMAノードのCPUとメモリのみを使うようにプロセスを起動できる。これによりリモートNUMAノードのメモリへのアクセスを排除し、ローカルNUMAアクセスのみで動作させることができる。NUMAアーキテクチャではローカルメモリアクセスよりリモートメモリアクセスのレイテンシが大きく（一般に1.5〜2倍程度）、頻繁なリモートアクセスが応答時間のばらつきにつながる。
選択肢ごとの解説
- A誤り。vm.swappinessはカーネルがスワップを使う積極性を制御するパラメータ。スワップの使用を抑えることでメモリプレッシャーを緩和する効果はあるが、NUMAのローカル/リモートアクセスの振り分けとは無関係であり今回の問題への直接的な解決にならない。
- B誤り。cgroupのcpusetサブシステムではcpuset.cpusでCPUコアを制限できるが、メモリのNUMAノードバインディングはcpuset.memsで別途設定が必要。CPUコアの制限だけでは今回の問題（リモートメモリアクセス）の解決にならない。
- C正しい。numactlの--cpunodebindと--membindを組み合わせることで、プロセスが使うCPUとメモリを特定のNUMAノードに固定できる。リモートNUMAメモリアクセスを排除する直接的な対策であり正解。
- D誤り。HugePagesは大きなページサイズを使うことでTLBミスを減らし大容量メモリを扱うデータベースで有効な最適化だが、NUMAノードのローカル/リモートアクセスの振り分けを制御するものではなく今回の問題の根本原因への対策にならない。