Therory: running OH completely in RAM

So, yes controversal :slight_smile: 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).

1 Like

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

thanks for time, indeed :slight_smile:

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.

In all likelihood you have more than five Rules trying to run at the same time. See Why have my Rules stopped running? Why Thread::sleep is a bad idea.

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.

it’s my testing environment, so nothing really major
I’m probably bit bored it seems :smiley:

anyway, i’ll try if its doable just for science

What’s your rationale ?

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.

i do, where to set it?

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 :wink: )

get openHABian :wink: EXTRA_JAVA_OPTS in /etc/default/openhab2

Not the best idea. You’ll quickly land off-mainstream, resulting in all sorts of trouble noone can help you with.

Come on that’s simple. And it isn’t slow unless you have a very old install.

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 :wink:

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. :wink:

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.

You must be using some very old package or openHABian here.
It does not happen on proper installs.

unless download page serves very old package, no

Something’s wrong with your system.
Get the recent 1.5 openHABian image and start over.

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).

As with lots of things, YMMV.

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 :wink:

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 :smiley:

[11:52:08] openhabian@openhabianpi:~$ cat /etc/cron.d/firemotd
# FireMotD system updates check (randomly execute between 0:00:00 and 5:59:59)
0 0 * * * root perl -e 'sleep int(rand(21600))' && /bin/bash /opt/FireMotD/FireMotD -S &>/dev/null

:+1:

I think this will work.

cd /opt/FireMotD
sudo make uninstall

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.

unfortunately it does not look like it is somewhere in openhabian included