Not a single byte is sent from node-red into the database.
I am on the wrong forum here. But as long as you bear with me I'd like to continue here.
There might be another data source, but since I'm not knowledgeable in this area, there is a very very low chance that I did something which sends data to influxdb.
There is only the infinite retention policy (default setting), and no continuous query (I disabled it nevertheless in the config file just to make sure).
There is nothing in the system logs showing up (I use 'sudo journalctl -f' to watch this)
I will let the system run over night to see if it cools down on its own.
If not, then the only way out here is to drop the database from within influx and start from scratch.
You can disconnect them all. Then add one function write to InfluxDB a time. This is one useful way to debug which influxDB write caused the error, or a cumulated error due to dozens of separate writes.
I stopped the influxdb.
Then I ran 'sudo influx_inspect verify -dir /var/lib/influxdb' , but the 5 .tsm files seemed 'healthy'.
Then I headed over to /var/lib/influxdb/data/home/autogen/150 and just deleted all the files there and the directory too. I do not care if I miss a few data points. desperate times, desperate measures.
I restarted influxdb, top and iotop look perfect.
Then I added all my data sources from within node-red in one go, just to see how this goes.
Result so far:
influxd as process shows rarely up in 'top'
'sudo iotop' shows almost no write activity
data show up in grafana as it should
no more errors in the log about a problem with compacting a .tsm file
Therefore I set the log level back from debug to warn.
Let's declare this exercise a success and head for the pillow.
Many thanks for all the assistance I got. I learned a lot. Not being alone with a problem like this means a lot to me. I hope I can give something forward at another opportunity.
Kind regards,
Urs.
It may well fail again when the db gets back to a significant size.
Unfortunately there doesn't seem to be a fix and likely never will be as there is no further development on 1.8 and apparently 2.0 doesn't (and won't) support 32 bit systems.
There is now, I think, a 64 bit OS version available for the pi 4, though I haven't tried it, or I suppose one could install Ubuntu or Debian.
I now use an old laptop as my main server (running Ubuntu server). Pretty much any old 64 bit laptop will handle the sort of loads you are talking about.
However, whatever you do, you should re-arrange the db schema, as the way you have it at the moment is a long way from ideal. Maybe best to carry on that discussion on your other thread?
It is possible that the fact that you have a database that is full of holes (due to sending multiple different field values to the measurements one at a time) may be making the issue more likely to happen.
To clarify what I mean, the db1 measurement will have a row in it for each timestamp for which you write a value. So one row will have timestamp and root value, but nothing for root-usage and all the others. Then the next row may have timestamp and root-usage value, but none of the others. This is a Bad Thing for an Influx DB.
Glad you got it sorted. Before you move on to InfluxDB 2.0, try and gain as much experience from 1.8 first. The query language in version 2.0 has a very steep learning curve.
@Colin Not yet. I will check it out when time allows and report back @ghayne Sorry we don't use GPIO from Node-RED function. We currently use C and pigpio library for the GPIO interface. I think Node-RED GPIO interface is also based on the pigpio library wrapped with Node.js. So I will expect it to work
I have just installed Ubuntu 21.04 64 bit on a Pi 3B. I then installed node-red with the standard script with no problems (No GPIO nodes) it's running fine.
That is good to know. It would be interesting for someone to try Raspbian 64 bit, or whatever they call it now. I haven't got a spare Pi to try it on at the moment.