(see discussion under “InfluxDB Advantages” section in this article)
I also note you have a Java process running. Java’s runtime allocates but never frees memory from the system. It will allocate memory from its configured min/start (-Xms) to its configured max (-Xmx) linearly; it will never return unused memory to the system. You may need to periodically restart the java process to reduce overall system memory use (ideally, of course, you would find a happy setting for max that works for your other system process and the total amount of system RAM, so that java hitting its limit doesn’t cause paging (swap) or system failure).
Increasing your swap size is likely only going to slow your system down and cause excess wear on the drive.
Anyone manage to add additional fields to already existing service tables? I followed the patterns and triple checked. Nothing gets updated for new items.
I’ve added a request on github to look at the possibility to slightly change the plugin so it can be used on Influx 2.x (compared to 1.8.x , there are some changes, concept of a access-token, organisation-id , …)
Hopefully there is still somebody looking at it or we keep stuck on InfluxDB 1.8.x
At the moment I don’t have any plans to update the plugin - I’m weighing up whether I stick with the Vera platform. Ezlo seems to be a long way from delivering anything that has feature parity, and even if/when they do I suspect all plugins will need an extensive rewrite.
If rigpapa has got 2.x Influx code in his repo then it might be easy to update it. I’ll take a look. But not making any promises.
It’s in a whole new Reactor (Multi-hub) product that works with both Vera and eZLO, but it’s not Lua so I don’t think it would do you much good. It’s all node (JS) now, and I’m using the @influxdata/influxdb-client package for the interface.