Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Advertise on LowEndTalk.com
How do you minimize impact of bad neighbours on shared resources?
New on LowEndTalk? Please Register and read our Community Rules.

How do you minimize impact of bad neighbours on shared resources?

craigbcraigb Member
edited October 2012 in Providers

Reading comments in offer threads it seems some providers do a much better job than others on handling customers that are "bad neighbours"...those peeps who's resource consumption patterns cause more than occasional slowdowns for everyone else.

Obviously different virt/container tech leads to different resource mgmt implementations...as a customer I'm curious what tools you have at your disposal and how quickly you can consistently identify and manage contention so that other customers on the same node experience less impact than if its left unchecked.

"Go cheap on rarely used things"

Comments

  • top
    ps ef | grep xxx

    As simple as that with KVM (For CPU abuse at least).

  • Two ways:
    1. Put less neighbors on a server.
    2. Price/target/promote your services in such a way that the bad apples prefer to go elsewhere.

    -

  • Ash_HawkridgeAsh_Hawkridge Member
    edited October 2012

    @rds100 said: Two ways:

    1. Put less neighbors on a server.
    2. Price/target/promote your services in such a way that the bad apples prefer to go elsewhere.

    +1 and manual fraud checks performed by a human!

    We dont use maxmind, instead a combination of common sense, google maps and geoip. We haven't had a single abuse report, suspension or chargeback since opening.

    I wish i could say the same for the days of instant setup/OpenVZ @ VMPort.

  • @GetKVM_Ash said: chargeback since opening

    You had one from me :P although it was accidental and I repaid it :)

    Like the simple new site, there's a few bugs though!

  • @AsadHaider said: You had one from me :P although it was accidental and I repaid it :)

    Like the simple new site, there's a few bugs though!

    Ah yeah haha. It wasn't a genuine chareback though :P

    Thank you, send me a PM regarding the bugs please, i will get them sorted.

  • fanfan Member
    edited October 2012

    Misunderstood the post, please just ignore this.

  • @GetKVM_Ash thanks. Do you find manual monitoring of tenants resource usage sufficient to pick up unsociable VPS tenants?

    "Go cheap on rarely used things"

  • jarjar Provider
    edited October 2012

    Personally speaking, I rely mostly on my eyes. We're a small operation, I'm not foolish enough to think that I'm going to be able to do this forever. I do have some light automation that I use when I sleep, but taking this time to manually do the work is important because it allows me to see with my own eyes what the common issues are. That allows for better automation as we grow. I think it is important that each host approach this in their own way, this is really your unspoken selling point.

  • @jarland thanks. agree with the implication that scale tends to drive the need for heavier automation.

    "Go cheap on rarely used things"

  • That's a good idea. The only issue I see with it is if a single process in one container is maxing out one CPU core. That's fine on a multi-core system, but what if you get more users doing that than you have cores available?

    May need to add another factor: number of minutes (or seconds) a process spends above 95% utilization of one core.

  • jarjar Provider
    edited October 2012

    @Damian said: That's fine on a multi-core system, but what if you get more users doing that than you have cores available?

    This is an interesting one. Personally I'd cut it in half and limit each process to 50% of a core using cpulimit and then notify the clients. Hopefully though most of us keep the number of available slots as a bit of a variable based on the usage of the clients on the machine while still generating enough profit from a worst case scenario. Of course, you can never be certain that all of your clients won't wake up tomorrow and decide to slam the node. Always a balancing act. Would be interesting to script that scenario...

  • KuJoeKuJoe Member, Provider

    Automated scripts FTW! :)

    -Joe @ SecureDragon - LEB's Powered by Wyvern in FL, CO, CA, IL, NJ, GA, OR, TX, and AZ
    Need backup space? Check out BackupDragon
Sign In or Register to comment.