Can the memory footprint of TDengine be limited by parameters? I - memory

I'm using TDengine database. The data will increase 200 million per day,but the memory usage is growing by about 50MB accordingly.I'm a little concerned about the amount of resources being used.
I have searched the development documentation and can't find any similar parameters to limit the memory footprint.
I wonder what mechanism is causing its memory to keep growing? Is there any way to limit it?

Related

Volatility of different types of memory

I'm dumbfounded with this matter. As far as my knowledge goes there is volatile and non-volatile memory. The question that has been given to me is to rate on a scale of 1 to 4 the volatility of each of these types of memory.
The types of memory outlined here are DRAM, CPU Cache, CPU Registers and Secondary Storage. I'm aware that DRAM, Cache and Registers are very much volatile, with some exceptions in the case of Registers. So far my answer goes as follows:
DRAM
Cache
Registers
Secondary Storage
Would this be considered a correct solution? I've researched wide and far and there is not much data on how volatile these types of memory are.
The closer to the core the memory is the more the pressure is on the manufacturers to optimize for speed. Volatility can be easily solved with refresh cycles with the cost of some extra energy consumption (nobody cares, everybody wants speeeeed).
Since there's a trade-off between speed and permanence, memory units closer to the core are more volatile.
So the order is: registers, cache, DRAM, secondary storage.

iPhone/iPad's Document Directory usage limit

I am working on an application where I have to store approximately 200 photos captured from camera in Documents directory. I know that there has to be some limit on the usage of Documents Directory, and if used in excess it may result in Low Memory Situations.Can you people tell me what is the max usage limit, if any. What are the different scenarios to be considered while doing the same?
No there is no limit. Limit is your device's available disk space. People will tell that there is 2GB limit but that is wrong. That is the app's size limit.
No it will not result in low memory situations if used in excess considering you are handling your objects properly like you do in any app.

Does the amount of data stored in the memory (e.g. DDR3) affect its power consumption?

I am not familiar with memory principles. This may be a naive question.
Suppose I have a DRAM with 1GB, like the one in my tablet.
Will there be power consumption differences when it holds 200MB data, or 500MB data?
If the data is just present in memory and not being accessed, No.
But the power consumption will increase in following cases:
You read memory - uses read circuit - very likely that you will read data when it is present in the memory
When you alter/write memory - large consumption when bit alterations in cells take place from 0 to 1 or 1 to 0
Also, there is a constant leakage current at all time the device is on.

What's the right statistic for iOS Memory footprint. Live Bytes? Real Memory? Other?

I'm definitely confused on this point.
I have an iPad application that shows 'Live Bytes' usage of 6-12mb in the object allocation instrument. If I pull up the memory monitor or activity monitor, the 'Real Memory' Column consistently climbs to around 80-90mb after some serious usage.
So do I have a normal memory footprint or a high one?
This answer and this answer claim you should watch 'Live Bytes' as the 'Real Memory' column shows memory blocks that have been released, but the OS hasn't yet reclaimed it.
On the other hand, this answer claims you need to pay attention to that memory monitor, as the 'Live Bytes' doesn't include things like interface elements.
What is the deal with iOS memory footprint!? :)
Those are simply two different metrics for measuring memory use. Which one is the "right" one depends on what question you're trying to answer.
In a nutshell, the difference between "live bytes" and "real memory" is the difference between the amount of memory currently used for stuff that your app has created and the total amount of physical memory currently attributed to your app. There are at least two reasons that those are different:
code: Your app's code has to be loaded into memory, of course, and the virtual memory system surely attributes that to your app even though it's not memory that your app allocated.
memory pools: Most allocators work by maintaining one or more pools of memory from which they can carve off pieces for individual objects or allocated memory blocks. Most implementations of malloc work that way, and I expect that the object allocator does too. These pools aren't automatically resized downward when an object is deallocated -- the memory is just marked 'free' in the pool, but the whole pool will still be attributed to your app.
There may be other ways that memory is attributed to your app without being directly allocated by your code, too.
So, what are you trying to learn about your application? If you're trying to figure out why your app crashed due to low memory, look at both "live bytes" (to see what your app is using now) and "real memory" (to see how much memory the VM system says your app is using). If you're trying to improve your app's memory performance, looking at "live bytes" or "live objects" is more likely to help, since that's the memory that you can do something about.
Seeing as how I wrote the last answer you linked to, I'll have to stand by that. If you want a total, accurate count of the current memory usage for your application, use the Memory Monitor instrument.
For reasons that I describe in this answer, Allocations hides the memory sizes of certain elements, meaning that its memory usage totals are significantly lower than your application's in-memory size. Many people find this out the hard way when they try to get their application functional on older iOS devices. On the older hardware, you had a hard memory ceiling of ~30 MB, where if you exceeded that your application was hard-killed.
Many developers (myself included) saw that we only had ~1-2 MB of live bytes in Allocations and thought we were good, until our applications started receiving memory warnings and early terminations. If you looked at Memory Monitor, you could see the true in-memory size of these applications being >20 MB, and you could see the applications being terminated the instant they crossed the 30 MB barrier in Memory Monitor.
Therefore, if you want an accurate assessment of your total application memory usage, use Memory Monitor. Allocations is great to find out the specific objects that are in memory, particularly when you use the heap shots to find things that might be accumulating (as leaks, retain cycles, or for other reasons). Just don't trust it when determining your application's actual size in memory.
'Live bytes' means memory allocated by your code (for example by malloc), so you have access to this memory. 'Real memory' shows physical amount of memory used by your app. This include also OpenGL textures, (possibly) sounds from Open AL...
Live bytes is useful to check when you allocate and release memory in your code. Real memory is good indicator for memory optimization efficiency. And it's overhead causes 'low memory' warnings.

High virtual memory usage + low allocations on iOS

I have code that has a low amount of active allocations (about 5 MB according to Instruments), but a high amount of system memory usage (over 100 MB). I know the code is leak-free, and I'm not seeing any allocation spikes after some optimization, but I'm still crashing due to the high amount of memory usage.
I Googled around a lot and see that I'm supposed to be using the VM Tracker instrument, which confirms my high memory usage, but I'm not sure how to address this situation. I'm using as little memory as possible, it's still too much on an iPad 1, and I don't have the knowledge or tools to figure out how to get the OS to not mark so much memory as dirty when I'm not actually using it. Where do I go from here?
Use the Profile tool and select memory +allocations. Click the VM tracker and take a snapshots. This results in a list with resident dirty and virtual memory usage per object type. This will give you an indication where to look.
I think the most common problem is that you have a lot of autoreleased objects that reside in the autoreleasepool. The following link explains more on how to handle autoreleasepools:
How does the NSAutoreleasePool autorelease pool work?

Resources