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).
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…
shell:info
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.
No.
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.
Cool, let us know what you notice when you compare the two as I am using the C2 currently and considering my upgrade options to gain more CPU headroom and either usb3 or sata.
“Support for these additional bootmodes will be added in the future via optional bootloader updates. The current schedule is to release PXE boot first, then USB boot.”
Just an FYI for anyone who has difficulty getting an RPi4 to work with a USB-C cable. Apparently the RPi designers ignored the USB-C specifications, so cables that are designed to spec (with an e-marker) won’t power the RPi4. Similar to a Nintendo Switch, the official RPi4 charger is fine, but it’s a bit of a guess with anything else.
Between this and the overheating issues, it seems to me that the 4 needed more rigorous testing before release. Is this typical of their development, or more unusual? I only have experience with a 3B.
My experience is that their releases are usually a little more solid than this. But it’s important to realize that all the versions of RPi from the fist one through RPi 3B+ were incremental changes. RPi 4 is a “back to the drawing board” redesign. It’s essentially a whole new board so I’m not surprised that they are having some difficulty. It’s the first time since they started that they’ve come up with a new board almost from scratch.
It’s also why I didn’t rush out to buy one. I can wait until they work out these early bugs. Designing a computer is hard.
That’s generally my stance on anything that requires electricity.
I am surprised that they designed their own USB-C circuit though, since lack of compliance among manufacturers (Nintendo, OnePlus, numerous cheap cables) has been a well-documented concern. I would have expected the RPi Foundation to reinforce the standard to push it forward.
If they weren’t going to use the USB-C standard, they might as well have just stuck with the micro-USB port. Personally, I don’t mind it for a device like an RPi that’s meant to stay plugged in at all times.
I don’t think micro-USB can supply the power necessary to drive the new chips on this board, let alone the power USB 3 devices plugged into it might draw. Even the old RPis lived on the razor’s edge when it comes to power supplies providing enough power to keep the thing running.
Ah yes, I wasn’t thinking about the limitations on current draw with micro-USB. Guess I’ll just have to look forward to the RPi 4B with USB-PD certification!
Yes and it was very much needed. All the clones were miles ahead because the older pi’s choose to keep consistent software support, over speed. I’m still waiting to see how much faster the pi4 is after the dust has settled.
The x86 boards are getting lower and lower electrical draw and work with off the shelf Ubuntu from day one of a release. 4 watts power draw at idle from an x86 system mean the lines between x86 and arm are shrinking. The cpu power of ARM is increasing and the power draw from the wall is dropping for x86.