[network] (Docker) Still massively slowing down boon when extended default-adress-pools are used in /etc/docker/daemon.json about openhab-addons HOT 14 OPEN

You can limit the interfaces to use in the Advanced settings of your Thing:

from openhab-addons.

Currently i deinstalled the Network binding and i am sending my magic packets via node-red

Can you just give me a very quick description/link on what to try? I tired to follow your link and look at the PR but not sure how i should try it.

Is it

1. Re-install network binding
2. Limit IP-Ranges in network binding settings
3. Try

I would love to be able to set a network address range

1. Your subnets are huge. The /12 has 1 million addresses I can’t think of why you want it that large in a private setting. /24 or /22 is usually enough.
   The second one is also huge /16. I would expect more issues sooner or later that have nothing todo with openHAB.
2. the added configuration option is documented. You can set/limit the interfaces in the thing configuration, it depends where if you use UI or file based config.

from openhab-addons.

Did you limit the network interfaces on your ping devices? This config option was added in #16145.

from openhab-addons.

Currently i deinstalled the Network binding and i am sending my magic packets via node-red

Can you just give me a very quick description/link on what to try?
I tired to follow your link and look at the PR but not sure how i should try it.

Is it

1. Re-install network binding
2. Limit IP-Ranges in network binding settings
3. Try

I would love to be able to set a network address range

from openhab-addons.

Understood
I will test it and give feedback
Thanks for caring

from openhab-addons.

Thanks for your input
I will also check reducing my subsets

from openhab-addons.

Setting interface for network devices seems to solve the "openhab things freezing" problem

I still see a high cpu load on openhab on my server
This may be due to the fact that @lsiepel describes

Hoping this is not too off topic:

• In not an expert in network addresses
• Long time ago i think i also used this to get an idea of what is happening: https://straz.to/2021-09-08-docker-address-pools/
• This means, that the following config should be the docker-standard, which i only extended with the 10.99.0.0/16 addresses

{
  "default-address-pools" : [
    {
      "base" : "172.17.0.0/12",
      "size" : 16
    },
    {
      "base" : "192.168.0.0/16",
      "size" : 20
    }
  ]
}

My problem was, that there are only 31 networks allowed in this config
I am running more than 31 thats why i need to extend this configuration

As a reminder, currently im running

{
  "default-address-pools": [
        {
            "base":"172.17.0.0/12",
            "size":16
        },
	{
            "base":"192.168.0.0/16",
            "size":20
        },
	{
            "base":"10.99.0.0/16",
            "size":24
        }
    ]
}

Do you have any good suggestions using the default-config as basis and just extending it by something like the 10.99.0.0/16 address range?

Sorry for asking questions, i feel very unsettled regarding this topic

from openhab-addons.

One more addition
I just tried to monitor my cpu load and during this i deinstalled the network binding again

As you see

• openhab (java) is utilizing my cpu permanent by 12%
• network binding present or not does not change anything

So im guessing im wrongly accusing the network binding for this utilization
I think this issue is closed and i have to check somehow if the CPU load is justifiable or if there is something else i have to dig in

Thank you

from openhab-addons.

Sorry in advance for these many messages.
One last thing i did after deinstalling the network binding was to restart the openHAB docker container

And as you can see, the utilization of OH has drastically fallen

• left side: network biding was deinstalled but not rebooted
• middle: high load during restart of OH
• right side: utilization with no changes made, only restarted

So im back on the status of my reply above: #16810 (comment)

from openhab-addons.

Maybe your tool can show the CPU usage per thread similar to top -H ?
The threads have a name so those can help to identify what is consuming your CPU cycles.

from openhab-addons.

I have the same issue with the final release of OH 4.2 running in a Docker container using host network. There is still a huge delay at start-up for the configured pingdevice things to show up. Sometimes up to an hour to get the related things up. The same happens if I try to add a new pingedevice thing. First, the add new thing page takes a very long time to be displayed. Once added, it takes a while before it is shows up as well and when it's available, it takes a while to get the thing properties to show up.

I did everything listed above to limit the network discovery scope without any success. I decreased the Docker default address pools size to 24. I also selected the network interfaces to use for each of my configured pingdevice things. The only difference is that the CPU is pretty much idling when the delay is happening. Looking at trace logs for the binding, not much is happening during that time as well. Each delay seems to be related to some kind of timeout that isn't logged. One last thing to point out is after the initial delay for the pingdevice thing to become available, its status seems to be updated as expected. So it is mostly an initialization/configuration issue.

I also ran a simple test using a new Docker container using host network and only installing the network binding. I experienced no issue up to OH 4.1.0 while I did from OH 4.1.1 and above. When I ran the container on its own network, the issue no longer happens. For reference, I have 33 network interfaces on my Docker host.

from openhab-addons.

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/network-binding-things-are-slow-to-start-and-slow-to-load-in-the-settings-ui/157001/8

from openhab-addons.

Sorry for taking my time. Very busy and wanted to observe this for a few days.

I have no idea why this probem is so hard do chase but since setting the Interfaces to only my network interface it seems that the load is ok, ping devices are working and opening the thing-settings is .... at least ok

I want to highlight again at this point that i have a very powerful homeserver --> Evern running this machine i can still feel a lag in opening the pingdevices

So i can understand the example of @jsetton especially if you are running a lower-powered machine

Running:

runtimeInfo:
  version: 4.2.0
  buildString: Release Build
locale: de-DE
systemInfo:
  configFolder: /openhab/conf
  userdataFolder: /openhab/userdata
  logFolder: /openhab/userdata/logs
  javaVersion: 17.0.11
  javaVendor: Debian
  osName: Linux
  osVersion: 6.8.5-301.fc40.x86_64
  osArchitecture: amd64
  availableProcessors: 16
  freeMemory: 639302192
  totalMemory: 1593835520
  uptime: 196953
  startLevel: 100
addons:
  - binding-astro
  - binding-chromecast
  - binding-fronius
  - binding-http
  - binding-ipcamera
  - binding-lgwebos
  - binding-luxtronikheatpump
  - binding-mqtt
  - binding-network
  - binding-ntp
  - binding-openweathermap
  - binding-shelly
  - binding-somfytahoma
  - binding-telegram
  - binding-wifiled
  - binding-wled
  - misc-metrics
  - misc-openhabcloud
  - persistence-influxdb
  - transformation-jsonpath
  - ui-habot
clientInfo:
  device:
    ios: false
    android: false
    androidChrome: false
    desktop: true
    iphone: false
    ipod: false
    ipad: false
    edge: false
    ie: false
    firefox: true
    macos: false
    windows: false
    cordova: false
    phonegap: false
    electron: false
    nwjs: false
    webView: false
    webview: false
    standalone: false
    pixelRatio: 1
    prefersColorScheme: dark
  isSecureContext: false
  locationbarVisible: true
  menubarVisible: true
  navigator:
    cookieEnabled: true
    deviceMemory: N/A
    hardwareConcurrency: 12
    language: en-US
    languages:
      - en-US
      - en
    onLine: true
    platform: Linux x86_64
  screen:
    width: 3440
    height: 1440
    colorDepth: 24
  support:
    touch: false
    pointerEvents: true
    observer: true
    passiveListener: true
    gestures: false
    intersectionObserver: true
  themeOptions:
    dark: dark
    filled: true
    pageTransitionAnimation: default
    bars: light
    homeNavbar: default
    homeBackground: default
    expandableCardAnimation: default
    blocklyRenderer: null
  userAgent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
timestamp: 2024-07-17T19:36:13.502Z

from openhab-addons.

So i can understand the example of @jsetton especially if you are running a lower-powered machine

I don't think this is related to a resource issue since there is a clear difference in behavior in the same environment between OH versions. Something changed between OH 4.1.0 and 4.1.1. Also, it may not be solely related to running OH in a Docker container as per the forum post linked above.

The network binding had a patch applied in 4.1.1 related to network interfaces filtering parameter but looking at the code, I can't see what could cause that delay issue. The only reason I can see is some library update from upstream. Hopefully @wborn would have a better insight on this.

from openhab-addons.