내가 가지고있는 하이퍼 스레딩 수있는 CPU를 궁금해, 그것은 다음과 같은 경고에서 알 수 있듯이 나쁜 생각은 물리적 CPU 코어의 수보다 더 많은 가상 CPU 코어를 할당하는 것입니다 :

성적 증명서:

호스트 시스템의 물리적 CPU 수보다 많은 가상 CPU가 가상 시스템에 할당됩니다. 이는 가상 머신의 성능을 저하시킬 수 있습니다. 가상 CPU 수를 줄이십시오.

누군가이 주제에 대해 추론을 할 수 있습니까?

편집 1 :

문제의 CPU는 Intel Core i7-4700HQ, Ark Intel , CPU 벤치 마크입니다.

EDIT2 :

SSD와 같은 HDD 및 / 또는 Low RAM (여기서는 16GB, vm.swappiness이 VM의 경우 최소 4GB ) 등과 같이 사용되지 않는 HW가 없다고 가정 합니다.

하드웨어 / OS / 소프트웨어

호스트 : Linux Mint 18 Cinnamon 64 비트 (완전히 업데이트); 커널 버전 4.4.0-47- 일반

게스트 : 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, 디스크 드라이브가 거의 0 점에 도달 할 때까지 기다렸습니다.

방법

1. 두 개의 동일한 가상 머신을 갖도록 원래 가상 머신을 복제합니다.
2. 재부팅 비활성화 바이러스 백신 이이 답변의 맨 아래를 지적하고 두 경우 모두 베타에서 최종 버전으로 WinRAR을 업데이트했기 때문에 두 번째 단계를 수행했습니다.
3. 이전에 지적한 것과 동일한 준비를 수행했습니다.
4. 가상 시스템은 다른 CPU 시간이 걸리는 응용 프로그램을 실행하지 않고 포 그라운드에서 실행되었으므로 테스트에 영향을 미치지 않도록 할 수있는 것을 비활성화했습니다.
5. 시스템 내부 또는 외부에 잠재적 인 캐싱을 포함시키기 위해 동일한 테스트를 두 번 실행했습니다. 이점은 거의 없습니다.

결과

윈라

1. 4 코어 => 7.5 분 ( 짧은 시간이 낫습니다)

   

   4 개의 코어가 활성화 된 WinRAR , 7.5GiB가 7.5 분 동안 처리되었습니다 .

2. 8 코어 => 4.5 분 ( 짧은 시간이 낫습니다)

   

   8 개의 코어가 활성화 된 WinRAR , 4.5GiB에서 4.5 분 동안 처리 .

베라 크립트

1. 4 코어 => 속도 2.6 GiB / s ( 높은 속도가 좋음)

   

   와 VeraCrypt 4 개 코어가 활성화 HW 가속 AES (AES-NI) 속도 2.6 지브 / S.

2. 8 코어 => 속도 3.9 GiB / s ( 높은 속도가 좋음)

   

   와 VeraCrypt 8 개 코어가 활성화 HW 가속 AES (AES-NI) 속도 3.9 지브 / S.

결론

필요한만큼 많은 테스트를 실행할 수있었습니다. 그러나이 두 가지 중 하나가 다소 복잡한 압축 테스트이고 두 번째는 다소 복잡한 암호화 테스트 세트라면 요점이 무엇인지 알 수 있습니다.

두 벤치 마크 모두 뚜렷한 차이를 보여줍니다. 필자는 다소 엄격한 준비와 방법을 따랐을 때 결과가 정확하지 않다고 믿을만한 근거가 없으며, 이러한 테스트는 RAM에서 수행되어 I / O 병목 현상을 배제했습니다. 내 관점에서, 질문에 언급 된 경고는 일부 조건에 적용 될 수 있지만 모든 조건에 해당되는 것은 아닙니다. 이 놀라운 결과를 당신과 함께 나누었으므로, 나는 당신이 나에게 동의 할 것이라고 확신합니다 . 최신 VirtualBox 버전의 하이퍼 스레딩 기능을 갖춘 최신 CPU에서는이 경고를 심각하게 받아들이지 않아야합니다 . 한 가지 확실한 점 :이 설정을 영구적으로 적용하기 전에 단어를 직접 입력하고 자신의 조건에서 테스트하지 마십시오.

OS 디자이너로서 저는 측정 결과에 전적으로 동의합니다. 주제와 관련하여 다른 곳에서 생산되는 헛소리의 양은 믿을 수 없습니다.

HW가 실행할 수있는 병렬 스레드 / 프로세스 수로 논리 코어 수를 참조하십시오. 예를 들어 CPU 코어의 레지스터와 명령어 포인터를 복제하면됩니다. CPU 코어 자체는 사용할 스레드 (명령 포인터)를 결정합니다. 현재 스레드의 명령어를 캐시에서 사용할 수없고 메모리 또는 L3 캐시에서 가져와야하므로 다른 스레드를 사용하기로 결정합니다. 이 메커니즘은 명령 / 초 또는 CPU 성능을 10 % -30 % 향상시킬 수 있습니다.

하나의 스레드로 단일 응용 프로그램을 실행하면이 이점을 얻을 수 없지만 기존 HT Pentium과 같은 두 개의 고부하 응용 프로그램을 실행하면 이점을 얻을 수 있습니다. 하나 이상의 스레드가있는 응용 프로그램의 경우에도 마찬가지입니다. 내 Linux 시스템에는 200 개의 스레드가 있으므로 실제로드에 따른 일부 이점이 항상 존재합니다. 이러한 모든 언급은 가상화없이 적용됩니다.

Virtualbox는 각 가상 머신 (VM)에 대해 병렬로 실행할 수있는 스레드 수만 제한하지만 호스트 프로세스 스케줄러는 VM 프로세스가 동적으로 실행되는 논리적 프로세서와 물리적 프로세서를 변경합니다. VM에서 고부하 응용 프로그램을 실행하면 추가 논리 코어가 10 % -30 %의 동일한 이점을 제공합니다. 부하는 단일 멀티 스레드 응용 프로그램이거나 다른 응용 프로그램 집합 일 수 있습니다.

VT-x 또는 AMD-V를 사용하는 최신 시스템에서는 동시에 더 많은 가상 머신을 실행하는 경우 눈에 띄는 성능 저하가 없기 때문에 논리 코어 수를 최대화해도 성능 저하가 없습니다. 제한은 CPU 칩의 성능이므로 각 VM의 속도를 늦추지 않으면 서 동일한 물리적 CPU를 공유해야하기 때문에 3 개의 VM에서 동시에 비디오를 렌더링 할 수 없습니다.

모든 논리 코어가있는 VM에서 비디오를 렌더링하면 호스트 시스템이 응답하지 않을 수 있지만 호스트에서 해당 렌더링 앱을 실행 한 경우 거의 동일한 문제가 발생합니다. 적어도 VM에서는 선택 사항이 있으며 최대 CPU 부하를 80 % -90 %로 제한하거나 이러한 이유로 코어 수를 줄여서 해결할 수 있습니다.

내 최고의 2 센트는 모든 코어 / 스레드를 사용하지 않고 호스트에 한두 가지만 허용하는 것입니다.

따라서 귀하의 경우 게스트에게 8 코어를 제공하십시오 (여러 호스트에는 8 개의 스레드 만 있기 때문에).

호스트에서 사용 가능한 스레드 수가 코어와 혼동되지 않는 경우 :

• <2 인 경우 가상 머신을 전혀 사용하지 않는 것이 좋습니다.
• 2 인 경우 모노 코어 모드에서 가상 머신을 사용하거나 위험을 감수하고 듀얼 코어 게스트를 사용하십시오.
• > 2 인 경우 수식을 사용하는 것이 좋습니다

두 개 이상의 스레드의 경우이 수식을 사용하는 경향이 있습니다.

• N = 호스트의 스레드 수
• M = 실행하려는 동시 가상 머신 수 (균등 한 균형, 각 게스트에 대해 동일한 수의 게스트 코어 가정)
• 호스트에 스레드가 4 개 이하인 경우 Formula = (N-1) / M
• 호스트에 4 개 이상의 스레드가있는 경우 Formula = (N-2) / M

나의 경험은 그러한 공식 한계를 초과하지 않는 것이 훨씬 부드럽고 덜 위험하다는 것을 말해줍니다.

경고 : 게스트를 실행하는 동안 게스트 코어 수를 변경할 수는 없지만 CPU 사용률을 100 %에서 75 % 또는 50 %로 낮추면 게스트가 실패하지 않을 수 있습니다.

따라서 때로는 2 스레드 손님에게 8 스레드 호스트에 6 개의 6 코어를 제공하는 경향이 있지만 (2 명의 게스트 대신 한 명의 게스트 만있는 것처럼 수식의 수) CPU 속도의 50 %로 제한합니다 (두 게스트 모두 1을 사용할 수 있음) / 2의 CPU 시간),하지만 손님이 이미지 비교 / 조인트 등과 같이 병렬 비율이 1보다 큰 앱을 실행하는 경우에만 알 수 있습니다.