Howdy, Stranger!

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

Sign In with OpenID
Advertise on LowEndTalk.com

In this Discussion

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

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"

Tagged:

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"

  • ZenZen Member

    Automated monitoring is always a bonus, but generally I've seen providers are in some way constantly monitoring the nodes whenever they're online. I definitely think that automation for resource abuse is the way forward, given that it provides so much flexibility and stops you from having to be tethered to top :)

    Transparency: I work for Nodisto and all subsequent businesses: Backupsy, VPSDime, Winity, Cloudive, and DotVPS. My opinions represented through posts on this forum are mine and not the opinions of these businesses unless explicitly stated otherwise.
  • jarlandjarland Member
    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.me | Read about my new hosting experiment.

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

    "Go cheap on rarely used things"

  • ZenZen Member

    @jarland said: 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.

    You just gave me an idea on logging actions that the monitoring script would take, so that I could do analysis on what the real issues are, bypassing need for what you mentioned above! :)

    I imagine something like this :

    00:19:58 - CPU Abuse (13.8 Load Average) ID 239 Warned 00:22:58 - CPU Abuse (17.3 Load Average) ID 239 Suspended

    Warning system would be cool, echo something into their container using VZCTL as a warning in case they're actively on the VPS.

    Transparency: I work for Nodisto and all subsequent businesses: Backupsy, VPSDime, Winity, Cloudive, and DotVPS. My opinions represented through posts on this forum are mine and not the opinions of these businesses unless explicitly stated otherwise.
    Thanked by 1jarland
  • 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.

    I am no longer affiliated with IPXcore.
  • @Zen said: You just gave me an idea on logging actions that the monitoring script would take, so that I could do analysis on what the real issues are, bypassing need for what you mentioned above! :)

    I imagine something like this :

    00:19:58 - CPU Abuse (13.8 Load Average) ID 239 Warned 00:22:58 - CPU Abuse (17.3 Load Average) ID 239 Suspended

    Warning system would be cool, echo something into their container using VZCTL as a warning in case they're actively on the VPS.

    http://www.lowendtalk.com/discussion/2882/script-stop-container-if-loadavg-is-x

    I'm sure you can make it better :)

  • jarlandjarland Member
    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...

    jarland.me | Read about my new hosting experiment.

  • ZenZen Member

    @Damian said: 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.

    Will work on something like this over the next few days.. :)

    Transparency: I work for Nodisto and all subsequent businesses: Backupsy, VPSDime, Winity, Cloudive, and DotVPS. My opinions represented through posts on this forum are mine and not the opinions of these businesses unless explicitly stated otherwise.
  • Automated scripts FTW! :)

Sign In or Register to comment.