That is what I would suggest. I think the important part is to link to the prerendered chart so all the work goes on in the Grafana server and the browser has just the one request and one image to download each refresh period.
The problem does not occur because of the refresh period. The service breaks down as soon as I refresh manually the view inside Chrome / Firefox. As long as the browser performs the automatic reload nothing strange happens. Everything seems to work.
Things change because of manual interaction of the user.
Anyway - tomorrow I will check the proposed combination of DB an chart service on my raspberries.
This morning I tested the ‘too many client connections’ problem with a 64 bit Windows 8.1 pro. I was not able to reproduce it. The Pi3 serves faster than the PiZeroW (surprise surprise), but I got a response on every refresh browser view action.
Only the Windows 7 pro System causes the trouble with the connections.
Interesting but bizarre…
I have a similar issue but I don’t have graphs. Running Synology OH2.3 stable with latest Java release; does this within 24 hours of a clean start (cache, tmp, logs) all cleared out.
2018-07-07 07:08:18.378 [ERROR] [me.storage.json.internal.JsonStorage] - Error writing JsonDB to /volume1/@appstore/openHAB/userdata/jsondb/org.eclipse.smarthome.core.thing.Thing.json. Cause /volume1/@appstore/openHAB/userdata/jsondb/org.eclipse.smarthome.core.thing.Thing.json (Too many open files)
I found that I had exposed over 400+ items using the “openHAB Cloud” binding; once I removed all those exposed items - my issue went away.
I’m guessing there is a bug in having so many items exposed?
Very interesting. I would recommend filing an issue against the openHAB Cloud Connector Add-on here.