Yes, it worked! I apologize, I did not carefully read the previous posts, I realized that you solved the problem, but did not understand how 
(I do not know English)
Now here is my data:
2.2.0-SNAPSHOT build 1082 running on an Ubuntu 16.04
I used ps -eo vsz,command | grep openhab | grep -v grep | cut -d ' ' -f 1
productive OH2 (openHAB 2.1.0-1 (Release Build)) on Raspberry Pi 2 Model B Rev 1.1
second test & half-productive OH2 (openHAB 2.1.0-1 (Release Build)) on Raspberry Pi 3 Model B Rev 1.2
external productive OH2 (openHAB 2.1.0-1 (Release Build)) on Raspberry Pi Model B Rev 2
Running the first command I get two lines:
122564
474868
The first one is frontail and the second is Java running openhab.
As for the others
135 active bundles
246 items
814 lines of code in rules
Raspberry Pi 3 Model B Rev 1.2 running Raspbian Jessie
I’m happy to help out. However:
Returns nothing.
Returns 4317888.
After logging on to Karaf:
Returns “0”.
Returns the full list. It seems I have 125 active bundles.
Returns also “0”.
Returns the full list. I have 673 items.
Returns “2236”.
Probably all due to the fact I run OH 2.2 in chroot on a Synology environment.
Summary:
Raspberry Pi 3 Model B running Raspbian
Kevin
That sounds reasonable based on what everyone else is reporting.
I don’t understand why -c works for some users and not others.
Thanks for posting!
| Operating System | Raspbian GNU/Linux 9 |
| Java Version | Zulu Embedded 8.20.0.42-linux-aarch32hf (build 1.8.0_121-b42) |
| openHAB Version | 2.2.0-SNAPSHOT (#1077) |
| Memory | 532060 kB |
| Active Bundles | 122 |
| Items | 80 |
| Lines of rule script . | 212 |
ok, thanks much for your help
here we go:
1: 2782400
2: 136 active bundles
3: 213 items
4: 372 lines of rules
Raspberry Pi 3 Model B
Raspbian GNU/Linux 8
2.2.0-SNAPSHOT Build #1078
1: 477528 KB
2: 132 bundles
3: 647 items
4: 2375 lines of rules
Raspberry 2
Raspbian GNU/Linux 8
openHAB 2.1.0 stable
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.
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.
OH 2.2 snapshot #1081
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.
Running 2.1.0 on Intel NUC i3
I have been reducing my rules significantly by migrating the rules to node-red. Still a WIP
Hi
On a RaspberryPi 3 with OH 2.1
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)