New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Name the provider, his competence must be scrutinized. According to him you steal from your-self.
tag the host
The host is @AvenaCloud
Ticket in question: https://imgur.com/a/WOE4iHK
Blatant heavy overselling and lie directly to customers eye. Pack your crap and move along, provider is incompetent and this may end in data loss.
That's sad, they even claim that the CPU core is dedicated
I want to know if it is the same now?
Why am I asking, because in the ticket I clarified that there is a problem with one of the nodes, after migrating the server (vps) to another node, the problem disappeared and the node with problems was replaced with another one.
I can write with certainty that this problem has been solved.
Still have the same issue. Fresh screenshot:
Please write the last digits of the IP so I can check, or write a replay to the ticket.
x.x.19.183
screenshot does not agree with your certainty
Please check now, and if everything is fine, I will write in the ticket what happened to your server.
Here is a particular problem with this server.
Yeah seems good now.
What had happened?
Am I at least the daddy?
well, seems they have unloaded the node, to reduce server load.
or they wrongly connected the cable, and now they have connected the cable correctly.
No, the node is not loaded and the cable is not to blame either. Especially since each node is connected to the sfp+ port (10Gbps), the cable has no problem.
It is solved now, that's what matters I guess
Seems I got here too late to say that that's exactly what artificial limiting looks like, (i.e. where the hypervisor is only allocated XX% of a vCPU).
However the 30% steal is consistent with the Provider limiting your vCPU to 0.7 because the hypervisor will consistently steal back the % of vCPU resources that aren't allocated so it checks out
Were you limiting the cpu resource allocation?
Yes or No, please.
We have a monitoring platform that checks each server separately in the cluster and if it exceeds 95th over a longer period, yes, the platform starts to decrease the vCPU bit by bit. In this case, it dropped to 0.7. We have already started removing these rules because it doesn't seem to help.
CPU usage is 50-100%, ST is roughly 30-50
But in the ticket you mentioned that overall cpu load on the node was in 45% range.
Did you advertise that VPS as dedicated cpu vCore?
It was advertised as dedicated.
For all VPSs, vCPUs are dedicated, just like memory and disk, everything is dedicated and not shared. We use KVM virtualization for VPSs, better said VDS and not OpenVZ or LXC. KVM virtualization completely separates the resources of the VPS server from other servers on the node in the cluster.
The one I wrote about 45% was about how much the physical processors were loaded on the node.
Probably, @AvenaCloud will claim that it was dedicated but not 100%, just 10%
You are losing your credibility faster than cpu steal rate.
Unfortunately, this whole procedure was done because of some clients who used the VPS illegally. But it is not possible to manually monitor all VPSs.
I mentioned earlier that our colleagues have already started correcting the rules and removing the limits from automations. We will deal differently with servers that are being misused.
would you mind giving me a test VPS for 3 days?
I would like to run through my tests.
-- I play with numbers for living