4 ms·

"Noisy neighbors: sometimes instances would behave much slower than usual, because other people on the same hypervisor were using all the hypervisor’s resources

"Noisy neighbors: sometimes instances would behave much slower than usual, because other people on the same hypervisor were using all the hypervisor’s resources" The Xen hypervisor actually has pretty good resource allocation between virtual machines, and although there are academic attacks [1], I'm interested to hear what evidence you've seen of neighbors hogging your resources. [1] http://pages.cs.wisc.edu/~rist/papers/rfa.pdf http://pages.cs.wisc.edu/~rist/papers/rfa.pdf

badman_ting 13y ago
There are lots of people with noisy neighbor problems on AWS. Linking to a paper to say that's not the case just strikes me as weird.
- apawloski 13y ago
  No the paper is saying the opposite -- that this situation can be the case -- what I was interested in was hearing their evidence that this is happening to them.
- oz 13y ago
  With a username like 'badman_ting', you must be a fellow Jamaican :). How can I contact you? There's no email in your profile.
  - dopamean 13y ago
    Jamaicans of the world unite!
    - oz 13y ago
      :) What's your email? Remember that the email in your HN profile isn't visible to others.
      - dopamean 13y ago
        nickmcd at gmail
asdasf 13y ago
I think most "noisy neighbor" complaints actually come from the noisy neighbors. EC2 lets you use CPU resources of your neighbors if they aren't using them. So people hammer the machine and expect that level of performance, then when a neighbor does something and suddenly you are scaled back to only using the resources you actually pay for, you feel it is slow and complain. But I think if EC2 didn't let you borrow CPU, nobody would use it because they would realize how absurdly underpowered EC2 offerings really are.
- lsc 13y ago
  >But I think if EC2 didn't let you borrow CPU, nobody would use it because they would realize how absurdly underpowered EC2 offerings really are. yeah, that's pretty much the crux of virtualization; it's a lot like buying bandwidth. Yes, your upstream is oversubscribing. Yes, if they do this right, 99% of the time, you won't notice the oversubscribe; you will get more service for less money vs. something that isn't oversubscribed. But, oversubscription needs to be managed carefully. One thing I've noticed? If your upstream has a 1000mbps line, and sells 1000 unlimited 10Mbps ports, you are almost never going to see contention, even though it's a 10x oversubscribe. If your upstream has a 1000Mbps port, and sells 10 1000Mbps ports? that's the same 10x oversubscribe. But I /guarantee/ that you will hit contention at least once a week. Probably more often. If people expect 1000Mbps reliable off that, they will be very unhappy. (Of course, if you setup your QoS properly, and tell the customers that it's 100Mbps CIR and up to a gigabit of best-effort burst? it can work out just fine. But nobody is going to get a reliable full gigabit out of that deal.) 90% of your users are using like 10% of your resources. But you've always got a few who are running torrents (or, in the case of CPU, mining primecoins) In the 1000 10Mbps port situation? it doesn't really matter if you've got a few bittorrent users. In the 10 users who can all completely fill the pipe situation? it matters a /lot/ That's the thing about CPU sharing, though; most of the time you don't put that many guests on one machine, and often you give each guest the ability to use the whole machine (when it's otherwise idle) - so you are in the situation of selling 10 1000Mbps links when you only have 1 1000mbps uplink, which ends in tears if anyone actually expects a reliable 1000Mbps uplink. (Now, if everyone understands that it's actually 100Mbps CIR that can burst to 1000Mbps, then sure, people can be happy. but you have to be careful with those expectations. With the 1000 10Mbps links on a 1gbps uplink, customers can treat their 10Mbps link as 10Mbps dedicated, and 99% of the time, they will get what they expect.)

badman_ting 13y ago

There are lots of people with noisy neighbor problems on AWS. Linking to a paper to say that's not the case just strikes me as weird.

apawloski 13y ago
No the paper is saying the opposite -- that this situation can be the case -- what I was interested in was hearing their evidence that this is happening to them.
oz 13y ago
With a username like 'badman_ting', you must be a fellow Jamaican :). How can I contact you? There's no email in your profile.
- dopamean 13y ago
  Jamaicans of the world unite!
  - oz 13y ago
    :) What's your email? Remember that the email in your HN profile isn't visible to others.
    - dopamean 13y ago
      nickmcd at gmail

asdasf 13y ago

I think most "noisy neighbor" complaints actually come from the noisy neighbors. EC2 lets you use CPU resources of your neighbors if they aren't using them. So people hammer the machine and expect that level of performance, then when a neighbor does something and suddenly you are scaled back to only using the resources you actually pay for, you feel it is slow and complain. But I think if EC2 didn't let you borrow CPU, nobody would use it because they would realize how absurdly underpowered EC2 offerings really are.

lsc 13y ago
>But I think if EC2 didn't let you borrow CPU, nobody would use it because they would realize how absurdly underpowered EC2 offerings really are. yeah, that's pretty much the crux of virtualization; it's a lot like buying bandwidth. Yes, your upstream is oversubscribing. Yes, if they do this right, 99% of the time, you won't notice the oversubscribe; you will get more service for less money vs. something that isn't oversubscribed. But, oversubscription needs to be managed carefully. One thing I've noticed? If your upstream has a 1000mbps line, and sells 1000 unlimited 10Mbps ports, you are almost never going to see contention, even though it's a 10x oversubscribe. If your upstream has a 1000Mbps port, and sells 10 1000Mbps ports? that's the same 10x oversubscribe. But I /guarantee/ that you will hit contention at least once a week. Probably more often. If people expect 1000Mbps reliable off that, they will be very unhappy. (Of course, if you setup your QoS properly, and tell the customers that it's 100Mbps CIR and up to a gigabit of best-effort burst? it can work out just fine. But nobody is going to get a reliable full gigabit out of that deal.) 90% of your users are using like 10% of your resources. But you've always got a few who are running torrents (or, in the case of CPU, mining primecoins) In the 1000 10Mbps port situation? it doesn't really matter if you've got a few bittorrent users. In the 10 users who can all completely fill the pipe situation? it matters a /lot/ That's the thing about CPU sharing, though; most of the time you don't put that many guests on one machine, and often you give each guest the ability to use the whole machine (when it's otherwise idle) - so you are in the situation of selling 10 1000Mbps links when you only have 1 1000mbps uplink, which ends in tears if anyone actually expects a reliable 1000Mbps uplink. (Now, if everyone understands that it's actually 100Mbps CIR that can burst to 1000Mbps, then sure, people can be happy. but you have to be careful with those expectations. With the 1000 10Mbps links on a 1gbps uplink, customers can treat their 10Mbps link as 10Mbps dedicated, and 99% of the time, they will get what they expect.)