Itll use the total amount of "cores" the system has. Since the processor has Hyperthreading your core count will be the thread count.
If you have this a Uniproc configuration, you will have 44 threads (22cores, 2 way SMT = 44 threads) or in a Dualproc config, that'll be 88.
Depending on your hypervisor and the VM CPU configuration itll manage which thread(s) to use.
With shared CPU resources, you should have some sort of fair use policy. Eg, if a client wants to use 100% of their vcores for a prolonged period but theyre not dedicated you should suspend the VM state so the rest of your clients dont get a high rate of CPU steal(and performance hits).
You should also have some sort of headroom for the hypervisor to run as well.
Can be 44 dedicated vCores, or anything between 66 and 176 shared/fair use/[whatever euphemism] vCores. And I've seen even worse.
But don't forget to include n x ? GB disk space ('n' being the number of vCores you go for and '?' being the size of each), or n x 2 x ? GB, if you don't want to play lottery with your customers data, n x ? GB RAM, and n x ? GB traffic in your calculations!
At the end of the day it's a question of balancing out the node cost (plus infrastructure, service&support!) plus having a margin - or, in other words how to slice your node up so as to have a tasty offer and still make some profit.
Comments
Nice processor.
It depends, do you want to sell DEDICATED vCores or SHARED vCores?
How companies sale? It just mention 2 vCores, 4 vCores.
>
Usually they are SHARED vCores. Assigning a dedicated vCore for each Customer is costly, expensive.
You could sell about 65 VPS using a 0.7x ratio of CPU sharing which is really good.
How 65 vps will be created with this processor.
It will use threads or a physics core?
As i saw on google. Physical x threads = virtual cores
Itll use the total amount of "cores" the system has. Since the processor has Hyperthreading your core count will be the thread count.
If you have this a Uniproc configuration, you will have 44 threads (22cores, 2 way SMT = 44 threads) or in a Dualproc config, that'll be 88.
Depending on your hypervisor and the VM CPU configuration itll manage which thread(s) to use.
With shared CPU resources, you should have some sort of fair use policy. Eg, if a client wants to use 100% of their vcores for a prolonged period but theyre not dedicated you should suspend the VM state so the rest of your clients dont get a high rate of CPU steal(and performance hits).
You should also have some sort of headroom for the hypervisor to run as well.
How do you exactly calculated the ratios?
45 upwards.
Can be 44 dedicated vCores, or anything between 66 and 176 shared/fair use/[whatever euphemism] vCores. And I've seen even worse.
But don't forget to include n x ? GB disk space ('n' being the number of vCores you go for and '?' being the size of each), or n x 2 x ? GB, if you don't want to play lottery with your customers data, n x ? GB RAM, and n x ? GB traffic in your calculations!
At the end of the day it's a question of balancing out the node cost (plus infrastructure, service&support!) plus having a margin - or, in other words how to slice your node up so as to have a tasty offer and still make some profit.
It depends on how do you plan to earn from a server
At least 44, since you get 2 threads per core