[SOLVED] Determining the reason for a java.lang.OutOfMemoryError

Setup, Configuration and Use Runtime
1

I have recently started getting java.lang.OutOfMemoryError error messages on a previously very stable installation. I am typically getting 12 to 24 hours after the service is restated.

I have tried some troubleshooting based on other forum posts however I feel i am just trying things without really understanding what is causing the problem.

I was originally running a stable version (2.4.0) however I have since upgraded to (2.5.0.M3) as part of my troubleshooting.

I believe the issue likely started after a apt-get dist-upgrade (on the stable openhab repo) Openhab is running on Ubuntu 18.10 (GNU/Linux 4.18.0-25-generic x86_64)

My Java version is

java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)

I have removed the RFXCom binding (last installed) and also the cloud connector add on whilst troubleshooting.

I have used Eclipse Memory Analyzer and its Leak suspect report on the last 4 OutOfMemoryError events with the following results. I suspect more information may be needed, but I am not sure what is useful at this stage.

Report 1
Problem Suspect 1

One instance of "org.eclipse.smarthome.core.internal.events.OSGiEventManager" loaded by "org.eclipse.smarthome.core" occupies 362,995,760 (66.05%) bytes. 

Keywords
org.eclipse.smarthome.core
org.eclipse.smarthome.core.internal.events.OSGiEventManager

Problem Suspect 2

1,073 instances of "sun.nio.ch.EPollArrayWrapper", loaded by "<system class loader>" occupy 70,998,320 (12.92%) bytes. 

Keywords
sun.nio.ch.EPollArrayWrapper

Report 2
Problem Suspect 1

1,069 instances of "sun.nio.ch.EPollArrayWrapper", loaded by "<system class loader>" occupy 70,733,784 (36.93%) bytes. 

Keywords
sun.nio.ch.EPollArrayWrapper

Report 3
Problem Suspect 1

1,071 instances of "sun.nio.ch.EPollArrayWrapper", loaded by "<system class loader>" occupy 70,869,664 (29.83%) bytes. 

Keywords
sun.nio.ch.EPollArrayWrapper

Report 4
Problem Suspect 1

1,073 instances of "sun.nio.ch.EPollArrayWrapper", loaded by "<system class loader>" occupy 70,984,848 (42.29%) bytes. 

Keywords
sun.nio.ch.EPollArrayWrapper

Problem Suspect 2

530 instances of "org.eclipse.jetty.client.AbstractConnectorHttpClientTransport$ClientSelectorManager", loaded by "org.eclipse.jetty.client" occupy 20,921,712 (12.46%) bytes. 

Keywords
org.eclipse.jetty.client.AbstractConnectorHttpClientTransport$ClientSelectorManager
org.eclipse.jetty.client

Is anyone able to provide some guidance on identifying the cause of the issue and how to correct?

Thank you.

2

please list all installed bindings

3

Sure:

Bindings:

  • binding-denon1 - 1.14.0.M3
  • binding-mqtt - 2.5.0.M3
  • binding-network - 2.5.0.M3
  • binding-ntp - 2.5.0.M3
  • binding-openenergymonitor1 - 1.14.0.M3
  • binding-opensprinkler - 2.5.0.M3
  • binding-samsungtv - 2.5.0.M3
  • binding-squeezebox - 2.5.0.M3
  • binding-systeminfo - 2.5.0.M3
  • binding-miio - 2.5.0.M3
  • binding-mihome - 2.5.0.M3

Actions:

  • action-telegram - 1.14.0.M3

Misc:

  • misc-market - 2.5.0.M3
  • misc-gcal1 - 1.14.0.M3

Persistence:

  • persistence-mysql - 1.14.0.M3

Transformations:

  • transformation-javascript - 2.5.0.M3
  • transformation-jsonpath - 2.5.0.M3
  • transformation-map - 2.5.0.M3

Voice:

  • voice-voicerss - 2.5.0.M3
4

What’s the hardware platform? Some ARM based SBCs need tuning

5

I am running:

Ubuntu 18.10 (GNU/Linux 4.18.0-25-generic x86_64)

A standard headless installation 16 gig ram and a 120gig SSD.

Openhab is installed from:

deb JFrog testing main

The server is also running node-red and Mosquitto.

6

Ah, sorry, missed the x86 part

7

No problem, I appreciate the assistance.

8

Are you using the speedtest rule to measure Internet speed? I had to stop using that as it gave the same errors.
They was on a rpi 3b though.

9

No, I have a presence detection rule and a telegram notify, thats all. Both have been running for around a year.

No rule is calling an external services.

10

This ended up being caused by the NEST binding still being active after I had migrated my Nest account to a Google account.

Once the binding was removed everything has remained stable.

1 Like