Raspberry 2
Raspbian GNU/Linux 8
openHAB 2.1.0 stable
- 497508
- 133
- 750
- 1289
Had to add “-A” for ps command, too.
In addition I have two docker container running. (graphana and fhem)
I would recommend 1GB RAM is minimum for openHAB.
1 Like
That was my first gut feeling but looking at the numbers I’m getting here coupled with the knowledge that what is posted would be kind of an upper bound (i.e. VSZ includes the size of shared libraries and memory that has been swapped out of RAM so the actual amount of RAM used will be less than the numbers posted) I think it might just be possible to run a resonable OH configuration within 512 M RAM. One couldn’t run anything else (sorry Mosquitto) and I wouldn’t use Docker, but with a minimal enough of a base install if just might be reasonable. We shall see when I get the Pi to test out.
The big kicker will be the cost differences between this Banana Pi Zero and a RPi 3. If it isn’t significantly cheaper I don’t know how I could recommend it. But if it is significantly cheaper it could be a good choice to run a slave OH instance or something like that.
Rpi3 model B rev 1.2
Virtual memory: 452308
Bundles active: 122
Items: 650
Rule lines: 1677 (but I comment my rules carefully, so that’s probably got about 30% comment lines in it)
I also run my ubiquiti/unifi controller on this machine, and have it connected to an openSprinkler Pi (which shouldn’t use memory). The unifi controller is also a Java app and uses 1.5G of virtual memory. OH2 has 231M resident, Unifi has ~400M resident. MongoDB uses another 250M odd (only 50 resident), mosquitto uses very little.
I’ve always wondered whether my OH2 would benefit from more ram allocated, and conversely whether I could crank down on the unifi setup - the unifi controller can run about 500 devices, and I have 3 access points…probably I need a lot less RAM than standard.
1 Like
OH 2.2 snapshot #1081
- 4516720
- 131
- 781
- 4956
I used egrep -v "^\s*//|/\*|\*/|^\s*$" /opt/openhab2/conf/rules/*.rules | wc -l to get rid of most of the white space and comments in the rules (could be used for items files too). Still has the contents of some block comments in the count though.
1 Like
Running 2.1.0 on Intel NUC i3
- 7986656
- 145
- 5854
- 6588
I have been reducing my rules significantly by migrating the rules to node-red. Still a WIP
1 Like
Hi
On a RaspberryPi 3 with OH 2.1
- 530592
- 130 bundles
- 830 items
- 1768 lines
1 Like
All,
looking for a memory leak.
Did anyone notice a notable change in memory consumption for 2.2 release ?
Yes.
I am on 2.2. and all of a sudden, accessing the PaperUI is not possible anymore - accessing the OH page in my browser takes a long time, and I see only the OpenHAB Log Viewer tile. Until yesterday evening, everything was fine.
I see the log entry below.
Running the bash command in this this thread returns:
ps -eo vsz,command | grep openhab | grep -v grep | cut -d ’ ’ -f 1
2069920
124240
Both
ssh -p 8101 openhab@localhost ‘bundle:list | grep -c Active’
ssh -p 8101 openhab@localhost ‘smarthome:items list | grep -c .*’
I can’t test as I am not able to access the console. I will probably be able to test after rebooting my Pi.
wc -l /etc/openhab2/rules/*.rules | tail -n 1
1354
2017-12-24 03:00:55.263 [ERROR] [ore.internal.events.OSGiEventManager] - Dispatching/filtering event for subscriber ‘org.eclipse.smarthome.core.events.EventSubscriber’ failed: unable to create new native thread
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method) ~[?:?]
at java.lang.Thread.start(Thread.java:717) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:957) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1378) ~[?:?]
at org.eclipse.smarthome.core.common.QueueingThreadPoolExecutor.execute(QueueingThreadPoolExecutor.java:153) ~[109:org.eclipse.smarthome.core:0.10.0.b1]
at org.eclipse.smarthome.core.items.GenericItem.notifyListeners(GenericItem.java:228) ~[109:org.eclipse.smarthome.core:0.10.0.b1]
at org.eclipse.smarthome.core.items.GenericItem.applyState(GenericItem.java:206) ~[109:org.eclipse.smarthome.core:0.10.0.b1]
at org.eclipse.smarthome.core.items.GenericItem.setState(GenericItem.java:192) ~[109:org.eclipse.smarthome.core:0.10.0.b1]
at org.eclipse.smarthome.core.library.items.NumberItem.setState(NumberItem.java:71) ~[109:org.eclipse.smarthome.core:0.10.0.b1]
at org.eclipse.smarthome.core.internal.items.ItemUpdater.receiveUpdate(ItemUpdater.java:78) ~[109:org.eclipse.smarthome.core:0.10.0.b1]
at org.eclipse.smarthome.core.items.events.AbstractItemEventSubscriber.receive(AbstractItemEventSubscriber.java:50) ~[109:org.eclipse.smarthome.core:0.10.0.b1]
at sun.reflect.GeneratedMethodAccessor58.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [109:org.eclipse.smarthome.core:0.10.0.b1]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [109:org.eclipse.smarthome.core:0.10.0.b1]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
Unfortunately my tests on the Banana Pi were unsuccessful. Counter to my expectations, the CPU overheating was the killer problem, not running it if RAM. I’m still on a 2.2 snapshot and not seeing any problem.
I’ll report back here when I manage the upgrade in a few days if I see a memory leak problem.
For the curious, my review of the banana pi is here:
Running OH 2.5.5 in Docker on OpenMediaVault 5 (Debian 10)
- 14601760
- 150
- 657
- 1522