ハイパースレッディング対応のCPU を持っているので、次の警告が示すように、物理CPUコアの数よりも多くの仮想CPUコアを割り当てるのは悪い考えでしょうか。

転写：

仮想マシンには、ホストシステム上の物理CPUの数よりも多くの仮想CPUが割り当てられます。これにより、仮想マシンのパフォーマンスが低下する可能性があります。仮想CPUの数を減らすことを検討してください。

誰かがこのトピックに推論を置くことができますか？

EDIT1：

問題のCPUはIntel Core i7-4700HQ、Ark Intel、CPUベンチマークです

EDIT2：

仮に、HDD（SSDの代わりに）や低RAM（ここでは16GB、最小vm.swappinessでこのVMに4GB ）などの古いハードウェアはありません。

ハードウェア/ OS /ソフトウェア

ホスト：Linux Mint 18 Cinnamon 64-bit（完全に更新済み）; カーネルバージョン4.4.0-47-generic

ゲスト：Windows 8.1 Pro 64ビット（完全に更新済み）

プロセッサー：Intel Core i7-4700HQ、（6MBキャッシュ、4つの物理コア、またはハイパースレッディングを使用した8つ）、CPUベンチマーク

VirtualBox：バージョン5.1.10 r112026（Qt5.5.1）

ゲストの追加：インストール済みで最新

ベンチマークツール＃1：WinRARバージョン5.40最終的な64ビット

ベンチマークツール＃2：VeraCryptバージョン1.19最終64ビット

準備

どちらの場合も、ブート後にCPU、RAM、ディスクドライブがゼロ点付近で安定するまで待機しました。

方法

1. 元の仮想マシンを複製して、2つの同一の仮想マシンを作成します。
2. 2回目のパスでは、再起動が無効になったため、Antivirusがこの回答の最後に指摘し、どちらの場合もWinRARをベータ版から最終版に更新しました。
3. 先ほど指摘したのと同じ準備をしました。
4. 仮想マシンはフォアグラウンドで実行され、他のCPU時間を必要とするアプリケーションは実行されていません。テストに影響を与えないためにできることは無効にしました。
5. システムの内部または外部に潜在的なキャッシュを含めるために、結果として同じテストを2回実行しました。利点はほとんどありません。

結果

WinRAR

1. 4コア=> 7.5分（時間が短いほど良い）

   

   4つのコアを有効にしたWinRAR 、1.5GiBは7.5分で処理されました。

2. 8コア=> 4.5分（時間が短いほど良い）

   

   8コアを有効にしたWinRAR 、1.5GiBは4.5分で処理されました。

VeraCrypt

1. 4コア=>速度2.6 GiB / s（速度は速いほど良い）

   

   4コアが有効なVeraCrypt 、HW加速AES（AES-NI）速度2.6 GiB / s。

2. 8コア=>速度3.9 GiB / s（速度は速いほど良い）

   

   8コアが有効なVeraCrypt 、HW加速AES（AES-NI）速度3.9 GiB / s。

結論

必要なだけテストを実行できました。しかし、この2つがどちらかと言えばかなり複雑な圧縮テストであり、もう1つがかなり複雑な暗号化テストのセットである場合、そのポイントはどうなるかを考えています。

どちらのベンチマークも顕著な違いを示しています。かなり厳密な準備と方法に従ったため、結果が不正確であると信じる理由はありません。さらに、これらのテストはI / Oボトルネックを排除するためにRAMで行われました。私の観点からは、質問で言及された警告はいくつかの条件に当てはまるかもしれませんが、すべての条件に当てはまるわけではありません。これらの驚くべき結果を皆さんと共有しましたが、最新のVirtualBoxバージョンを備えたハイパースレッディングを備えた最新のCPUではおそらくこの警告をそれほど真剣に受け止めてはならないことを私は同意します。確かなことは、この設定を永続的に適用することを決定する前に、私にその言葉を信じて自分の条件でテストしないでください。

OSの設計者として、私は測定の結果に完全に同意します。主題に関して他の場所で生み出されたでたらめの量は信じられないほどです。

HWで実行できる並列スレッド/プロセスの数として、論理コアの数を参照してください。これは、たとえばCPUコアのレジスタと命令ポインターを複製することで実現されます。CPUコア自体が、使用するスレッド（命令ポインター）を決定するようになりました。現在のスレッドの命令がキャッシュで利用できず、メモリやL3キャッシュなどからフェッチする必要があるため、他のスレッドを使用することを決定します。このメカニズムにより、命令/秒またはCPUパフォーマンスが10％〜30％改善される可能性があります。

1つのスレッドで1つのアプリケーションを実行する場合、このメリットを享受することはできませんが、たとえば古いHT Pentiumで2つの高負荷アプリケーションを実行する場合、メリットを享受できます。もちろん、同じことが複数のスレッドを持つアプリケーションにも当てはまります。私のLinuxシステムには200のスレッドがあるため、実際の負荷に依存する利点が常に存在します。これらのすべてのコメントは、仮想化なしで適用されます。

Virtualboxは、各仮想マシン（VM）で並行して実行できるスレッドの数を制限するだけですが、ホストプロセススケジューラーは、VMプロセスが動的に実行される論理プロセッサー、したがって物理プロセッサーを変更します。VMで高負荷のアプリケーションを実行する場合、追加の論理コアにより、10％〜30％の同じ利点が得られます。負荷は、単一のマルチスレッドアプリケーションまたは異なるアプリケーションのセットにすることができます。

VT-xまたはAMD-Vを搭載した最新のシステムでは、同時により多くの仮想マシンを実行することによる顕著なパフォーマンスペナルティがないため、論理コアの数を最大限にすることによるパフォーマンスペナルティはありません。制限はCPUチップのパフォーマンスです。したがって、各VMは同じ物理CPUを共有する必要があるため、各VMの速度を落とさずに、同時に3つのVMでビデオをレンダリングすることはできません。

すべての論理コアが存在するVMでビデオをレンダリングすると、ホストシステムが応答しなくなる可能性がありますが、ホストでそのレンダリングアプリを実行すると、ほぼ同じ問題が発生します。少なくともVMには選択肢があり、最大CPU負荷を80％〜90％に制限するか、この理由でコアの数を減らすことで解決できます。

私の最高の2セントは、すべてのコア/スレッドを決して使用せず、ホストに1つか2つだけにすることです。

したがって、あなたの場合、ゲストに6コアを与え、8コアは与えないでください（ホスト上に8スレッドしかないため）。

ホスト上の使用可能なスレッドの数（コアと混同しないように）が次の場合：

• <2の場合、仮想マシンをまったく使用しない方が良い
• 2の場合、モノコアモードで仮想マシンを使用するか、リスクを冒してデュアルコアゲストを使用します
• 2より大きい場合は、式を使用する方が良い

3つ以上のスレッドの場合、次の式を使用する傾向があります。

• N =ホストのスレッド数
• M =実行する並行仮想マシンの数（均等なバランス、各ゲストの同数のゲストコアを想定）
• ホストに4つ以下のスレッドしかない場合、Formula =（N-1）/ M
• ホストに4つ以上のスレッドがある場合、Formula =（N-2）/ M

私の経験では、そのようなフォーミュラの制限を超えないようにすれば、はるかにスムーズでリスクが少なくなります。

警告：ゲストの実行中にゲストコアの数を変更することはできませんが、CPU使用率を100％から75％または50％に下げることができます。失敗するゲストは少なくありません。

だから時々、私は2人のゲストに8スレッドホスト上の6つの6コア（2人のゲストではなく1人のゲストのように式の数）を与える傾向がありますが、CPU速度の50％に制限します（両方のゲストが1 / 2の時間（CPU））が、ゲストがイメージ比較/結合などのように、並列の比率が1より大きいアプリを実行することがわかっている場合のみ