Thanks for the update. Great information. Please let us know how it works. Do you notice any difference? What memory version do you have?
I’ve snagged the 4gb version. My thoughts are I’ll be consolidate mysql, mosquito and OH onto the one rpi (instead of 3).
So far I’ve had
*no joy installing Zulu (install but java failed)
*no joy getting samba working (fails to part way through install)
Not smoothest start but I remain hopeful
Sounds like a good plan. I’d be very interested in the results.
Wow that is a disappointment. Still important information. I hope you will share your experiences. Maybe other forum members have solutions.
Definitely take notes as you go. I’m certain the openHABian folks will greatly appreciate your experience.
Check out my post on getting an odroid c2 working as I shared a bash script which is full of terminal commands which are proven to work on 64bit Ubuntu as java is a pain to get running manually and it took me a while to work out that method in the script. They may help you out but the pi4 is still very new it could be an issue that just needs a few weeks for some updates to get released.
< evil voice>It’s alive!</evil voice>
In the end it was a combination of problems which were solved, in part, by my liver and some sleep.
It’s been a long week and I had perhaps to many gins after coming home yesterday.
- Install Buster onto RPi4
- Install Zulu as per this post
- Install OH 2.4 as per this document
- Install samba as per this document (see note below)
- Restore the backup from your other pi.
- wait for around a minute before trying to connect.
It certainly seems to start the service quite quickly. I’ve not timed it against the other but my rpi3+ takes a number of minutes before it settles down and behaves. Will see how this one works.
Some downsides which will cause rework for me -
You cannot boot from USB3 at the moment on buster. That is coming soon but not yet.
I bought a Sandisk U3 card - it has a read of c.110MB/s and write of c.70MB/s. The USB disk, a mSATA in USB3 caddy has a 300/330 rw How much that will matter in real life? Dunno. I’ll do it though for longevity.
I’ll port over the peripherals today and run this as a production system for the next week or so. Updates to follow
For the record, this is my current RPi3
You can see, memory was a problem…
Thank you very much for this great information. Yes memory was becoming a problem. I suppose that is solved now.
As I boot my pi 3 from a ssd, I will be waiting a bit more for usb boot to become available. For anyone interested, link to documentation about missing usb boot on raspberry pi 4:
thanks for the link Mark. Interesting reading.
I read somewhere that the boot will be here shortly so not long to wait.
Never seen any ARM based OH to use way more than 700MB.
BTW only the resident part is relevant so you don’t/didn’t have problem
(ok, the difference is being paged out so it affects SD card wearout but that happens only more or less once per OH run).
What -Xms (and -Xmx) options do you use ?
I did push it up to, IIRC, 512. I did it a while ago when there was a lot of chatter about the rules and them being cached. I have a lot of quick-run rules and thought it would help.
Another update -
This is the rpi3B+ after (service) running for a day, during the day.
Some interesting start times, and while it’s not conclusive, it’s interesting
Above is the time diff between the following lines in the log
[.core.internal.i18n.I18nProviderImpl] - Locale set to 'en_GB'.
[ternal.dhcp.DHCPPacketListenerServer] - DHCP request packet listener online
Between those two lines in the log file all items, things and rules are loaded. I figure it’s a good enough set of markers. If there is a better option then I’ll remeasure it.
Below is the htop of the RPi4 after 20ish minutes of running my “production” OH2 setup.
the early morning stops and starts are thanks to insomnia. Nothing like working on home automation when you can’t sleep
Correction - I have the following:
xmx650 / xms400
Question - On the 4GB model, any benefit in making that higher now? Or leave it default?
Thanks for the info. I now definitely want a rp4 now. Just waiting for the USB boot.
I hear you. Where is the ‘help me sleep’ binding when you need it.
Which explains your high memory “demand”.
Xms is the relevant one, and 256M is way enough to cache all rules.
As it’s not openHABian I don’t know the defaults so can’t answer.
As I said Xms 256M is sufficient, the rest means waste of mem and more paging to disk (SD).
thanks for the info. I will dig out my notes on why I increased it at the time and start another thread for it. I’d like to understand why
For how many rules?
The amount „all“ is difference for every installation.
Result of a number of tests and default in openHABian (and effectively in most others, too).
There would have been complaints.
You know for yourself that there cannot be an exact answer.
But 256M is also the Xmx default that probably most people still run. Java crashes when it needs more mem.
xmx is the far more important one to set right, oracle recommends setting them both to the same value to prevent resources being used resizing the heap all the time… Too big a value of xmx is not good due to GC and a value too small means the GC has to run more often which is also not good. A balanced value gives best results.
My advice is to run this in karaf and actually see what your system is using and use that to set the value…
The look at the memory heap lines, for example mine are…
Memory Current heap size 432,184 kbytes Maximum heap size 760,256 kbytes Committed heap size 760,256 kbytes Pending objects 0 Garbage collector Name = 'Copy', Collections = 61, Time = 7.315 seconds Garbage collector Name = 'MarkSweepCompact', Collections = 4, Time = 2.408 seconds
A few minutes later I ran it again just after GC and this output…
Memory Current heap size 280,743 kbytes Maximum heap size 760,256 kbytes Committed heap size 760,256 kbytes Pending objects 0 Garbage collector Name = 'Copy', Collections = 67, Time = 7.508 seconds Garbage collector Name = 'MarkSweepCompact', Collections = 4, Time = 2.408 seconds
From looking at my system I see my current heap changes from 480mb to 280mb and it just bounces between these two values. I clearly can not run my system on 256 and I am too close to 512 as I have seen OOME on 512 recently so I have set mine at 768m
My system has 2gb of ram and trying such a high value would not work on a 1gb setup.
See what your system uses as the heap is used for everything running inside java and not just rules.
If talking about memory usage it is Xms. That’s the heap mem Java pre-allocates on start and where it puts the compiled rules. If it’s too small (like the default is), rules need to be compiled on subsequent executions, too, which causes lags.
Xmx is important, too. If OH ever requests more mem than that, Java will crash.
However the vast majority of users runs the default (256M on ARM !) without problems, in openHABian I raised it to 350 but you have 650 already. No need to increase further.
In fact doing so is harmful. Not due to garbage collection as you write. But it creates more paging to SD card so thatt wears out faster.
But we’re getting off-topic. Any next discussion please in appropriate threads not here.