So, yes controversal but anway I do have a 24/7 computer which I’m using as mediacenter only, that thing has got plenty of unuset ram >14gb so that got me thinking… can OH run completely from RAM?
I mean, let’s assume I can handle config files and syncing after reboot, but what if I create 8gb ramdisk and put whole OH there? or run openhabian in virtualised environment which runs in ram only.
Are there some known/unknown limitations?
It’s not mission critical, but why not to try something new ;]
I can’t think of any reason why it wouldn’t work. 8 GB would be way overkill. You could probably make due with 2 GB (my current install is sitting at 2.6 GB but 1.7 GB of that is my .git folder and another 500 MB of that are OH logs, I have a couple of bindings configured with trace logging level so I’m generating a lot of logs right now).
Obviously YMMV but I would expect 2-3 GB would give most users plenty of room to expand.
Of course there may be limitations but I suspect you are aware. Since you’d be running from a tempfs, the entire file system will get wiped on a reboot. So your OH would not be able to persist anything that you need to preserve from one boot to the next (I’m not talking about OH Persistence which you can run a traditional external database in the traditional way for that). You will also need to modify the start script (I’m assuming a .service file) to copy OH and all it’s configs every time you reboot. If you don’t include userdata/cache and userdata/tmp this also means that OH will have to reinstall all of your bindings every time you reboot.
But in general, whether the file system is a tempfs or on physical media is transparent to OH (or any other program you want to run). But those programs will not expect the file system to be wiped on every reboot so you need to think about what gets written to disk.
I’m not sure what you would gain by doing this though. Except for logging and persistence, OH is a pretty disk read/write light application. I suppose it could restart faster (but not the first start after a boot in which case it will start much more slowly).
I was recently watching rules gets triggered with bit of lag and cpu seems to be almost always idling (not really sure if its because config 53, delay rules - which I believe is only during boot) so I was thinking it might improve overall performance as ram is way faster than disk.
As I said it’s more about education myself what and how can be done.
Is there any list of folders which are essential for OH to keep? (besides /etc/openhab2/)
eg. installed addons, configuration made in paperUI and so on
Only if the bottleneck is disk IO. Before going through a lot of effort to move OH to a tmpfs, maybe spend a little time proving that is in fact the source of your problem.
I’d be very surprised this is your problem. Once Rules are loaded into memory at OH start time they remain in memory. Disk IO can’t cause the lag. Moving to a tmpfs will improve how quickly those Rules can be loaded in the first place, not in how they run.
There is no list. You can skip userdata/tmp and userdata/cache, but if you do OH will have to download and reinstall all the add-ons every time you reboot.
If it’s about SD or other flash wearout then check out zram implementation in latest openHABian 1.5.
It’s selectively doing that for a list of directories you can specify.
Effectively it’s not required (and not beneficial) to move everything into RAM, it’s sufficient to move those dirs (and swap !) into ram that would otherwise write to disk which is those specified in /etc/ztab (these you can extend if you want to).
If that’s your rationale this is likely due to compiled rules being garbage collected. Increase -Xms java parameter to 250m or more. Quadruple that number if you run on 64bit x86.
Yes that’s only changing the load order on OH startup.
seen that, but rather than habian I would prefer dietPI in case of rpi deployment (I really hate habian’s FireMOTD which is slow as hell and I did not researched how to remove it yet )
i don’t have old install, actually it’s like 2days old on rpi 3b+ and i really hate firemotd when loggin in to ssh and have to wait couple of seconds till I can actually write something to shell.
I’m not hating habian, just using something else. If there will be an easy way how to disable firemotd completely, will do as first thing I can when installing habian
Till now I don’t really see any differencies between running habian or anything else what one likes.
I have rpi3b+ and rpi3b and rpi4 for testing running habian or dietpi and must say they act like twins
Also have a look at all the levels of caching there are nowdays:
Most desktop processors usually have 3 levels of caching (L1, L2, L3) ranging from 4MB-50MB
Applications (openHAB) are programmed such that frequently accessed data is kept in memory and not continuously loaded from disk
The OS is already using unused memory for disk caching. That’s why on Linux it appears as if all your RAM is eaten (https://www.linuxatemyram.com/)
OS-es prefetch the data of frequently used applications
Desktop/server harddisk have hundreds and even gigibytes of cache
Because of all this caching, trying to further optimize performance by manually loading files into memory usually doesn’t give big performance improvements.
It may even result in less performance because all automatic optimizations now have less memory to work with.
On embedded devices that don’t have a lot of memory and where you want to prevent writes to SD-cards it does make sense to tune this.
I think it’s just a line in your .profile or .bashrc.
I tend to keep it up to date and while I like it, it is pretty slow.
When everything works, they work the same. When something stops working we won’t be able to help much is Markus’s point. If you know what you are doing there’s no problem as you should be able to stand on your own. but if you need help or don’t know what you are doing, running dietPi will greatly hinder our ability to help if something goes south.
I only have one install from openHABian and manual installs on my other machines. Even on beefy VMs (compared to RPi) it takes one to two seconds for FireMotD to let me have my prompt. It’s worse on the RPi 1s and 0Ws. I pull and rebuild from github FireMotD a couple times a week (it’s part of my update Ansible playbooks).
Oh you’re right seems I have deactivated it myself so long ago that I have even forgotten about.
But there also once was a bug where it took really long. That at least has been fixed.
You might be right on this, actually it’s probably too much effort with little or none effect, it came to my mind when I’m playing with different scenarios/setups/systems/platforms and OH together.
Just something to talk about really
to disable appearence probably yes, but it’s doing some stuff after apt update as well which seems unnecessary for me
Have to figure out how to remove it if possible
I don’t even know why I’m so bothered with it honestly, but for some reason it’s like red flag
I didn’t study the makefile to see how thorough the uninstall is but that should remove the cron jobs and entries in the shell init files. Test to see if you are happy after running that and if so, delete /opt/FireMotD.