In the early 1970s, 1 MB of memory cost $1 million. Now, there is no comparison; 1 MB is a fraction of that cost. This is one of the reasons why engineers and enterprises don’t worry about memory any more. $1 million dollars in the 1970’s is the equivalent of several millions of dollars today. This is why memory was so precious back in the day. Paul Allen’s autobiography goes into this challenge in detail. Paul Allen talks about the difficulties he and Bill Gates faced in writing BASIC programs in under 4 KB.
There are 4 primary computing resources:
Your application might run on tens, or even thousands of application server instances. Which resource does your application instance use first?
For most applications it is memory. CPU is always at 30 – 60%. There is always abundant storage. It’s hard to saturate a network (unless your application is streaming video content). So, for most applications, it’s the memory that is getting saturated first. Even though the CPU, storage, and network are underutilized, , you end up provisioning more and more application server instances just because memory is getting saturated. This can increase the computing cost for organizations to millions and billions of dollars.
On the other hand, without exception modern applications wastes anywhere from 30 – 90% of memory due to inefficient programming practices. Below are nine different practices that are followed in the industry, which cause memory wastage:
- Duplicate Strings
- Inefficient Collections
- Duplicate Objects
- Duplicate arrays
- Inefficient arrays
- Objects waiting for finalization
- Boxed numbers
- Overhead caused by Object Headers
- Wrong memory size settings
If you can eliminate this 30 – 90% of memory wastage, it will bring two major advantages to your enterprise:
- Reduced computing cost: As memory is the first resource to get saturated, if you can reduce memory consumption, you would be able to run your application on a smaller number of server instances. You might be able to reduce 30 – 40% of servers. Therefore, your management can reduce 30 – 40% of its datacenter (or cloud hosting provider) costs, maintenance and support cost. This alone could account for several millions or billions of dollars in cost savings.
- Better customer experience:If you are reducing number of objects that you are creating to service incoming request, your response time will get a lot better. Since less objects are created, less CPU cycles are spent in creation and garbage collection. A reduction in response time will improve the customer’s experience.
How much memory is my application wasting?
So now let’s get back to original question of this article, “How much memory is my application wasting?”. It’s sad but true: there aren’t that many tools in the industry that can give you this answer. There are tools which can answer the question, “How much memory is my application using?” like TOP, Application Performance Monitoring (APM) tools, Nagios, and more. Using is different from wasting. But we will help you answer this question in two simple steps.
Step 1: Capture Heap Dumps
In order to analyze how memory is wasted, you first need to capture the heap dump. A heap dump is basically a snapshot of your application’s memory. It has information all the objects present in memory, who is referencing it, and more.
You should use the option that best suited for you and your apps.
It’s recommended to capture heap dump when your application is taking traffic. When application is idle, new objects will not be created, thus you wouldn’t be able to see how much memory is actually wasted.
Step 2: Analyze using HeapHero tool
Once you have captured the heap dumps, you can upload the captured heap dumps to the free online heap dump analysis tool HeapHero.
Depending on your application, Heap dumps can contain PII data and other sensitive data. In this case, you can register here to download and install the HeapHero tool locally in your machine.
This tool will give high level summary of total amount of memory that is wasted, the actual data that is causing memory wastage, and lines of code that are triggering this memory wastage. It even recommends solutions to fix the problem.
SEE ALSO: IoT memory: An overview of the options
HeapHero creates a pie graph that summarizes how much memory is wasted due to each inefficient programming practice. Apparently, this application is wasting 35% of its memory. The top two reasons for this wastage are:
- Inefficient collections (i.e. Data Structures) are causing 11.5% of memory wastage.
- Duplication of strings is causing 10.4% of memory wastage.
In this application, there are 343,661 instances of string objects. Out of those, only 144,520 of them are unique. Apparently, there are 6,147 instances of “webservices.sabre.com” string objects. Why are there so many duplicates? Why hasn’t this been cleaned up to free up more memory?
In this application, 34% of HashMap contains no elements. This begs the question of why so many HashMaps have been created with without any elements. When you create a HashMap, it creates 16 elements by default. The space allocated for those 16 elements is wasted when you don’t insert any elements in to it. Interestingly, 97% of Hashtable doesn’t contain any elements either.
SEE ALSO: Eclipse Sprotty: Diagrams in the web
This tool from HeapHero not only shows the objects that are wasting memory, but it also shows the code path that triggers the memory wastage. This knowledge will make it easier for engineers to make the right fix in the right part of the application.
Happy hacking, happy coding!
Source : JAXenter