通过bcdedit命令可以调整cpu、内存、groupsize等等。groupsize取值最大不超过64、group的个数最大不超过20。基于此，如果有一台80个vcpu的机器，那groupsize就不能低于4，因为按最多20个group来算，groupsize最小是4，低于4会蓝屏。
打开vnc耐心等待从0%到100%，大概15分钟左右或者20分钟左右，选择Troubleshoot
选择Administrator输入密码进到cmd命令行
bcdedit.exe /deletevalue {default} groupsize
bcdedit.exe /deletevalue {default} numproc
我是80c机器，我执行了下面2句命令出现的蓝屏，所以我在recovery模式的cmd里反其道而行之，复原到执行这2句命令之前（注意，一般执行bcdedit命令都需要加{current} 、{default}，正常系统如果是命令里有{default}，可以省略{default}，但recovery模式不能省略）
bcdedit.exe /set numproc 60
bcdedit.exe /set groupsize 3
执行完bcdedit.exe /deletevalue …后重启机器就恢复正常了。
再比如，hostname限制15个字符，通过注册表给改到15个字符以上，机器也会蓝屏。一般来说，操作系统本身的限制就不要尝试挑战了，没意义。
假如是160个vcpu的机器，160÷20，groupsize不能低于8。
搞多个group没用，默认情况下，应用程序被限制在一个组中。这一点，从 Windows 11 和 Windows Server 2022 开始变化。
Windows Server 2008、Windows Vista、Windows Server 2003 和 Windows XP：不支持groupsize。
64 位版本的 Windows 7 和 Windows Server 2008 R2 以及更高版本的 Windows 在单台计算机上支持超过 64 个逻辑处理器。此功能在 32 位版本的 Windows 上不可用。
在具有 64 个或更少处理器的系统上，现有应用程序无需修改即可正常运行。
对具有超过 64 个逻辑处理器的系统的支持基于处理器组的概念，它是最多 64 个逻辑处理器的静态集合，被视为单个调度实体。处理器组从 0 开始编号。少于 64 个逻辑处理器的系统始终只有一个组，即组 0。
为了获得更好的性能，操作系统在将逻辑处理器分配给组时会考虑物理位置。如果可能，一个内核中的所有逻辑处理器以及一个物理处理器中的所有内核都被分配到同一个组中。物理上彼此靠近的物理处理器被分配到同一组。除非节点的容量超过最大组大小，否则 NUMA 节点将分配给单个组。
默认情况下，应用程序被限制在一个组中，这应该为典型应用程序提供充足的处理能力。操作系统最初以循环方式跨系统中的组将每个进程分配给单个组。一个进程开始执行分配给一个组。进程的第一个线程最初在进程分配到的组中运行。每个新创建的线程都被分配到与创建它的线程相同的组中。
从 Windows 11 和 Windows Server 2022 开始，应用程序不再默认受限于单个处理器组。相反，进程及其线程具有处理器亲缘关系，默认情况下跨越系统中的所有处理器，跨越具有超过 64 个处理器的机器上的多个组。这意味着应用程序不再需要显式设置其线程的关联性来访问多个处理器组。
https://docs.microsoft.com/en-us/windows/win32/procthread/processor-groups
云服务器cpu的维度：底层母机层面的物理cpu分布情况 → 虚拟机OS层面的vcpu分布情况(socket → node → core → thread → groupsize)
