We overprovision with 2:1 (to logical cores) on our shared KVM openstack - even when used highly with automation jobs, but memory overprovisioning we avoid.
I love overprovisioning, running a Ryzen 3 2200G (16GB) with Virtualbox. I always assign all 4 CPUs to a VM with as only exceptions older VMs like e.g. Windows XP Home. I do it since 2019 and I never had any issue running 2 to 4 VMs at the same time all with 4 CPUs assigned. I was perfectly happy with the behavior of the Linux kernel of the Host, it effectively assigns all processes to the 4 physical CPUs. I only have problems, when I overprovision memory and the system start swapping. The first 2GB it swaps to my nvme-SSD partition and that is still fine. Afterwards it swaps to the HDD and then I seriously consider to kill a VM :( :). The system is loaded heavily, when I start to run the updates for my 34 VMs, still needing updates. I can run 2 or 3 VMs at the same time, since in this way the Host can use the CPU idle time effectively for another VM and my total update elapse time is reduced. The limit is basically my own multi-tasking ability at 77 :) However when I want to update Windows 11 Pro as fast as possible I run the update alone of course. By the way when I run the weekly VM OS updates, I also play the wma copies of my old LPs and CDs in Windows XP Home. To avoid seconds of silence and stuttering, when a post-XP Windows starts, I run Windows XP on high priority.
I notice that it's quite common these days to use threads and "cores" interchangeably i.e. a 12 core 24 thread CPU will be talked about as if it had 24 cores. Despite being technically inaccurate this obviously works perfectly well in practice - so I was wondering if there are any exceptions? Last time I took a deeper dive into threads vs cores (years ago!) I was soundly ticked off for "confusing" the two terms - so is it just the case that hyperthreading technology has just so drastically improved that it's a non-issue these days? For e.g. Presumably it's still a bad idea to assign odd numbers of threads?
Kind of a late response but just stumbled here. Basically HT/SMT is what is known as a branch prediction queue. I.e. the cpu core is what actually does work, nothing will get done on a system without it hitting an actual core. What HT/SMT does is open up a queue to accept commands to be processed by the actual core and try to preload or 'predict' certain calls. For applications that are memory resident you can get a decent amount of benefit for this as the core when done with it's current task has the new data to load in at hand. If however this 'prediction' is wrong (i.e. data that was preloaded is not valid anymore; the heuristic 'guessed' a wrong path, etc.) then the 'preload' work has to be thrown out and goes back to a normal operation. Now, Where this fails miserably is when there is any workload that requires a hardware interrupt (e.g. disk i/o; network i/o; audio i/o; whatever). Basically really anything that is not in memory. hardware interrupts /CANNOT/ be predicted and *must* allocate a core to handle their load. Which means that if you have say something on a core and a HT/SMT queue loaded that queue will be vacated / flushed and instead the interrupt will be handled. This wastes time (it takes time (higher latency) to flush and time to wait for the core to finish up whatever it's already working on). This is why, in high performance systems HT/SMT is disabled (or you get cpu's that don't support it); Likewise functions like power saving functions (C states) (usually > C1) are disabled as those take time; in addition for really latency sensitive apps even dynamic frequency (raising/lowering/changing/ cpu frequency) is also disabled as that also takes time (cycles). Home users generally do not utilize their computers enough to notice this and they generally are running apps that (once loaded) are in memory. If you are doing i/o (hardware interrupt tasks) like running large NAS/SAN/DAS; doing high speed routing/firewall; or even professional multi channel audio this becomes an issue.
Overprovisioning is only really an issue if you don't monitor your VMs and 1 Windows VM for some reason gets stuck using 100 of the CPU, and not the whole system is slow because of that.
I like watching your video's as I learn quite a bit (and have a lot more to learn) however, todays video was almost like foreign language to me. I'm just an old retired firefighter just trying to spend my days learning. On todays subject matter could you recommend a source I could go to learn more about it from the basics? If thats not possible or I don't know what I'm asking for just have a laugh and I'll keep watching.
I have 10 8 core virtual desktops + 7 6 core servers all sharing 16 cores, 32 threads. Everything works great because only rarely does a desktop need all 8 cores or servers need to use all 6 of their cores. High performance for all my users!
We use vmware at work. We have a bunch of servers we juse for our build pipe. Jenkins to be exact. Our servers have two CPUs in each. 12 cores and 24 threads in total per CPU. We have four VMs runing on each server. I've assigned all VMs all the CPUs available. So they technically have access to 48 threads. I might need to rethink this strategy. The thing is that we hardly ever run all of the VMs at the same time. We don't always need all of the builds at the same time so it felt like a waste to not give each and every VM all of the CPUs since they will essentially be idling then at those times when we only use one of the VMs to do our builds.
What happens when both VMs are set to use the max number of cores but each is only only running a single-threaded application? Does each VM need to wait for _all_ cores to be clear (meaning only 1 host CPU is used) or is a hypervisor able to "split" the VMs to let both run simultaneously and properly utilize 2 host cores? I haven't been able to find an answer to this question but it seems like it could be very important when provisioning cores.
Does this also apply to Windows servers, especially AD controllers? I may rethink how I was going to build my system and give more cores to each knowing that when they get shuffled off to a different host, things will be over provisioned. I'll have enough ram that each can have its own slice without conflict.
We overprovision with 2:1 (to logical cores) on our shared KVM openstack - even when used highly with automation jobs, but memory overprovisioning we avoid.
I love overprovisioning, running a Ryzen 3 2200G (16GB) with Virtualbox. I always assign all 4 CPUs to a VM with as only exceptions older VMs like e.g. Windows XP Home. I do it since 2019 and I never had any issue running 2 to 4 VMs at the same time all with 4 CPUs assigned. I was perfectly happy with the behavior of the Linux kernel of the Host, it effectively assigns all processes to the 4 physical CPUs.
I only have problems, when I overprovision memory and the system start swapping. The first 2GB it swaps to my nvme-SSD partition and that is still fine. Afterwards it swaps to the HDD and then I seriously consider to kill a VM :( :).
The system is loaded heavily, when I start to run the updates for my 34 VMs, still needing updates. I can run 2 or 3 VMs at the same time, since in this way the Host can use the CPU idle time effectively for another VM and my total update elapse time is reduced. The limit is basically my own multi-tasking ability at 77 :) However when I want to update Windows 11 Pro as fast as possible I run the update alone of course.
By the way when I run the weekly VM OS updates, I also play the wma copies of my old LPs and CDs in Windows XP Home. To avoid seconds of silence and stuttering, when a post-XP Windows starts, I run Windows XP on high priority.
As usual, it depends(tm) :)
I notice that it's quite common these days to use threads and "cores" interchangeably i.e. a 12 core 24 thread CPU will be talked about as if it had 24 cores. Despite being technically inaccurate this obviously works perfectly well in practice - so I was wondering if there are any exceptions? Last time I took a deeper dive into threads vs cores (years ago!) I was soundly ticked off for "confusing" the two terms - so is it just the case that hyperthreading technology has just so drastically improved that it's a non-issue these days? For e.g. Presumably it's still a bad idea to assign odd numbers of threads?
This is going to get more confusing in the future is the CPU's that have different core types get popular.
Kind of a late response but just stumbled here. Basically HT/SMT is what is known as a branch prediction queue. I.e. the cpu core is what actually does work, nothing will get done on a system without it hitting an actual core. What HT/SMT does is open up a queue to accept commands to be processed by the actual core and try to preload or 'predict' certain calls. For applications that are memory resident you can get a decent amount of benefit for this as the core when done with it's current task has the new data to load in at hand. If however this 'prediction' is wrong (i.e. data that was preloaded is not valid anymore; the heuristic 'guessed' a wrong path, etc.) then the 'preload' work has to be thrown out and goes back to a normal operation. Now, Where this fails miserably is when there is any workload that requires a hardware interrupt (e.g. disk i/o; network i/o; audio i/o; whatever). Basically really anything that is not in memory. hardware interrupts /CANNOT/ be predicted and *must* allocate a core to handle their load. Which means that if you have say something on a core and a HT/SMT queue loaded that queue will be vacated / flushed and instead the interrupt will be handled. This wastes time (it takes time (higher latency) to flush and time to wait for the core to finish up whatever it's already working on). This is why, in high performance systems HT/SMT is disabled (or you get cpu's that don't support it); Likewise functions like power saving functions (C states) (usually > C1) are disabled as those take time; in addition for really latency sensitive apps even dynamic frequency (raising/lowering/changing/ cpu frequency) is also disabled as that also takes time (cycles). Home users generally do not utilize their computers enough to notice this and they generally are running apps that (once loaded) are in memory. If you are doing i/o (hardware interrupt tasks) like running large NAS/SAN/DAS; doing high speed routing/firewall; or even professional multi channel audio this becomes an issue.
Overprovisioning is only really an issue if you don't monitor your VMs and 1 Windows VM for some reason gets stuck using 100 of the CPU, and not the whole system is slow because of that.
Good info thanks
I like watching your video's as I learn quite a bit (and have a lot more to learn) however, todays video was almost like foreign language to me. I'm just an old retired firefighter just trying to spend my days learning. On todays subject matter could you recommend a source I could go to learn more about it from the basics? If thats not possible or I don't know what I'm asking for just have a laugh and I'll keep watching.
Google virtualization CPU over provisioning and head down that rabbit hole
@@LAWRENCESYSTEMS Thank you for indulging me.
I have 10 8 core virtual desktops + 7 6 core servers all sharing 16 cores, 32 threads. Everything works great because only rarely does a desktop need all 8 cores or servers need to use all 6 of their cores. High performance for all my users!
I think it is time to compare different virtualisation platforms
How do you get those sweet sweet icons in the names on the VM?? lol ... love your vids keep up the epic work!!
They are just emojis
@@LAWRENCESYSTEMS lol well now i feel a bit dumb .. thanks brotha
We use vmware at work. We have a bunch of servers we juse for our build pipe. Jenkins to be exact. Our servers have two CPUs in each. 12 cores and 24 threads in total per CPU. We have four VMs runing on each server. I've assigned all VMs all the CPUs available. So they technically have access to 48 threads. I might need to rethink this strategy. The thing is that we hardly ever run all of the VMs at the same time. We don't always need all of the builds at the same time so it felt like a waste to not give each and every VM all of the CPUs since they will essentially be idling then at those times when we only use one of the VMs to do our builds.
What happens when both VMs are set to use the max number of cores but each is only only running a single-threaded application? Does each VM need to wait for _all_ cores to be clear (meaning only 1 host CPU is used) or is a hypervisor able to "split" the VMs to let both run simultaneously and properly utilize 2 host cores? I haven't been able to find an answer to this question but it seems like it could be very important when provisioning cores.
No it will not put the unused cores into a wait state.
Does this also apply to Windows servers, especially AD controllers? I may rethink how I was going to build my system and give more cores to each knowing that when they get shuffled off to a different host, things will be over provisioned. I'll have enough ram that each can have its own slice without conflict.
Yes
What software was the dashboard/interface with all the gauges?
Netdata ruclips.net/video/Hsq6ebnzPtI/видео.html
@@LAWRENCESYSTEMS Awesome. Thank you
Tom: XCP-NG or ESXi for homelab? I've never used XCP-NG but now my server is 11y old and not supported in ESXi8..
pfSense, unRAID, Ubuntu server and first two use hw passtrough.
I prefer XCP-NG
Can you apply the same theory to ESXI?
Pretty much yes
Yes and others.