Openhab filling up Memory and Swap


i described my root problem in this post but there was no responce since some weeks so i’m trying it here again…
In short words: Openhab is filling up Memory until the System crashes.

My old installation was a mess by updating/reverting from stable to testing to beta and back with backups from the old installation and also adding/removing bindings and so on.
So i decided to do a complete fresh setup.

Here are some setup infos:

Raspberry Pi 3 B+
openHAB 2.4.0-1 (Release Build) (installed with openhabian)
Openhab App on three wall mounted FireHD tablets for controlling OH (the app is permanently running).
Openhab App Version: 2.5.0 - 24.11.2018
All tablets have a satic ip assigned. W-Lan Signal of the tablets is ~ 99%. 3 APs, one in each floor.

Since i wanted a very slick installation i only have some cron triggered rules (open/closing shutters) and also some expire rules based on this design pattern for turning lights off which my wife forgot to turn off :wink:

Following bindings are installed:

Installed Bindings:

194 │ Resolved │ 75 │ 2.4.0 │ org.openhab.ui.basicui
197 │ Resolved │ 75 │ 2.4.0 │ org.openhab.ui.paperui
206 │ Active │ 80 │ 2.4.0 │ org.openhab.binding.knx
212 │ Active │ 80 │ 1.13.0 │ org.openhab.persistence.mapdb
213 │ Active │ 80 │ 1.13.0 │ org.openhab.action.mail
214 │ Active │ 80 │ 1.13.0 │ org.openhab.binding.expire

The java heap oom from my initial post vanished… but… openhab is still filling up ram on the pi.

Then i did some tests…
i closed all Openhab Apps on the Android Tablets, rebooted the raspberry and monitored ram usage on the raspberry:

070119 - 07:00 after reboot

all clients/tablets disabled

System Memory: OK - RAM used: 316.39 MB of 976.74 MB, Swap used: 0.00 B of 100.00 MB, Total virtual memory used: 316.39 MB of 1.05 GB (29.4%),
OPENHAB Process: OK - 3 processes 851.9 MB virtual, 313.8 MB physical, 53.4% CPU, youngest running for 85 sec, oldest running for 90 sec

after about 23 hours the ram usage was quite stable which you can also see on this screenshots:

then i opened the openhab app on all three tablets and the system memory usage increased slowly till memory and swap are full:

080119-0648 - starting openhab android apps

System Memory: OK - RAM used: 337.94 MB of 976.74 MB, Swap used: 0.00 B of 100.00 MB, Total virtual memory used: 337.94 MB of 1.05 GB (31.4%),
OPENHAB Process: OK - 3 processes 865.0 MB virtual, 334.9 MB physical, 1.7% CPU, youngest running for 23 hours, oldest running for 23 hours


System Memory: CRIT - RAM used: 902.36 MB of 976.74 MB, Swap used: 99.93 MB of 100.00 MB, Total virtual memory used: 1002.29 MB of 1.05 GB (93.1%, warn/crit at 80.0%/90.0%)
OPENHAB Process: OK - 3 processes 919.3 MB virtual, 588.9 MB physical, 113.8% CPU, youngest running for 46 hours, oldest running for 46 hours

currently i did not enable any debug logging, wanted to wait for advice which is best for this problem.

soooo, where is the root of my problem?
anyone an idea? what else can i provide to help troubleshooting?

thanks in advance!



1 Like

Are you using any image items?
Start by removing each binding one by one to see if the problem goes away. Strip things back until the issue stops. Also look in the syslog

Thanks for your anwer. no i’m not using any image items. but which binding do you expect me to uninstall? knx? ok but this makes the expire binding and all the basic automation also obsolete and becomes a plain openhab installation. also my sitemap would be obsolete because there wouldn’t be any items to display/refresh. i’ve already stripped down to a basic level of my setup in a completly fresh setup. usually i’m also using homematic, hue, astro, harmony hub, network, squeezebox, weather and wol binding, mail and telegram action. i’m fighting a lot with this issues for weeks now without any success.

as i already wrote there are only some rules active currently which are all quite the same.
here are some example rules:


rule "Bad Raffstore Down"
        Time cron "0 30 18 1/1 * ? *"
		if (OG_KNX_Bad_Raffstore.state < 100) {
		    logInfo("beschattung_bad.rules","Bad: Raffstore wird runtergefahren.")
                    sendMail("", "Bad: Raffstore Down", "Bad: Raffstore wird heruntergefahren")

rule "Bad Raffstore Up"
        Time cron "0 30 06 ? * MON-FRI *" or
	Time cron "0 30 07 ? * SAT-SUN *"
				if (OG_KNX_Bad_Raffstore.state >= 95) {
               logInfo("beschattung_bad.rules","Bad: Raffstore wird hochgefahren.")		
	       sendMail("", "Bad: Raffstore Up", "Bad:Raffstore wird hochgefahren")

lights auto off:

rule "Buero Beleuchtung check Auto Timer"

	Item KG_KNX_Buero_Licht changed from ON to OFF
	if(Beleuchtung_Auto_Aus_Buero_KG.state == OFF) {
	logInfo("beleuchtung.rules","Setzte Auto Aus für Buero.")

rule "Buero Beleuchtungs Timer An"

	Item KG_KNX_Buero_Licht changed from OFF to ON
	if(Beleuchtung_Auto_Aus_Buero_KG.state == ON) {
	logInfo("beleuchtung.rules","Setzte Timer für Licht Buero KG.")
rule "Buero Beleuchtungs Timer Aus"

	Item Beleuchtung_Auto_Timer_Buero_KG received command OFF
	if(Beleuchtung_Auto_Aus_Buero_KG.state == ON && KG_KNX_Buero_Licht.state == ON) {
	logInfo("beleuchtung.rules","Timer abgelaufen, schalte Buero KG Licht aus.")
	else {
	logInfo("beleuchtung.rules","Büro Timer abgelaufen, aber nicht aktiv.")

and here’s my sitemap:

sitemap home label="Seho" {

						Frame label="Tür und Kamera" icon="camera" {
										Switch item=KG_KNX_Haustuere_Schloss mappings=[ON="Öffnen"]
	Frame label="Beleuchtung" {
			Text label="Übersicht Eingeschaltene" icon="zoom" {
				Switch item=KG_KNX_Hwr_Licht visibility=[KG_KNX_Hwr_Licht==ON]
				Switch item=KG_KNX_Buero_Licht visibility=[KG_KNX_Buero_Licht==ON]
				Switch item=KG_KNX_Lager_Licht visibility=[KG_KNX_Lager_Licht==ON]
				Switch item=KG_KNX_Technik_Licht visibility=[KG_KNX_Technik_Licht==ON]
				Switch item=KG_KNX_Garage_Licht visibility=[KG_KNX_Garage_Licht==ON]
				Switch item=EG_KNX_Awc_Licht visibility=[EG_KNX_Awc_Licht==ON]
				Switch item=EG_KNX_Kueche_Arbeitsflaeche_Licht visibility=[EG_KNX_Kueche_Arbeitsflaeche_Licht==ON]
				Switch item=EG_KNX_Kueche_Fenster_Licht visibility=[EG_KNX_Kueche_Fenster_Licht==ON]
				Switch item=EG_KNX_Kueche_Decke_Licht visibility=[EG_KNX_Kueche_Decke_Licht==ON]
				Switch item=EG_KNX_Esstisch_Decke_Licht visibility=[EG_KNX_Esstisch_Decke_Licht==ON]
				Switch item=EG_KNX_Schreibtisch_Decke_Licht visibility=[EG_KNX_Schreibtisch_Decke_Licht==ON]
				Switch item=EG_KNX_Wohnzimmer_Decke_Licht visibility=[EG_KNX_Wohnzimmer_Decke_Licht==ON]
				Switch item=EG_KNX_Terrasse_Licht visibility=[EG_KNX_Terrasse_Licht==ON]
				Switch item=OG_KNX_Gang_Decke_Licht visibility=[OG_KNX_Gang_Decke_Licht==ON]
				Switch item=OG_KNX_Treppenhaus_Decke_Licht visibility=[OG_KNX_Treppenhaus_Decke_Licht==ON]
				Switch item=OG_KNX_Treppenhaus_Stiegen_Licht visibility=[OG_KNX_Treppenhaus_Stiegen_Licht==ON]
				Switch item=OG_KNX_Bad_Decke_Licht visibility=[OG_KNX_Bad_Decke_Licht==ON]
				Switch item=OG_KNX_Bad_Spiegel_Licht visibility=[OG_KNX_Bad_Spiegel_Licht==ON]
				Switch item=OG_KNX_Kizi1_Decke_Licht visibility=[OG_KNX_Kizi1_Decke_Licht==ON]
				Switch item=OG_KNX_Kizi2_Decke_Licht visibility=[OG_KNX_Kizi2_Decke_Licht==ON]
				Switch item=OG_KNX_Schlafzimmer_Decke_Licht visibility=[OG_KNX_Schlafzimmer_Decke_Licht==ON]
				Text label="Kellergeschoß" icon="cellar" {
				Switch item=KG_KNX_Hwr_Licht
				Switch item=KG_KNX_Buero_Licht
				Switch item=KG_KNX_Lager_Licht
				Switch item=KG_KNX_Technik_Licht
				Switch item=KG_KNX_Garage_Licht
				Text label="Erdgeschoß" icon="groundfloor" {
				Switch item=EG_KNX_Awc_Licht 
				Switch item=EG_KNX_Kueche_Arbeitsflaeche_Licht
				Switch item=EG_KNX_Kueche_Fenster_Licht
				Switch item=EG_KNX_Kueche_Decke_Licht
				Switch item=EG_KNX_Esstisch_Decke_Licht
				Switch item=EG_KNX_Schreibtisch_Decke_Licht
				Switch item=EG_KNX_Wohnzimmer_Decke_Licht
				Switch item=EG_KNX_Terrasse_Licht
				Text label="Obergeschoß" icon="firstfloor" {
				Switch item=OG_KNX_Treppenhaus_Stiegen_Licht
				Switch item=OG_KNX_Treppenhaus_Decke_Licht
				Switch item=OG_KNX_Gang_Decke_Licht
				Switch item=OG_KNX_Bad_Decke_Licht
				Switch item=OG_KNX_Bad_Spiegel_Licht
				Switch item=OG_KNX_Kizi1_Decke_Licht
				Switch item=OG_KNX_Kizi2_Decke_Licht
				Switch item=OG_KNX_Schlafzimmer_Decke_Licht
				Text label="Terrasse" icon="garden" {
				Switch item=EG_KNX_Terrasse_Licht
		Frame label="Raffstore" {
				Text label="Übersicht Geschlossene" icon="zoom" {
				Switch item=KG_KNX_Buero_Raffstore mappings=[UP="Hoch", STOP="X", DOWN="Runter"] visibility=[KG_KNX_Buero_Raffstore>0]
				Switch item=EG_KNX_Essbereich_Raffstore mappings=[UP="Hoch", STOP="X", DOWN="Runter"] visibility=[EG_KNX_Essbereich_Raffstore>0]
				Switch item=EG_KNX_Schreibtisch_Raffstore mappings=[UP="Hoch", STOP="X", DOWN="Runter"] visibility=[EG_KNX_Schreibtisch_Raffstore>0]
				Switch item=EG_KNX_Couch_Raffstore mappings=[UP="Hoch", STOP="X", DOWN="Runter"] visibility=[EG_KNX_Couch_Raffstore>0]
				Switch item=EG_KNX_Terasse_Raffstore mappings=[UP="Hoch", STOP="X", DOWN="Runter"] visibility=[EG_KNX_Terasse_Raffstore>0]
				Switch item=EG_KNX_Kueche_Raffstore mappings=[UP="Hoch", STOP="X", DOWN="Runter"] visibility=[EG_KNX_Kueche_Raffstore>0]
				Switch item=OG_KNX_Bad_Raffstore mappings=[UP="Hoch", STOP="X", DOWN="Runter"] visibility=[OG_KNX_Bad_Raffstore>0]
				Switch item=OG_KNX_Kizi1_Raffstore_Rechts mappings=[UP="Hoch", STOP="X", DOWN="Runter"] visibility=[OG_KNX_Kizi1_Raffstore_Rechts>0]
				Switch item=OG_KNX_Kizi1_Raffstore_Links mappings=[UP="Hoch", STOP="X", DOWN="Runter"] visibility=[OG_KNX_Kizi1_Raffstore_Links>0]
				Switch item=OG_KNX_Kizi2_Raffstore_Rechts mappings=[UP="Hoch", STOP="X", DOWN="Runter"] visibility=[OG_KNX_Kizi2_Raffstore_Rechts>0]
				Switch item=OG_KNX_Kizi2_Raffstore_Links mappings=[UP="Hoch", STOP="X", DOWN="Runter"] visibility=[OG_KNX_Kizi2_Raffstore_Links>0]
				Switch item=OG_KNX_Schlafzimmer_Raffstore mappings=[UP="Hoch", STOP="X", DOWN="Runter"] visibility=[OG_KNX_Schlafzimmer_Raffstore>0]
				Text label="Raffstore Kellergeschoß" icon="cellar" {
				Switch item=KG_KNX_Buero_Raffstore mappings=[UP="Hoch", STOP="X", DOWN="Runter"]
				Text label="Raffstore Erdgeschoß" icon="groundfloor" {
				Switch item=EG_KNX_Essbereich_Raffstore mappings=[UP="Hoch", STOP="X", DOWN="Runter"] 
				Switch item=EG_KNX_Schreibtisch_Raffstore mappings=[UP="Hoch", STOP="X", DOWN="Runter"]
				Switch item=EG_KNX_Couch_Raffstore mappings=[UP="Hoch", STOP="X", DOWN="Runter"]
				Switch item=EG_KNX_Terasse_Raffstore mappings=[UP="Hoch", STOP="X", DOWN="Runter"]
				Switch item=EG_KNX_Kueche_Raffstore mappings=[UP="Hoch", STOP="X", DOWN="Runter"]
				Text label="Raffstore Obergeschoß" icon="firstfloor" {
				Switch item=OG_KNX_Bad_Raffstore mappings=[UP="Hoch", STOP="X", DOWN="Runter"]
				Switch item=OG_KNX_Kizi1_Raffstore_Rechts mappings=[UP="Hoch", STOP="X", DOWN="Runter"]
				Switch item=OG_KNX_Kizi1_Raffstore_Links mappings=[UP="Hoch", STOP="X", DOWN="Runter"]
				Switch item=OG_KNX_Kizi2_Raffstore_Rechts mappings=[UP="Hoch", STOP="X", DOWN="Runter"]
				Switch item=OG_KNX_Kizi2_Raffstore_Links mappings=[UP="Hoch", STOP="X", DOWN="Runter"]
				Switch item=OG_KNX_Schlafzimmer_Raffstore mappings=[UP="Hoch", STOP="X", DOWN="Runter"]

		 Frame label="Temperatur" {
			    Text label="Übersicht" icon="zoom" {
				Text item=KG_KNX_Garage_Temperatur				label="Temperatur Garage [%.1f °C]"
				Text item=KG_KNX_Buero_Temperatur				label="Temperatur Büro [%.1f °C]"
				Text item=EG_KNX_Wohnzimmer_Temperatur 			label="Temperatur Esszimmer [%.1f °C]"
			Text label="Keller" icon="cellar" {
				Text item=KG_KNX_Garage_Temperatur				label="Temperatur Garage [%.1f °C]"
				Text item=KG_KNX_Buero_Temperatur				label="Temperatur Büro [%.1f °C]"

			Text label="Erdgeschoß" icon="groundfloor" {
				Text item=EG_KNX_Wohnzimmer_Temperatur 			label="Temperatur Esszimmer [%.1f °C]"
		Frame label="Einstellungen"  {
			Text label="Beleuchtung" icon="light" {
			Switch item=Adrian_Abend_Auto_Licht labelcolor=["ON"="green","OFF"="red"]
			Switch item=Jana_Abend_Auto_Licht labelcolor=["ON"="green","OFF"="red"]
			Switch item=Beleuchtung_Auto_Aus_Technik_KG labelcolor=["ON"="green","OFF"="red"]
			Switch item=Beleuchtung_Auto_Aus_Garage_KG labelcolor=["ON"="green","OFF"="red"]
			Switch item=Beleuchtung_Auto_Aus_Lager_KG labelcolor=["ON"="green","OFF"="red"]
			Switch item=Beleuchtung_Auto_Aus_Hwr_KG labelcolor=["ON"="green","OFF"="red"]
			Switch item=Beleuchtung_Auto_Aus_Buero_KG labelcolor=["ON"="green","OFF"="red"]
			Switch item=Beleuchtung_Auto_Aus_WC_EG labelcolor=["ON"="green","OFF"="red"]
			Switch item=Beleuchtung_Auto_Aus_Gang_OG labelcolor=["ON"="green","OFF"="red"]
			Switch item=Beleuchtung_Auto_Aus_Treppenspots_OG labelcolor=["ON"="green","OFF"="red"]
			Text label="Raffstore" icon="blinds" {
			Switch item=Raffstore_Autobeschattung labelcolor=["ON"="green","OFF"="red"]
			Switch item=Raffstore_Urlaubsmodus_Jana labelcolor=["ON"="green","OFF"="red"]
			Switch item=Raffstore_Urlaubsmodus_Adrian labelcolor=["ON"="green","OFF"="red"]
			Switch item=Raffstore_Urlaubsmodus_Schlafzimmer labelcolor=["ON"="green","OFF"="red"]
			Switch item=Raffstore_Gaestemodus_Buero labelcolor=["ON"="green","OFF"="red"]
			Switch item=Raffstore_Auto_Lamellen_Jana labelcolor=["ON"="green","OFF"="red"]
			Switch item=Raffstore_Auto_Lamellen_Adrian labelcolor=["ON"="green","OFF"="red"]
			Switch item=Raffstore_Auto_Lamellen_Eltern labelcolor=["ON"="green","OFF"="red"]

so which logs do you want me to debug?



I don’t necessarily see anything fundamentally wrong here (yet).
OH uses a lot of memory and Java never releases any to the public. But any unused mem is paged out after enough inactivity so swap grows, too.

Check the -Xms and -Xmx options Java is started with (/etc/default/openhab2) and eventually reduce them to 250m/350m to see if that makes a difference. Note the latter is the maximum heap size that if reached makes the Java process crash (but that does not apply if it’s something other than the heap to grow).

Other than that as @matt1 proposed try removing bindings and UIs to identify if one of them is the culprit (I recently disabled Hue in my setup as that apparently caused my OH to grow beyond bounds).

1 Like

ok i changed the heap size from
EXTRA_JAVA_OPTS="-Xms400m -Xmx512m -XX:+HeapDumpOnOutOfMemoryError"
EXTRA_JAVA_OPTS="-Xms250m -Xmx350m -XX:+HeapDumpOnOutOfMemoryError"
and restarted the pi.

the android openhab app clients on the tablets are active. lets see what happens.
if memory again grows i will start removing the last bindings… starting with mail action and expire binding.
the last binding will be knx because if i remove this the others get obsolete and also the sitemap is useless.

in my personal opinion the android openhab app is causing some problems on/in the server.
because if they are not running (as written in my first post) the memory usage is stable.

I agree there is an issue because…

  1. You see a problem that you describe as a crash.
  2. The Swap should stay empty as it is not a good thing to use slow flash instead of ram unless your system is trying it as a last ditch attempt as the ram is full.
  3. The ram filling up like that is a classic memory leak symptom.

Recently I had issues when I specified -Xms, never tracked it down so I always run without it, the heap dump is optional…


To help narrow it down try this and paste the output here so we can look at it…

In the openhab console run this command.


Also look in your syslog file for any clues.

 sudo nano /var/log/syslog

Also remove all rules and see if the problem goes away, it could be something like a rule is stuck in a loop creating timers and filling up the ram.

You are just going to have to use a process of elimination to find the cause if the logs do not give clues. This means remove rules, remove bindings, remove half your items…etc…

the java extra opts were defaults in the openhabian installation… never had problems with them…
but i will give it a try in some hours. i configured the heap dump option because of the java heap oom’s
i had with my older installations as shown in this post.

and as requested the shell:info output:

Karaf version 4.2.1
Karaf home /usr/share/openhab2/runtime
Karaf base /var/lib/openhab2
OSGi Framework org.eclipse.osgi-3.12.100.v20180210-1608

Java Virtual Machine OpenJDK Client VM version 25.152-b76
Version 1.8.0_152
Vendor Azul Systems, Inc.
Pid 486
Uptime 1 hour 11 minutes
Process CPU time 6 minutes
Process CPU load 0.02
System CPU load 0.03
Open file descriptors 207
Max file descriptors 102,642
Total compile time 30.395 seconds
Live threads 109
Daemon threads 59
Peak 136
Total started 694
Current heap size 90,483 kbytes
Maximum heap size 346,496 kbytes
Committed heap size 247,680 kbytes
Pending objects 0
Garbage collector Name = ‘Copy’, Collections = 41, Time = 3.043 seconds
Garbage collector Name = ‘MarkSweepCompact’, Collections = 3, Time = 1.076 seconds
Current classes loaded 14,941
Total classes loaded 14,971
Total classes unloaded 30
Operating system
Name Linux version 4.14.79-v7+
Architecture arm
Processors 4

syslog doesn’t show anything irregular…

An interesting test might be to close all but one tablet app, and see if your rate of resource consumption is same or slower.

Is there any graphing/charting in your setup?

i’ve already tried this… but not on the fresh system…and i have no data about this try
i will try it again in the evening since i’m not at home currently…
theres no graphing/charting in the setup

24 hours later… looks like that the hint from @matt1 and @mstormi did the trick…
memory usage since changing heap size and reboot yesterday is currently “stable” …
did no other changes since then… the items visibilty state in the android openhab apps
are more responsive also… at least most of the time…

a slight increase of memory usage is noticable… hopefully this will not result in a very slowly dead…
we will see…

what makes me wonder about this whole issue is… never had problems with heap size and memory before… using openhab since 4 or 5 years now… maybe because we moved into our new house and my environment growed over the last 1 1/2 years?

i will also try setting only Xmx as stated by matt1, reboot the server and will report back in about 24 hours :wink:

thanks for patience and support!



Xmx only increases the heap size limit so Java will not crash as fast (it does when heap size reaches that limit). But crashing is not your problem anyway, memory consumption is.
Xms preallocates heap space. The default is fine as long as you don’t run anything else large on the same box and yes you can decrease or omit it, too.
But that can result in delayed rule execution, the setting is there to avoid that.

i see … did also some reading about the java heap size settings…
but since my openhab setup is already a construction site i will try all options/possibilities offered :wink:

again 24 hours later… back again :wink:
currently the ram usage with Xmx512m setting is “stable”…

will then start to add some more bindings again and also reactivate some rules…
lets see what happens then :wink:

have a nice weekend!



1 Like

You appear to have the same symptoms that I had, so I will not be surprised the same fix worked. For me it was an image channel that was causing it and just like it happened for you it was only when a tablet or app was open.

2 weeks later, still the same issue…
did again a lot of tests without success and decided to switch over running
basic ui in fully kiosk browser on the tables.
currently running my full setup since one week without any memory problems (except some button display problem in the dark theme (grey font on black background))
but as soon as i turn on the android openhab app(S) the fun begins.
no or sporadically refreshing of item visibilty and memory is filling up and
openhab crashes about 24 hours later.
in the meantime i don’t have the time and patience for further testing.
so for me the android app is not usable in that way.
maybe the problems are related to this issue.
this is the only info i got from the maintainer of the app in this post.
is there a chance for further investigation of this issue on development side?



It is an openHAB core problem unfortunately. The android app uses the official REST web interface and apparently one of the called endpoints is leaking memory. The android app might just call that very frequently so it happens more likely.

Next to REST it could also be the mDNS library that openHAB uses (which is bad code quality). Everytime a network peer asks for “openhab.local” the mDNS library kicks in and tells the local network about openHABs IP address. Maybe the android app does this quite often.

Someone would indeed need to investigate that sooner or later, otherwise openHAB cannot be deemed as being long-run-time stable anymore.



I assume that should be sooner rather than later.

But that would be you then. There are no free developers at the moment, because of the Eclipse smarthome reintegration and the 50 new bindings pull requests of the last 4 weeks (each > 1000 lines).

I can´t… I havn´t got the knowlegde.

I understand things are highly complicated atm with alot of stuff to do. But what worry me is, if ie. bindings has higher priority than this kind of problem?

A binding developer is a potential new core contributor and openhab is in need of more core developers ^^.