To resolve the situation described and prevent any potential performance impact, you can take one of the following actions:
- Revert the cores-per-socket setting to its default,
or
- Proceed with the advanced configuration, keeping in mind the considerations outlined below:
Guest operating system schedulers and applications often optimize workloads according to the underlying hardware topology. In some cases, these optimizations place worker threads within the same socket and avoid migrating threads across sockets to reduce latency caused by cross-socket memory access. For larger VMs (for example, those configured with 32 vCPUs), the default configuration of one core per socket may not be ideal or practical depending on the system design.
This behavior has been observed across a wide range of workloads, including large-scale databases, enterprise applications, and micro-benchmark tests.