I have this memory issue with Java 8 on Jetty Server. After exploring about memory leaks, it is not clear for me that: whether a Java Memory leak will cause just jvm OutOfMemoryError only? or can cause excessive physical memory usage(which can't be tracked by profiler) resulting a system crash?
A memory leak can lead to any resource being exhausted.
A common one is running out of file descriptors, i.e. files or keeping unused sockets alive. This limit can be as low as 1024.
It would be possible to do the same thing with GUI components or any component which proxies an external resource.
Related
I searched quite a lot for the question but was unable to find my exact query although it seems general enough that might have been asked and answered somewhere.
I wanted to know what happens after a process causes a memory leak and terminates. In my opinion it's not big deal because of virtual memory. After all physical pages can be still allocated to other/new process even if it was causing memory leak earlier (after old process caused memory leak)
But I also read somewhere that due to memory leaks you need to restart your system, and I dont seem to understand why???
Recommended reading : Operating Systems: Three Easy Pieces
On common OSes (e.g. Linux, Windows, MacOSX, Android) each process has its own virtual address space (and the heap memory, e.g. used for malloc or mmap, is inside that virtual address space), and when the process terminates, its entire virtual address space is destroyed.
So memory leaks don't survive the process itself.
There could be subtle corner cases (e.g. leaks on using shm_overview(7) or shmget(2)).
Read (for Linux) proc(5), try cat /proc/self/maps, and see also this. Learn to use valgrind and the Address Sanitizer.
Read also about Garbage Collection. It is quite relevant.
In modern operating systems the address space is divided into a user space and an system space. The system space is the same for all processes.
When you kill a process, that destroys the user space for the process. If an application has a memory leak, killing the process remedies the leak.
However,the operating system can also allocate memory in the system space. When there is a memory leak in the operating system's allocation of system space memory, killing processes does not free it up.
That is the type of memory leak that forces you to reboot the system.
Can someone explain the difference between on-heap memory and off-heap memory?Does the off-heap memory show on the JVM memory size?Are the off-heap all pointers?
All memory is native memory, however the JVM manages and record memory in it's JVM heap (not the same as the native heap)
Offheap is a Java term for memory not managed directly. However, it can be managed indirectly using direct ByteBuffer(s) as proxy objects for raw native memory.
Which memory usage reporting method should I use when my application crashes due to low memory? There are few options:
Allocations instrumentation tool
Activity Monitor instrumentation tool
VM Tracker instrumentation tool
Xcode debugging sessions memory reporting
mach_msg_type_number_t.resident_size
The problem is that every method returns different results.
Allocations instrumentation return much smaller values than other methods - I assume Allocation only counts memory explicitly allocated inside application, but not memory used by my my app code and other libraries code? Am I right? On 512MB devices Allocation reports as low as 70MB of allocated memory and application still receives memory warnings and eventually crashes. Can I somehow measure what this difference is exactly?
Xcode debugging sessions memory reporting and mach_msg_type_number_t.resident_size varies vastly. They are sometimes 50MB away from each other, both ways. Why is that?
I have a service which intermittently starts gobbling up server memory over time and needs to be restarted to free it. I turned +ust with gflags, restarted the service, and started taking scheduled UMDH snapshots. When the problem reoccurred, resource manager reported multiple GB under Working set and Private bytes, but the UMDH snapshots account only for a few MB allocations in the process' heaps.
At the top of UMDH snapshot files, it mentions "Only allocations for which the heap manager collected a stack are dumped".
How can an allocation in a process be without a trace when +ust flags were specified?
How can I find out where/how these GBs were allocated?
UMDH is short for User Mode Dump Heap. The term Heap is a key term here: it refers to the C++ heap manager only. This means that all memory which is allocated by other means than the C++ heap manager is not tracked by UMDH.
This can be
direct calls to VirtualAlloc()
memory used by .NET, since .NET has its own heap manager
But even for C++, there is the case that allocations larger than 512 kB are not efficiently manageable by the C++ heap manager, so it just redirects it to VirtualAlloc() and does not create a heap segment of such large allocations.
How can I find out where/how these GBs were allocated?
For direct calls to VirtualAlloc(), the WinDbg command !address -summary may give an answer. For .NET, the SOS extension and the !dumpheap -stat can give an answer.
Like the title says I'm interested if I can see per thread memory usage on programs compiled with -ltcmalloc. AFAIK with regular malloc memory is linked to process not to thread, but I'm not sure about tcmalloc.
TcMalloc has some per-thread memory caches. But they are just a proxy to a shared heap (to reduce the congestion). All the memory in tcmalloc comes from a single shared pool.
Alive (allocated) memory may be passed freely from one thread to the other,
so it's not easy to say which thread uses it.
You could monitor which thread allocated the used memory, but you would need either completely separated memory pools (not very elastic) or some per-allocation memory overhead. Neither of those is present in tcmalloc...
There is no such thing as per-thread memory usage. Memory is a process resource.