But then you would not see all those containers in /proc/cgroups? Slabbing implies you are basically virtualizing your OpenVZ nodes which in turn would effectively "hide" containers running in the other slabs.
How To: Determining how many 'VPS neighbors' you have or if you are on an oversold OpenVZ node
- Thread starter MannDude
- Start date
MustardMan must be a VPS hosting provider based on activity on LXCenter's forum and this comment:
I can understand why a provider may not want this information known however I can not fathom why an end-user would want it unknown.
If you believe it should be listed as a feature, and not a bug, please respond to the report here ( https://bugzilla.openvz.org/show_bug.cgi?id=3234).
I don't see how this is any different than checking the CPU information with "cat /proc/cpuinfo" for example. It's simply a transparency feature that would allow end users to help diagnose VPS issues. A good example of it's use would be performance benchmarks and reviews. If you continually have piss-poor performance as an end-user and use it with other commands that reveal hostnode information it could help you determine that you chose a provider who has oversold their node significantly.
Of course, if I had it my way you would be able to determine the hostnode's actual RAM vs RAM allocated to containers and disk space stats.
I can understand why a provider may not want this information known however I can not fathom why an end-user would want it unknown.
If you believe it should be listed as a feature, and not a bug, please respond to the report here ( https://bugzilla.openvz.org/show_bug.cgi?id=3234).
I don't see how this is any different than checking the CPU information with "cat /proc/cpuinfo" for example. It's simply a transparency feature that would allow end users to help diagnose VPS issues. A good example of it's use would be performance benchmarks and reviews. If you continually have piss-poor performance as an end-user and use it with other commands that reveal hostnode information it could help you determine that you chose a provider who has oversold their node significantly.
Of course, if I had it my way you would be able to determine the hostnode's actual RAM vs RAM allocated to containers and disk space stats.
Last edited by a moderator:
Munzy
Active Member
https://twitter.com/mustardman296/followers
https://bugzilla.openvz.org/show_bug.cgi?id=2069
https://bugzilla.openvz.org/show_bug.cgi?id=1990
https://bugzilla.openvz.org/show_bug.cgi?id=2019
http://forum.lxcenter.org/index.php?t=msg&goto=72013&
https://productforums.google.com/forum/#!msg/drive/2YX9UPDuExw/5yAT6HTyKIgJ
https://bugzilla.openvz.org/show_bug.cgi?id=2069
https://bugzilla.openvz.org/show_bug.cgi?id=1990
https://bugzilla.openvz.org/show_bug.cgi?id=2019
http://forum.lxcenter.org/index.php?t=msg&goto=72013&
https://productforums.google.com/forum/#!msg/drive/2YX9UPDuExw/5yAT6HTyKIgJ
Yep, it's being discussed in the last several comments.
I'd like to think of it as more of a useful feature than a bug, but will likely not be able to sway devs and providers to feel the same way.
A new kernel was released this morning to patch this and it's released as a security fix so I'm wondering if KernelCare/Ksplice will treat it like so and providers won't even need to reboot to fix it.
Now for a quick little rant that most of you probably won't agree with...
Everybody here should know by now that I am all for transparency and honesty (which leads to trust) but at the same time I am all for businesses to be allowed to make their own decisions about how transparent or honest they want to be. If clients ask me an exact number of VPSs on any given node, I won't tell them because the number is irrelevant and means nothing to them and the only thing it would do is scare away new clients who see a number over 20 and go "OMG my disk IO will be in the KB/s, my network speed will be slower than dial-up, and the CPUs are probably maxed out 24x7" not even bothering to look at our server status page or read reviews. For current clients, they could use that number as an excuse where it doesn't belong "My VPS is running slow now and it will never get better because that's expected when you have X VPSs on a node, time to cancel" not even bothering to check if there's a hardware issue or something minor that we are working on. Do we advertise that we don't oversell? No we don't, we explain it right in our FAQ.
Luckily there are a ton of clients and knowledgeable people on this forum who understand that overselling != diminished performance, unfortunately for every one of those there are thousands that don't understand that and thus why advertising the population of a node is not beneficial to a VPS provider who's business relies on sales from the general public where the vast majority aren't very technically inclined and will quickly judge a company based on the negatives of the virtualization used (i.e. OpenVZ is always oversold and companyA has X VPSs per node so they are more oversold than companyB even though the real numbers don't add up). Imagine if there was a website that listed all of the VPS providers and the number of VPSs per node, now imagine John Q visits that website and sees a provider they used that really sucked performance-wise with 100 VPSs per node. They look for another provider and find a really nice one but they have 101 VPSs per node and John remembers how bad the performance was with 100 VPSs per node so they don't even bother to see that the new provider doesn't sell 2GB plans for $12/year and doesn't use the a bargain bin special OVH server.
The bottom line is that the number of VPSs per node has no impact on anything and cannot be used to quantify anything performance-wise. All you have is a number out of context of anything and will mean different things for different providers. If the number was broken down to show you have much RAM and disk space each VPS got, then you could see how oversold a node is but even that doesn't give you a view point of the server's performance. Now if the number was broken down by CPU, RAM/swap, or disk IO usage, then you can get an idea of how over/underworked the server is, but you could see that by using your VPS for a while and gauging the responsiveness and running benchmarks. I guess you can use the number to keep track of a company's sales or turnover, but that's not something most companies are willing to disclose either.
For us vpsBoarders, that number is a neat metric but nothing else. Instead of wanting to see the number of VPSs per node, try the VPS in the real world and see if it fits your needs or not instead of relying on a number to calculate it for you.
Now for a quick little rant that most of you probably won't agree with...
Everybody here should know by now that I am all for transparency and honesty (which leads to trust) but at the same time I am all for businesses to be allowed to make their own decisions about how transparent or honest they want to be. If clients ask me an exact number of VPSs on any given node, I won't tell them because the number is irrelevant and means nothing to them and the only thing it would do is scare away new clients who see a number over 20 and go "OMG my disk IO will be in the KB/s, my network speed will be slower than dial-up, and the CPUs are probably maxed out 24x7" not even bothering to look at our server status page or read reviews. For current clients, they could use that number as an excuse where it doesn't belong "My VPS is running slow now and it will never get better because that's expected when you have X VPSs on a node, time to cancel" not even bothering to check if there's a hardware issue or something minor that we are working on. Do we advertise that we don't oversell? No we don't, we explain it right in our FAQ.
Luckily there are a ton of clients and knowledgeable people on this forum who understand that overselling != diminished performance, unfortunately for every one of those there are thousands that don't understand that and thus why advertising the population of a node is not beneficial to a VPS provider who's business relies on sales from the general public where the vast majority aren't very technically inclined and will quickly judge a company based on the negatives of the virtualization used (i.e. OpenVZ is always oversold and companyA has X VPSs per node so they are more oversold than companyB even though the real numbers don't add up). Imagine if there was a website that listed all of the VPS providers and the number of VPSs per node, now imagine John Q visits that website and sees a provider they used that really sucked performance-wise with 100 VPSs per node. They look for another provider and find a really nice one but they have 101 VPSs per node and John remembers how bad the performance was with 100 VPSs per node so they don't even bother to see that the new provider doesn't sell 2GB plans for $12/year and doesn't use the a bargain bin special OVH server.
The bottom line is that the number of VPSs per node has no impact on anything and cannot be used to quantify anything performance-wise. All you have is a number out of context of anything and will mean different things for different providers. If the number was broken down to show you have much RAM and disk space each VPS got, then you could see how oversold a node is but even that doesn't give you a view point of the server's performance. Now if the number was broken down by CPU, RAM/swap, or disk IO usage, then you can get an idea of how over/underworked the server is, but you could see that by using your VPS for a while and gauging the responsiveness and running benchmarks. I guess you can use the number to keep track of a company's sales or turnover, but that's not something most companies are willing to disclose either.
For us vpsBoarders, that number is a neat metric but nothing else. Instead of wanting to see the number of VPSs per node, try the VPS in the real world and see if it fits your needs or not instead of relying on a number to calculate it for you.
Last edited by a moderator:
The mixed feelings on this are totally cool, and expected, really. I actually agree with a lot of what Joe said.
I just wish we had a happy medium...just some little way of saying "Yes, we run OVZ but we're not being blatant f***ing idiots about the number of containers running on our nodes." Yada, yada, yada...
I just wish we had a happy medium...just some little way of saying "Yes, we run OVZ but we're not being blatant f***ing idiots about the number of containers running on our nodes." Yada, yada, yada...
Exactly. I've been using OpenVZ since 2006. Sadly, you ask the random person on VPSBoards, LET, WHT, or any other community which virtualization technology is the worst, and most of them will say OpenVZ. Then you ask them why? "Because the host can oversell" is the common response.
I constantly have to explain to people that every technology can be oversold (and have been doing so since ~2008). The difference with OpenVZ is OS-level virtualization (containerization) is more efficient so it actually performs better when two nodes are equally oversold. The low requirements of a container just allow for more containers per node than virtual machines.
This has become an issue because providers that have oversold to the extreme have used OpenVZ and dragged the technology's name through the dirt. Back in the day, Xen didn't allow for memory and disk overselling and some people still to this day think that virtual machines can't be oversold. Even back then, they could oversell disk I/O, CPU, network I/O, etc.
So if the companies putting 1000 containers on a box are outed, they probably deserved it because it is companies like that that have destroyed OpenVZ's reputation.
Last edited by a moderator:
There are actually a few commands you can throw at a container that can tell you whether or not it's nested inside Xen/KVM, but that can be for a rainy day or something.
Last edited by a moderator:
Exactly! The common people has no clue Xen has been able to be oversold for a long time now...all a different couple ways too. Though you mostly need the know-how to even perform this, so it's still better then Joe Smo overselling his 32GB E3 with 100+ customers hehe.
drmike
100% Tier-1 Gogent
Well I agree, but do take some slight issues with this.
OVZ only has industry traction based on offer price. Show me some mega cheap annuals for $5-10 on KVM/Xen/etc.? They are ALL OpenVZ, won't find the others. Someone wants to offer such on other virtualizations, they would likely do well. If they can manage oversell and implications in other virtualization.
A container count does speak to level a provider is going to monetize their server. There are reasonable loading levels and reasonable income per U numbers. Calling this optimizing resources is being borderline dishonest based on who I am conversing with and their actual knowledge level.
You get some of these container counts we have have seen 600-1600 on a server and I fail to see how such could perform even at an acceptable level. Only math at play there is scores of idle containers online, but sitting with no real use - only way such is viable as a loading stunt. Even those better be running on an E5 to make it believable.
When I see those numbers I think what an insane customer base; buyers that just idle. Those customer bases can only be one thing - extremely cheap, call it laughable cost annuals and very small plans at that.
I wonder how many companies charging $10GB of RAM or more are so heavily loading nodes to be embarrassed if such was made public? Those are the shops I worry about as people actually host business type stuff there (as where the el cheapo stuff is hobby sandboxing).
Arguably nothing can be used to quantify performance other than overall customer in container perception. It's counter productive to the industry and providers who actually understand the technology. Top level full server CPU, RAM/swap, disk IO, disk IOWAIT, etc. could give time in place snapshot view, but even that is flawed - need some graphing over long time periods to make sane sense and be believable. This I hope becomes the normal approach for companies claiming transparency and wanting to run a good shop.