EC2, Windows 10, la moitié des processeurs virtuels

Windows Server & IT Pro Windows Server 2022 & antérieur
1

Nous exécutons des instances t3.large et m5.large, qui ont 2 vCPU (comme affiché dans la console de gestion EC2). J’essaie de comprendre pourquoi Windows 2019 (AMI fourni par notre IT) ne peut voir que la moitié du nombre de processeurs logiques.

  • La moitié du nombre est rapportée dans le Gestionnaire des tâches, dans msinfo32, dans Coreinfo. Nous voyons également la moitié du nombre pour les instances plus grandes (xlarge : 2 au lieu de 4).

  • Si j’exécute while($true){} dans PowerShell, le Gestionnaire des tâches rapporte 100% d’utilisation, mais CloudWatch rapporte 50%.

  • Dans msconfig, je ne peux choisir que 1 CPU (pour les instances large).

  • Quand j’ai créé mon instance dans l’assistant EC2, j’ai utilisé le nombre par défaut de vCPU.

  • Si j’utilise une AMI Windows 2019 du marketplace, j’obtiens le bon nombre de processeurs logiques. Dans les deux cas, c’est la même version/build (Windows Server 2019 Datacenter).

Sauriez-vous s’il existe une configuration dans Windows 10 qui pourrait affecter le nombre de processeurs logiques détectés ? Ou si je peux activer un journal pour voir comment les CPU sont détectés (comme dmesg sous Linux). Mon collègue IT m’a dit qu’ils n’avaient rien changé concernant le nombre de CPU ou l’hyper-threading, mais il semble qu’il y ait quelque chose de particulier avec leur AMI.

Mise à jour : Dans l’Observateur d’événements, dans “Microsoft / Windows / Kernel-PnP”, je peux voir :

Device
ACPI\GenuineIntel_-Intel64_Family_6_Model_79-_Intel(R)_Xeon(R)CPU_E5-2686_v4@_2.30GHz_1
was configured.

Device
ACPI\GenuineIntel_-Intel64_Family_6_Model_79-_Intel(R)_Xeon(R)CPU_E5-2686_v4@_2.30GHz_0
was configured.

Je ne sais pas s’il y a un autre journal quelque part qui indiquerait quand un CPU/coeur/thread est initialisé comme processeur logique.

Mise à jour 2 : J’ai comparé le contenu de bcdedit /enum All et bcdedit /v pour les machines problématiques et fonctionnelles et c’est le même (sauf un UUID). J’ai essayé de définir explicitement bcdedit /set NUMPROC 2 et de redémarrer, sans résultat. bcdedit /v :

Windows Boot Manager
--------------------
identifier              {9dea862c-5cdd-4e70-acc1-f32b344d4795}
device                  partition=C:
description             Windows Boot Manager
locale                  en-US
inherit                 {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
bootshutdowndisabled    Yes
default                 {61a8a653-e7da-11e8-a960-0e221fdbf186}
resumeobject            {61a8a652-e7da-11e8-a960-0e221fdbf186}
displayorder            {61a8a653-e7da-11e8-a960-0e221fdbf186}
toolsdisplayorder       {b2721d73-1db4-4c62-bf78-c548a880142d}
timeout                 30

Windows Boot Loader
-------------------
identifier              {61a8a653-e7da-11e8-a960-0e221fdbf186}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows Server
locale                  en-US
inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
recoverysequence        {74e13b1d-b199-11ea-827a-0af4c9a8ea6d}
displaymessageoverride  Recovery
recoveryenabled         Yes
allowedinmemorysettings 0x15000075
osdevice                partition=C:
systemroot              \Windows
resumeobject            {61a8a652-e7da-11e8-a960-0e221fdbf186}
nx                      OptOut
bootstatuspolicy        IgnoreAllFailures

Source : [Server Fault](KB4457951: Windows guidance to protect against speculative execution side-channel vulnerabilities - Microsoft Support](KB4457951: Windows guidance to protect against speculative execution side-channel vulnerabilities - Microsoft Support)

2

Ce problème survient lorsque l’Hyper-Threading est désactivé au niveau du système d’exploitation. Cela a peut-être été fait sur la base de la recommandation de Microsoft pour se protéger contre une vulnérabilité connue appelée attaque par canal auxiliaire d’exécution spéculative [1].

Selon les “Conseils Windows pour se protéger contre les vulnérabilités d’exécution spéculative par canal auxiliaire” [2], les clients qui ont Windows Update activé et qui ont appliqué les mises à jour de sécurité publiées le 9 juillet 2019 sont protégés automatiquement. Aucune configuration supplémentaire n’est nécessaire.

Pour résoudre ce problème, j’ai suggéré d’activer l’Hyper-Threading en suivant les étapes ci-dessous :

1. Confirm that Hyper-Threading is disabled by querying the registry using below command:

    •   reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride

    The Hyper-Threading will be disabled if the output is:

    •   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
    •   FeatureSettingsOverride    REG_DWORD    0x2048

2. Once confirmed, proceed with enabling the Hyper-Threading using the below command:

    •   reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 0 /f

3. Restart the instance and check the number of vCPU reported in the OS, which should show the correct number.

Référence :