• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

Overprovisioning cpu cores...

/dev/null

/dev/null

[H]F Junkie
Joined
Mar 31, 2001
Messages
15,181
What is a safe limit?

I've got a bunch of vms (12?) mostly with 1 cpu core and 16G ram on a Phen2 965 running KVM.

I've only got 1 interactive box (desktop OS) and 2-3 somewhat realtime (asterisk server, firewalls...)

At what point should I be looking at more cores? 1090's aren't all that expensive and BD 8 core should be out within the next month or two.
 
Well, IMO, the asterisk server is more real-time except anything else (except maybe the firewall.)
 
No real rule....really up to workload and utilization. Keep stacking until peak performance isn't satisfactory.
 
NetJunkie said:
No real rule....really up to workload and utilization. Keep stacking until peak performance isn't satisfactory.
Click to expand...

Agreed. Keep an eye on CPU ready if performance gets crappy. Do a google search on that stat, because viewing from ESXTOP is not the same as viewing through the vSphere Client's performance graphs. ESXTOP will show you a percentage per interval where the vSphere Client will show you a summation of the latency in miliseconds per interval. ESXTOP has a tighter interval frequency, in fact I use '2' seconds which I believe is the lowest it can go. The vSphere Client's real time stats intervals are 20 seconds apart, which is too far apart I think when talking about CPU stats.

As for ESXTOP, rule of thumb is 10% CPU ready per 2 second interval in ESXTOP. Remember that's 10% per vCPU, so remember to divide per vCPU if a VM is using vSMP.
 
defuseme2k said:
Agreed. Keep an eye on CPU ready if performance gets crappy. Do a google search on that stat, because viewing from ESXTOP is not the same as viewing through the vSphere Client's performance graphs. ESXTOP will show you a percentage per interval where the vSphere Client will show you a summation of the latency in miliseconds per interval. ESXTOP has a tighter interval frequency, in fact I use '2' seconds which I believe is the lowest it can go. The vSphere Client's real time stats intervals are 20 seconds apart, which is too far apart I think when talking about CPU stats.

As for ESXTOP, rule of thumb is 10% CPU ready per 2 second interval in ESXTOP. Remember that's 10% per vCPU, so remember to divide per vCPU if a VM is using vSMP.
Click to expand...

Is there an equivalent for KVM?

top - 11:44:11 up 11 days, 15:08, 1 user, load average: 0.27, 0.19, 0.16
Tasks: 149 total, 2 running, 147 sleeping, 0 stopped, 0 zombie
Cpu0 : 0.3%us, 0.3%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu1 : 7.8%us, 16.1%sy, 0.0%ni, 76.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu2 : 17.0%us, 5.8%sy, 0.0%ni, 77.2%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Cpu3 : 0.7%us, 0.0%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 16436564k total, 12369968k used, 4066596k free, 240548k buffers
Swap: 7733244k total, 0k used, 7733244k free, 2904860k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2715 root 20 0 691m 518m 1744 S 6 3.2 1156:34 kvm
2682 root 20 0 627m 514m 1612 S 4 3.2 659:26.99 kvm
2799 root 20 0 1208m 1.0g 1848 R 4 6.5 698:56.76 kvm
2764 root 20 0 373m 264m 1628 S 3 1.6 628:31.39 kvm
7820 root 20 0 4461m 2.9g 1936 S 3 18.2 34:55.21 kvm
2785 root 20 0 2338m 1.1g 1916 S 3 7.3 419:03.56 kvm
3239 root 20 0 627m 519m 1616 S 3 3.2 454:26.37 kvm
2741 root 20 0 778m 414m 1760 S 2 2.6 413:28.87 kvm
2656 root 20 0 0 0 0 S 0 0.0 3:27.14 rpciod/3
2728 root 20 0 780m 524m 1764 S 0 3.3 31:08.19 kvm
26332 root 20 0 19008 1224 868 R 0 0.0 0:00.01 top
1 root 20 0 10364 744 616 S 0 0.0 0:05.50 init
2 root 20 0 0 0 0 S 0 0.0 0:00.00 kthreadd
3 root 20 0 0 0 0 S 0 0.0 0:02.23 ksoftirqd/0
Click to expand...
 
I would start with the basic 'top' command in linux and go from there. Sounds like it isn't that different from esx's top? At least to get an idea of the loading and such...
 
Robstar, do you ever get complaints about call quality on the virtualized asterisk? My only remaining physical host (not on my all in one) is a small atom unit that runs pbxinaflash. I've been afraid to move that to the virtualized environment, since even a small amount of added latency can be very noticeable on calls. I suppose the firewall/gateway would be too, but not as much, since it is just packet switching.
 
danswartz said:
Robstar, do you ever get complaints about call quality on the virtualized asterisk? My only remaining physical host (not on my all in one) is a small atom unit that runs pbxinaflash. I've been afraid to move that to the virtualized environment, since even a small amount of added latency can be very noticeable on calls. I suppose the firewall/gateway would be too, but not as much, since it is just packet switching.
Click to expand...

Nope. Mostly myself, my wife, and her relatives use it. With that being said, I configured all system phones and asterisk so there is _no_ transcoding of audio.

I had stuttering in a very early version of the free "vmware server" under linux a few years ago but I imagine the newer esxi is much much better.

At any one time, 3-20 sip accounts are connected. I also have it connected to an outside provider to receive inbound calls from POTS as well as make outbound calls to POTS. Works great.

A KEY NOTE: We actually find it faster dialing & less latency than pots<->pots as my wifes relatives are in Brazil. POTS is SO SLOW to make a connection...sometimes 10 seconds or more.
 
You must log in or register to reply here.
Back
Top