What is the noisy neighbor effect?

Whether it’s a TV turned up too loud, thumping bass from music, crying babies, crazy parties, barking dogs, or even the whirring of kitchen ap­pli­ances through the night: noise dis­turb­ances from neigh­bours are something that all of us have ex­per­i­enced in life. But when these dis­turb­ances are par­tic­u­larly dis­rupt­ive or occur regularly, they can have an enormous impact on your living en­vir­on­ment and daily life. But the problem of noisy neigh­bours having a negative impact on rented resources isn’t ex­clus­ively contained within your four walls at home: this phe­nomen­on has also spread to the virtual server en­vir­on­ment too. For this reason, it’s referred to as the ‘noisy neighbour problem’.

When choosing where to live, you generally have two options: either you can buy or rent a stan­dalone house, or you can live in an apartment in a shared block. With the former your neigh­bours are much less likely to be an issue, with the later you tend to have a lot more regular contact with them in an apartment in a shared building. But the price you pay for the added privacy of a house is usually higher, with ad­di­tion­al ad­min­is­trat­ive costs included – both of which are typically lower in an apartment block.

Searching for a suitable home for your web project or company IT in­fra­struc­ture is similar in several aspects: running your own physical server (either on your own or hosted by a provider), including all the necessary software and hardware, is an expensive solution and requires greater effort, but it does mean you remain 100% in control of the resources and man­age­ment of your server. If you turn to vir­tu­al­ised resources to save costs, you share the base of your project with others – which can lead to oc­ca­sion­al fluc­tu­ation in per­form­ance.

The cause for this is usually too much strain being placed on resources by a co-tenant, which has led to the use of the term ‘the ‘noisy neighbour’ effect’. Today, you can witness the phe­nomen­on of a per­form­ance-impairing ‘neighbour’ instantly, par­tic­u­larly in flexible cloud computing, which is built on the presence of a multi-tenancy, or multi-instance ar­chi­tec­ture (par­tic­u­larly the public clouds).

The ‘noisy neighbour’ effect has been in existence longer than the discovery of the cloud though – the term was coined when resource sharing in internet tech­no­logy began. The problem of noisy neigh­bours was first es­tab­lished as early as the found­a­tion of tra­di­tion­al shared hosting between a hosting provider and clients. If a par­ti­cipant con­sciously or un­con­sciously uses more resources than was ori­gin­ally allocated, it means that at least one other par­ti­cipant is tem­por­ar­ily re­stric­ted – this is par­tic­u­larly true of memory space. In the meantime, the hy­per­visors, which serve as a mediation layer between the physical resources and the virtual machines, have become so soph­ist­ic­ated that it’s almost im­possible for in­di­vidu­al users to avoid the limiting of resources.

Modern cloud hosting, on the other hand, whose great advantage is its very flexible scalab­il­ity, has its own ‘noisy neighbour’ problem: although the capacity and access times of storage tech­no­logy has improved greatly, storage re­quire­ments regarding the cloud have grown more ex­po­nen­tially. If multiple user instances are connected to a cloud solution, and one or more virtual machines burden the physical server memory with excessive input/output values, this may cause some memory impair­ment. SSDs work to prevent this problem occurring, but they can’t halt the negative effects entirely; they’re also not a standard component of every cloud hosting provider’s rep­er­toire yet.

There’s also another noisy neighbour effect present in cloud computing, one which results from the behaviour of the hy­per­visor and the pro­cessors. While the hy­per­visor has no access to the local storage or the cache of the pro­cessors, these con­versely don’t have much in­form­a­tion about what happens beyond the network layer. For this reason, the pro­cessors decide which data is cached them­selves. Ad­di­tion­ally, modern, multi-core pro­cessors prefer to assign in­di­vidu­al virtual machines to the L3 cache, which speeds up the data exchange between the cores. The con­sequence of this is that all other op­er­a­tions for the remaining machines that also access to same processor take con­sid­er­ably more time to complete.

To avoid the ‘noisy neighbour’ problem and optimise the per­form­ance of all hosted projects for the long term, some cloud providers have switched to an all-flash storage in­fra­struc­ture. This storage concept involves replacing all of the tra­di­tion­al hard disk drives (HDDs) with the more powerful (but also more expensive) solid state drives (SSDs). But even this modern flash storage medium can’t com­pletely stop the ‘noisy neighbour’ effect, despite its higher input/output rate. As a result, database storage systems that contain several flash memory drives – known as all-flash arrays – have proven to be suc­cess­ful ways to operate storage structure without HDDs. These arrays have a built-in storage quota for the input and output of data that can be managed via an in­di­vidu­ally cus­tom­is­able ap­plic­a­tion layer. This means that the cloud provider or the operator of an in­di­vidu­al cloud can co­ordin­ate and keep tabs on the data transfer between the different virtual machines.

If the de­vel­op­ment of your project is difficult to estimate, you should be aware of the upgrading and down­grad­ing options for your chosen rented resources. Otherwise, you may quickly discover that you’re paying for storage and CPU per­form­ance that you don’t really need – or that you yourself have become a ‘noisy neighbour’ due to using more resources than you’ve been allocated and dis­rupt­ing other cloud users in the process.

You are in­ter­ested in a virtual server cloud and want to avoid the ‘noisy neighbour’ effect, then find out here about the IONOS server portfolio.