The issue has been closed
Problem/Motivation
It seems that InfluxDB may start to use excessive CPU and RAM resources on a Raspberry PI after a while (see this issue). I have quite a lot of sensor that log to InfluxDB every 10 seconds. After each restart of InfluxDB within 3 days or so HA starts to slow down significantly and InfluxDB seems to be the culprit (also see my comment on the forum).
Proposed changes
As suggested by the InfluxDB team (link) a possible solution is "to disable the internal monitor" by adding the following to the influxdb.conf file:
[monitor]
store-enabled = false
For me this has solved the issue of high CPU and RAM usage. It would be nice to be able to apply this configuration without going into the Docker container and editing the config after each update.
:wave: Thanks for opening your first issue here! If you're reporting a :bug: bug, please make sure you include steps to reproduce it. Also, logs, error messages and information about your hardware might be useful.
As an end user I've had the same problem. I believe you can set store-enabled with the recent changes to use environment variables, e.g.:
auth: true
reporting: true
ssl: true
certfile: fullchain.pem
keyfile: privkey.pem
envvars:
- name: INFLUXDB_MONITOR_STORE_ENABLED
value: 'false'
log_level: info
My more pressing problem was it running out of memory during compaction which I couldn't fix with any influxdb option. As I've commented previously on issue 53 it seems that influxdb just isn't going to cut it as a long-term solution on an RPI. I've reluctantly moved influxdb to a different machine for data collection.
If this works, then this issue can be closed. @rychardeh I've tried compacting, but could issue a command that works. Which one did you use?
I'm not sure I follow what you mean by command. Influxdb just compacts at boot time if the DB needs it and periodically thereafter - I don't know if there is a way to trigger it manually.
posted by L2v2P almost 5 years ago I hadn't seen that - were you doing this within the container similar to this? My long-term issue was getting out of memory errors during compaction and no amount of swap on the RPI helped - only moving the database to a machine with more physical memory allowed it to finish the compaction.
I tried it on the default addon container.
IssueHunt