As suggested by many,instruments tool is the best way to capture the memory allocation and leaks.But for me its been easy to use instruments tool,but i am confused with the detailed results as shown in the above screenshot.
Want to know the meaning of following points,
1)All Allocations,
2)Live Bytes,
3)Overall Bytes,
4)Overall.
Simple but confusing!Any answer will be greatly appreciated.
live bytes: The number of bytes that have been allocated but not released yet.
Living:*The number of object created and still on the heap.
Transitory: The number of objects created and destroyed
Overall byte: The total number of byte that have been allocated and released
overall:The total number of objects allocated and released .
all allocations: All the allocations while the application is running .
Related
I know basic stuffs like when you run a process, it will load environment variables and the parameters to the stack; or how rsp, rbp registers be doing when we run a function. But, what thing and when does the stack/heap actually created when we run a process?
The stack is allocated at launch time of the process with a default size. It also has a maximum size. If the stack grows past its default size, the kernel checks whether the stack is bigger than its maximum size. It allocates more pages to the stack if it is smaller or kills the process if it is bigger.
The heap is allocated a region of virtual memory but not of physical memory. The heap will have a reserved region of virtual memory so that it can freely grow within it. When you ask for dynamic memory using the new operator in C++, you make a system call in the kernel to ask that it allocates a part of that virtual address space reserved for the heap in the physical address space. Once a portion of the physical address space has been allocated to your process, you can use it in your application freely.
Most C++ standard library implementations will have code that will follow how the heap grows and attempt to avoid internal fragmentation. The smallest unit of allocation in most OSes is 4KB. If you ask for, let's say, 1024 bytes of data, one page is allocated to your process. The process thus have one full page allocated. There is some memory lost here to internal fragmentation. The C++ standard library implementation thus keeps track of the allocated pages for you so that when you ask for more memory it will use the same page for your memory needs instead of requesting several pages for nothing.
There are four components on the ram: the code itself, global variables, stack, and heap.
In c++, the first three gets created during compilation, heap gets created when you create it(eg. int *ptr = new int[10];)
In python, everything is pointers (stack memory only contains the pointers, actual values in heap), meaning all four are created during compilation(interpreting)
The stack is created in every scope. Stack
The heap is created when allocated. Heap
I use Mongodb 3.6 + .net driver (MongoDb.Driver 2.10) to manage our data. Recenyly, we've noticed that our services (background) consume a lot of memory. After anaylyzing a dump, it turned out that there's a mongo object called BsonChunkPool that always consumes around 0.5 GB of memory. Is it normal ? I cannot really find any valuable documentation about this type, and what it actually does. Can anyone help ?
The BsonChunkPool exists so that large memory buffers (chunks) can be reused, thus easing the amount of work the garbage collector has to do.
Initially the pool is empty, but as buffers are returned to the pool the pool is no longer empty. Whatever memory is held in the pool will not be garbage collected. This is by design. That memory is intended to be reused. This is not a memory leak.
The default configuration of the BsonChunkPool is such that it can hold a maximum of 8192 chunks of 64KB each, so if the pool were to grow to its maximum size it would use 512MB of memory (even more than the 7 or 35 MB you are observing).
If for some reason you don't want the BsonChunkPool to use that much memory, you can configure it differently by putting the following statement at the beginning of your application:
BsonChunkPool.Default = new BsonChunkPool(16, 64 * 1024); // e.g. max 16 chunks of 64KB each, for a total of 1MB
We haven't experimented with different values for chunk counts and sizes so if you do decide to change the default BsonChunkPool configuration you should do some benchmarking and verify that it doesn't have an adverse impact on your performance.
From jira: BsonChunkPool and memory leak
Really, I only want to know what are slabs in memcached. And could be better if someine who is working know with can answer me.
Thanks for your answers...
Applications that run for long periods of time, like memcached, run into memory fragmentation issues the longer the service runs. On top of that caching applications have the added issue that there are pieces of memory that have been cached for long periods of time as well as newer pieces of memory that were recently allocated.
Memcached has a "slab" allocator that attempts to reduce memory fragmentation in the memcached process. At a high level a slab is a 1MB piece of memory that contains the values of the key-value pairs you store in memcached. There are also different slabs for different value sizes. There might be a slab for 16B values, a a slab for 32B values, a slab for 1024B values, etc. When a new key-value pair is added memcached puts the value in the smallest slab that will hold the value. By allocating memory like this memcached is able to reduce memory fragmentation and as a result reduce the overall amount of memory used by memcached.
Slabs and the slab allocator are internal memcached implementation details. You can get information about them through the stats command, but unless you're trying to debug an issues with memcached itself inspecting the slab information is unlikely to be useful.
For more details about slabs and the slab allocator I found a blog post linked below.
https://holmeshe.me/understanding-memcached-source-code-I/
If you're particularly interested in this kind of architecture then look into how memory allocators work in general since the concepts are similar.
i'm with a big doubt about TLABs and objects.
For what i've studied about TLABs in JVM, the objects should preferentially kept into TLABs when they're created, going to the young generation, right?
However, as you can see in the image 1, the 'Average TLAB Size' is 20,13 kB for my application and 'Average Object Size' (outside TLABs) is 11,25 kB.
As far as I know the objects should be saved into TLAB, unless they're greater than a TLAB. I'm afraid that we're having a lot of heap fragmentation, as you can see that we have the 'Total Memory Allocated for TLABs' with 52,90 MB and 'Total Memory Allocated for Objects' with only 1,27 MB. That is a waste of 51,63 MB for only 5 minutes running the Java Mission Control.
Is it something very wrong with my application, JVM or JBoss? Or is that a misunderstood?
Thanks in advance.
TLABs greater than Objects
GC's compaction, sweep and mark avoids heap memory fragmentation. So how is memory fragmentation is avoided in Swift?
Are these statements correct?
Every time a reference count becomes zero, the allocated space gets added to an 'available' list.
For the next allocation, the frontmost chunk of memory which can fit the size is used.
Chunks of previously used up memory will be used again to be best extent possible
Is the 'available list' sorted by address location or size?
Will live objects be moved around for better compaction?
I did some digging in the assembly of a compiled Swift program, and I discovered that swift:: swift_allocObject is the runtime function called when a new Class object is instantiated. It calls SWIFT_RT_ENTRY_IMPL(swift_allocObject) which calls swift::swift_slowAlloc, which ultimately calls... malloc() from the C standard library. So Swift's runtime isn't doing the memory allocation, it's malloc() that does it.
malloc() is implemented in the C library (libc). You can see Apple's implementation of libc here. malloc() is defined in /gen/malloc.c. If you're interested in exactly what memory allocation algorithm is used, you can continue the journey down the rabbit hole from
there.
Is the 'available list' sorted by address location or size?
That's an implementation detail of malloc that I welcome you to discover in the source code linked above.
1. Every time a reference count becomes zero, the allocated space gets added to an 'available' list.
Yes, that's correct. Except the "available" list might not be a list. Furthermore, this action isn't necessarily done by the Swift runtime library, but it could be done by the OS kernel through a system call.
2. For the next allocation, the frontmost chunk of memory which can fit the size is used.
Not necessarily frontmost. There are many different memory allocation schemes. The one you've thought of is called "first fit". Here are some example memory allocation techniques (from this site):
Best fit: The allocator places a process in the smallest block of unallocated memory in which it will fit. For example, suppose a process requests 12KB of memory and the memory manager currently has a list of unallocated blocks of 6KB, 14KB, 19KB, 11KB, and 13KB blocks. The best-fit strategy will allocate 12KB of the 13KB block to the process.
First fit: There may be many holes in the memory, so the operating system, to reduce the amount of time it spends analyzing the available spaces, begins at the start of primary memory and allocates memory from the first hole it encounters large enough to satisfy the request. Using the same example as above, first fit will allocate 12KB of the 14KB block to the process.
Worst fit: The memory manager places a process in the largest block of unallocated memory available. The idea is that this placement will create the largest hold after the allocations, thus increasing the possibility that, compared to best fit, another process can use the remaining space. Using the same example as above, worst fit will allocate 12KB of the 19KB block to the process, leaving a 7KB block for future use.
Objects will not be compacted during their lifetime. The libc handles memory fragmentation by the way it allocates memory. It has no way of moving around objects that have already been allocated.
Alexander’s answer is great, but there are a few other details somewhat related to memory layout. Garbage Collection requires memory overhead for compaction, so the wasted space from malloc fragmentation isn’t really putting it at much of a disadvantage. Moving memory around also has a hit on battery and performance since it invalidates the processor cache. Apple’s memory management implementation can compress memory that hadn’t been accessed in awhile. Even though virtual address space can be fragmented, the actual RAM is less fragmented due to compression. The compression also allows faster swaps to disk.
Less related, but one of the big reasons Apple picked reference counting has more to do with c-calls then memory layout. Apple’s solution works better if you are heavily interacting with c-libraries. A garbage collected system is normally in order of magnitude slower interacting with c since it needs to halt garbage collection operations before the call. The overhead is usually about the same as a syscall in any language. Normally that doesn’t matter unless you are calling c functions in a loop such as with OpenGL or SQLite. Other threads/processes can normally use the processor resources while a c-call is waiting for the garbage collector so the impact is minimal if you can do your work in a few calls. In the future there may be advantages to Swift’s memory management when it comes to system programming and a rust-like lifecycle memory management. It is on Swift’s roadmap, but Swift 4 is not yet suited for systems programming. Typically in C# you would drop to managed c++ for systems programming and operations that make heavy use of c libraries.