はじめに
Nutanix AHV上のWindows Server 2022で、受信側の仮想NIC（vNIC）のキュー数を変え、1,000個のファイルをコピーする時間を比較しました。今回の環境では、キュー数を既定値から4に変更すると、コピーにかかる時間が約36秒から約28秒に短縮しました。
virtio-net multi-queueとは
virtio-net multi-queueは、1つのvNICに複数の送受信キューペアを用意し、通信を並列に処理できるようにする機能です。Windows側では、RSS（Receive Side Scaling）が、異なる通信フローの受信処理を複数のCPUに振り分けます。同じTCP接続のパケットは原則として同じCPUが処理するため、複数の接続が同時に流れるワークロードで効果を期待できます。MicrosoftのRSS解説
ここで区別したいのが、Windowsのドライバーに表示される値と、AHVがvNICに用意するキュー数です。
今回の環境では、Nutanix VirtIO Ethernet Adapterの［詳細設定］で、［Maximum Number of RSS Queues］が 16 でした。これはドライバー側のRSSキュー数の上限です。一方、AHV 6.8の管理ガイドでは、vNICの送受信キューペア数の既定値は 1 です。Windows側の表示が 16 でも、その値だけでは実際に使われるキュー数やvCPU数は分かりません。Nutanix AHV Administration Guide（pp. 106–108）
検証構成と測定方法
Windows Server 2022のVMを2台用意し、異なるAHVノードに配置しました。両VMとも4 vCPU、メモリ8 GiBです。
| 役割 | VM名 | IPアドレス | フォルダー |
|---|---|---|---|
| 送信側 | Windows-Server-2022-1 | 192.168.0.51 | TEST1 |
| 受信側 | Windows-Server-2022-2 | 192.168.0.52 | TEST2 |
送信側の TEST1 から受信側の TEST2 に、エクスプローラーで同じ1,000個のファイルをコピーしました。受信側vNICの設定変更前後でそれぞれ約5回試行し、コピー完了までの時間と、コピー中に画面に表示された速度を比較しました。
小さいファイルのコピーでは、ファイルごとに開く・作成する・閉じるといった処理が発生します。一方、SMBでは複数のファイルの転送に既存のTCP接続を利用できます。SMB Multichannelを利用すると、1つのSMBセッションで複数のTCP接続を使う場合もあります。このため、ファイル数だけから、RSSで分散できる通信フロー数を判断することはできません。MicrosoftのSMB Multichannel解説
受信側vNICのキュー数を変更する
以下のコマンドは、CVMに nutanix ユーザーで接続して実行します。VM名とMACアドレスは検証環境の例です。
まず、対象VMのvNICと現在のキュー数を確認します。AHV 6.8では、出力に queues がなければ既定値の1です。
acli vm.nic_get Windows-Server-2022-2
メンテナンス時間内に、受信側VMをシャットダウンします。
acli vm.shutdown Windows-Server-2022-2
VMの停止を確認してから、対象vNICを queues=4 に変更します。
acli vm.nic_update Windows-Server-2022-2 50:6b:8d:82:19:ba queues=4
設定が反映されたことを確認し、VMを起動します。
acli vm.nic_get Windows-Server-2022-2
acli vm.on Windows-Server-2022-2
Windowsの起動後、変更前と同じファイルを同じ向きにコピーします。
結果
| 測定項目 | 変更前（既定値） | 変更後（queues=4） |
|---|---|---|
| コピー完了までの時間 | 約36秒 | 約28秒 |
| コピー中に観察した表示速度 | 約30 KB/s | 約35～40 KB/s |
| 進捗98%の時点での表示速度 | 31.5 KB/s | 39.5 KB/s |
コピー時間の差は約8秒です。変更前の約36秒を基準にすると、短縮率は (36 − 28) ÷ 36 ≒ 22% でした。31.5 KB/sと39.5 KB/sは、それぞれコピー画面を撮影した時点の値です。
今回確認できたのは、受信側vNICの設定変更後に、一連のファイルコピーが短時間で完了したことです。通信フロー数やvCPUごとの受信負荷までは測定していないため、どの程度の処理が複数のvCPUに分散したかは、この結果だけでは判断できません。
本番環境で試すときの目安
今回の queues=4 は、4 vCPUの検証用VMで試した値です。NutanixのAHV 6.8管理ガイドでは、まずキュー数を2に増やし、ゲストのCPU使用率とネットワーク性能を確認するよう案内しています。VMの総vCPU数を超えてキュー数を増やしても、受信処理の並列度はそれ以上高まりません。Nutanix AHV Administration Guide（pp. 106–108）
別の社内環境では、筆者は1.5～2倍のスループットを観測しました。改善幅は、同時接続数、CPUの空き、ストレージの応答時間、物理ネットワークの混雑状況などによって変わります。本番への適用を判断する際は、実際の負荷に近い条件で、転送時間とCPU使用率を変更前後で比較してください。
関連資料：Nutanix Support & Insightsの関連KB ／ VA Linuxのパケット受信処理解説 ／ [Windowsでのダミーファイル作成例](https://tsuredurediary.com/archives/windows-dummy-file.html