I was experiencing only the “not mapped for I/O” version. Have upgraded a few times via openhabian. Some suggestions above which did not work for me:
I’ve exactly the same issue with openhabian / OH3.1 (staple version) and tried all the suggestions but not works and get sporadic the same error message:
[ERROR] [d4j.internal.RRD4jPersistenceService] - Could not create rrd4j database file ‘/var/lib/openhab/persistence/rrd4j/eSmartMeterGesamtleistung.rrd’: null
If I check this Item, then I see the values from the persistence DB e.g. Item “eSmartMeterGesamtleistung” but only a value each 15min (no matter what I change in the persistence file).
But if I open this Item then I see no values in OH UI.
The persistence rrd4j is installed and is set as default.
Here are my file:
Strategies {
everyMinute : "0 * * * * ?"
everyHour : "0 0 * * * ?"
everyDay : "0 0 0 * * ?"
default = everyChange
}
Items {
* : strategy = everyChange, everyDay, restoreOnStartup
eSmartMeterGesamtleistung : strategy = everyChange, restoreOnStartup
}
rrd4j requires at least an everyMinute strategy for all that data it stores. If your Item is not changing once a minute.
That’s not the source of the error in the log but it likely is why you are not seeing anything in the chart.
I do question that your rrd4j DB stored no minute-wise data. You showed a persistence viewer page that asks for data of the last month! Look into the docs and you will see that for such timeframe a 15 mi ute step is by design!
@rlkoshak : Sorry, but after the change to version 3 rrd4j the requirement for everyMinute was replaced by a minimum sample interval of 20 seconds as set in the rrd4j.cfg.
In other words the reason for not showing a graph is unknown ( at least to me ATM).
You’re right. My mistake. The filter for date was not correct.
Now I see each minute a value.
But the issue is the same. I see no values on the graph ;-(
Yes, it is a group item type:number aggregation:SUM.
It seems that is a known issue…
Hi all,
After upgrade from 3.0.x to 3.1.0 I get the same error :“Could not create rrd4j database file ‘/var/lib/openhab/persistence/rrd4j/xxxxx.rrd’: Map failed”
And few hours later lot of memory errors and OH is globaly KO.
Upgrade last week and it occured two times since.
Restart fix this.
Your root problem is a memory problem, not rrd4j. That error means that the OS would not give openHAB the RAM it needed to write out to the rrd file. So it’s a symptom caused by some other problem and not related to rrd4j.
Hi @rlkoshak
Thanks for your answer.
Ok I understand it is probably a memory problem but it is strange that the first thing to crash is rrd4j for hours.
I have a dedicated raspberry PI4 4Go for OH3, and I think that when it crashes it never goes beyond 2Go.
Perhaps I could manually tell openhab to use more than 2G RAM but I dont know how to do. (some researches point me to XMX and XMS java parameter, but I dont know to configure it…)
rrd4j is very busy on a typical OH instance, probably the most active single part of the system. It’s not unexpected that it would be the first to complain when memory becomes a problem.
Java is limited to a certain amount of memory which, by default, is a certain percentage of the total amount of RAM. A Java program will start to have out of memory errors long before the machine itself runs out of memory.
You can give the Java process more memory through command line arguments but all that really ends up doing is buying you a little more time before the out of memory errors start to occur. The root problem is there is a memory leak somewhere in OH core or more likely one of the add-ons you are using. OH can and does work just fine with the default settings. If you are running out of memory adding more is not going to help.
OK thanks for details and explanations.
I will give up to add memory in java in this case.
I will try to identify the plugin for the memory leak but there is nothing relevant in logs.
Do you know where can I get the memory allocations for OH3 ? (for each plugin and core if available ?)
Many thanks
Search through the out of memory threads posted here on the forum for lots of techniques. But usually you can’t get something like “binding X is using Y amount of RAM”.
Hello everyone! Just hit this problem today. I think it’s most likely zram space overrun. I have lots of items and, indeed, some of them update quite frequently. I’ve also noticed “device i/o error” in kernel log.
There were many large files in the persistence storage dir. 700 k or even 7mb each.
Another problem caused by this is that openhab stops responding to controls.
Is it possible to limit number of stored values? I’ve read the doc but didn’t find the exact answer
And another question. My system has a hard drive for the exact this purpose. How to relocate the rrd4j storage? Or is the only way to go is to mount it on top of /var/lib/openhab/persistence?
@funcat no, adding more memory for java won’t solve the problem as it will actually take it away from zram.
Hi @Sonic
Yes I agree. I made some tests and adding memory for java just give me some additionnal time before crash.
FYI I run OH3 on raspbian as application (raspberry with SSD), so I dont have zram.
I am still running with memory leaks, and i dont find the problem.
I made a lot of tests, and I think that multiple addons have memory leak problem. (ipcamera, gardena… and i suspect samsungtv binding also and interaction with visual studio when connection are still open).
At the end of memory, always same symptoms : flooding RRD4J issue and few hours later a crash or even restart of OH.
Now my config can stand 3-4 weeks before EOM restart.
rrd4j files are fixed. They don’t grow but they don’t shrink either.
What you can do is limit which Items are saved. Persistence | openHAB
rrd4j has a lot of configuration options but where it saves the files is not one of them.
You can edit /etc/ztab to spend more memory to your persistence data (reboot needed).
Settings are optimized for 1GB machines. If you have more RAM you can easily double the values but even with 1GB only you can increase them a little.
zramctl --output-all will give you a good indication what limits you might have hit.
We just merged a PR that raise limits on new installs of systems with 2+ GB.
Aha, so on init of each container (aseparate file) a fixed N slots are allocated to store the respective value. So is it possible to at least edit this N to make files shorter? By the way, by default, how many values are stored?
