Best practices in InfluxDB 2.7 for memory usage reduction on IoT devices in 2024

Hello. Currently, we are using InfluxDB 2.7 on Raspberry Pi 4 IoT devices, where we have a limited 4GB RAM available. The collected data are replicated to another InfluxDB where we are storing these so we are storing only less data locally with low retention time. What options are there on the InfluxDB configuration side to reduce its memory usage? For example, more frequent writing of data to the storage instead of keeping it in memory, etc. What settings do people use in such an environment in 2024? The key is to avoid consuming all the memory, as it leads to system instability issues. I didn’t find another good option in the documentation. I have ruled out cgroups because in a critical business environment, reaching the memory limit and killing running processes is not ideal. Also, after reviewing the configuration options, reducing the shared cache size can cause similar operational problems. Thank you for any constructive suggestions. Regards, Wolfi

Hello @wolfi,
Welcome!
Unfortunately there isn’t much operator control over InfluxDB v2 (thats a big reason why 3.x was developed).

You can use OS level settings to change how much memory is available for mmap. Indirectly, you can reduce data stored in Influx through a smaller retention period and/or downsampling and reducing cardinality of data. If you do constrain memory, I would expect to see decreased performance as the OS pulls mmap’d data in and out more frequently.

Sorry that there isn’t a better solution in that version.

Hello @Anaisdg, can you be more specific about OS level settings to change how much memory is available for mmap? Also can you tell us about v3 it is possible set memory limit in this version?

Actually i faced height memory usage v2 while upgrading from v1 to v2. To such an extent that i can’t start my influx after restart. I be really glad to hear some advice about upgrading. I have around 60G v1 database and around 4Gb RAM VM for influx should i try upgrade to v3 or better stay on v1, v2 obviously not usable in my case.

Hello @ComBin,
I think you can do something like:

sysctl -w vm.max_map_count=262144  

But I haven’t done this and I don’t think its considered best practice. Whether you upgrade depends on your needs and whats causing the mem issues.
InfluxDB3 Core and Enterprise have distinct and last value caches:

Here are mem configuration options in v3

1 Like