Customize Consent Preferences

We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below.

The cookies that are categorized as "Necessary" are stored on your browser as they are essential for enabling the basic functionalities of the site. ... 

Always Active

Necessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.

No cookies to display.

Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features.

No cookies to display.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc.

No cookies to display.

Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.

No cookies to display.

Advertisement cookies are used to provide visitors with customized advertisements based on the pages you visited previously and to analyze the effectiveness of the ad campaigns.

No cookies to display.

On the Subject of Bloat

VM’s take up space. They use resources like RAM and CPU cycles when they’re online, and they use up storage no matter if they’re online or not. As VM infrastructures get bigger and bigger, so does the amount of resources that they consume.

In the modern datacenter, this has contributed to a theory called bloat, where VM resources balloon larger and larger over time. In many cases, this bloat isn’t being caused by active resources, and that’s where problems can occur quickly.

As VM’s are provisioned and used, the active resources they take up are necessary for the VM system itself to function. You have 10 servers that each use about 50GB of disk, 2 processor cores and 4GB of RAM, etc. The problems start when those servers are no longer needed.

You upgrade to a new CRM system. The old CRM system’s VM’s are – of course – shut down after the migration. As usual for any updated system, the old system is kept dormant for a period of time, just in case you have to either go back to it, or retrieve data that didn’t make it through the migration process for some reason.

Now it’s six months later, and the old system is all but forgotten about. But the VM’s that made up that old system are still there. Since they’re not physical machines, and since they’re not using RAM and CPU power, it is all to easy to simply forget they exist and leave them on the VM hosts that they formerly ran on. That means that a set of storage is not useable, because it’s being held by the – now-non-functioning – CRM system VM’s.

As more applications go through this life-cycle, more dormant VM’s are left sitting on the VM hosts, eating up more and more space and other resources (VM network ports, etc).

So, a few times a year, go through all the dormant VM’s and make sure they really need to be on the VM systems at all. If they don’t, clear out the space (after taking a backup, of course) and free it up for other systems within your active pool of VM’s.

There will always be some dormant VM’s that need to stick around for various reasons, but any that do not need to remain on the VM hosts are doing nothing but sapping space and taking up time during maintenance runs.

Dealing with bloat effectively can mean the difference between having a smooth running system with plenty of space, and having to buy a new storage device because you ran out of room for no valid reason.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.