Imagine checking into a hotel after a long flight, wanting to catch a good night’s sleep before next day’s business meeting. But suddenly your next door neighbor decides to watch a loud TV program. Its sound will awaken you for sure, but what’s the recourse?
Not much, if your virtual hotel is a server on Amazon’s cloud. Your neighbor in this case may be another EC2 user, running a noisy job with too many memory or disk interactions. As we witnessed this recently with Meghafind’s scouts monitoring an EC2 server, with no other job running on it. The performance metrics kept on toggling between Green (good) and other undesirable colors.
So what’s reason for such gyrations?
It turns out that while memory and CPU cores can be neatly divided between Xen VMM based Virtual Machines (VMs) on a physical server, there are several components such as a memory, network or disk controller that must be shared by all VMs. If one of the VMs decides to play a rouge game, intentionally or otherwise, it will generate a lot of I/O traffic saturating the shared controller.
Just like a city highway, where an entry or exit ramp-up can become a bottleneck for new vehicles, a new request on the shared controller must get in line and patiently wait for its turn. This will result in a slow-down of your jobs or web-site responses. There is not much you can do then, except wait. With Meghafind scouts, you can detect when such a blockade starts to happen and take your future jobs to another server, or perhaps another cloud until things become normal. Good luck on your shared cloudy hotel, be sure to find the brighter side.