Latest posts by khushvinder (see all)
- How to get top five CPU and Memory consuming processes from zabbix using SNMP and PS linux command - September 26, 2019
- How to monitor Services/Processes in zabbix using SNMP? - August 17, 2019
- How to get overall CPU utilization in zabbix - June 15, 2019
Out-of-memory errors occur when there is not enough space available in the heap to create a new object. A JVM will always trigger a garbage collection and try to reclaim memory before raising an out-of-memory error. In most cases the underlying cause is an insufficient memory configuration or a memory leak. Below is the some points which may be responsible for OOM errors:
- Insufficient memory configuration
- Memory leak
- Memory fragmentation
- Excess GC overhead
- Allocating oversized temporary objects
1. Insufficient memory configuration: java.lang.OutOfMemoryError does not necessarily involve a memory leak. The issue might simply be a configuration issue, for example if the specified heap size (or the default size if not specified) is insufficient for the application. We have some command line options to increase the Heap size:
For reference, the 3 most common parameters used to change the memory (heap) allocation are:
Xms – the minimum size of the heap
Xmx – the maximum size of the heap
-XX:MaxPermSize – the maximum size of PermGen (Note : this is not used in Java 8 and above)
2. Memory Leaks: Memory leaks is a type of resource leak that occurs when a computer program incorrectly manages memory allocations. In such a way that memory which is no longer needed is not released. In object-oriented programming, a memory leak may happen when an object is stored in memory but cannot be accessed by the running code.
We can view the memory graph using MAT and after that try to do appropriate operation to like close/clear the unused objects.
3. Memory fragmentation can also cause out-of-memory errors even when there appears to be enough free memory, because there isn’t a single continuous area in the heap that’s large enough for the allocation request. In most cases, compaction assures that this does not occur, however there are GC strategies that do not use compaction.
4. Excess GC overhead: The parallel collector will throw an OutOfMemoryError if too much time is being spent in garbage collection: if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, an OutOfMemoryError will be thrown. This feature is designed to prevent applications from running for an extended period of time while making little or no progress because the heap is too small. If necessary, this feature can be disabled by adding the option -XX:-UseGCOverheadLimit to the command line.
5. Allocating oversized temporary objects : Program logic that attempts to allocate overly large temporary objects. Since the JVM can’t satisfy the request, an out-of-memory error is triggered and the transaction will be aborted. This can be difficult to diagnose, as no heap dump or allocation-analysis tool will highlight the problem. You can only identify the area of code triggering the error, and once discovered, fix or remove the cause of the problem.
For garbage collection please follow Garbage Collection post.
1,557 total views, 1 views today