Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Degrading responsiveness, runaway memory, and unhandled exceptions #55

Open
John867530nine opened this issue Aug 11, 2022 · 2 comments
Open
Assignees

Comments

@John867530nine
Copy link

Using Windows 10, using container provided here: https://hub.docker.com/r/cedalo/management-center

I have experienced the following over several releases including today's most recent.

The container is configured to run a local mosquitto broker because the container will not run otherwise. It is configured to connect to a remote broker on the internet. Sheets was removed.

version: "3.6"
services:
  mosquitto:
    image: eclipse-mosquitto:2-openssl
    ports:
      - 1883:1883
    networks:
      - cedalo-platform
    volumes:
      - ./mosquitto/config:/mosquitto/config
      - ./mosquitto/data:/mosquitto/data
  management-center:
    image: cedalo/management-center:2
    ports:
      - 8088:8088
    depends_on:
      - mosquitto
    networks:
      - cedalo-platform
    environment:
      CEDALO_MC_BROKER_ID: mosquitto-2.0
      CEDALO_MC_BROKER_NAME: Mosquitto 2.0
      CEDALO_MC_BROKER_URL: REDACTED
      CEDALO_MC_BROKER_USERNAME: REDACTED
      CEDALO_MC_BROKER_PASSWORD: REDACTED
      CEDALO_MC_USERNAME: cedalo
      CEDALO_MC_PASSWORD: mmcisawesome
networks:
  cedalo-platform:
    name: cedalo-platform
    driver: bridge

The basic administrative functions work but the container performance degrades according to the number of clients and ACLs. I have less than 30 clients configured, each with one ACL. The container is stable through the GUI login process. The problems manifest when attempting anything that queries or adjusts the broker security policy.

With low client count, symptoms were an ever increasing amount of interface lag. Eventually the app began complaining about response timeout though I could see data arriving is less than a second in the container terminal. Currently at around 30 configured clients, the container apparently faults, consuming all available physical memory on the docker host. It will occasionally throw an unhandled exception and die. Most times, I have to kill the container or docker to recover.

Suggestions?

@keptt keptt self-assigned this Aug 16, 2022
@keptt
Copy link
Collaborator

keptt commented Aug 16, 2022

The problem you are experiencing is probably due to the topic tree feature. As a solution try pulling a newer version of the management center where you can turn off the topic tree in settings. Management center 2.4.2 and higher supports this

@John867530nine
Copy link
Author

John867530nine commented Aug 22, 2022

That resolved my issue, though a few others came up.

I noticed my image: cedalo/management-center:2 is using the tag 2. This is not being maintained as having the latest 2.x release so my previous updates were not actually updating anything.

Using tag 2.4.6-rc3 I found the container would run but the web-app would fail to start due to not properly handling an undefined theme variable.

Using tag 2.4.5 I found the container would run but the web app did no respect the mqtt broker settings in my .yml file. It would present a login style modal that would fail to connect to my public broker. I never got past it. I didn't find any new instructions around indicating how to bypass with .yml values.

Finally, I just set the tag to 2.4.2 and the thing started up and ran per usual but is far snappier than what I had been running from the 2 tag. The topic tree is off by default. I haven't bothered to see if that setting matters. I think it should not have because my broker data is sparse. I'm going to leave well enough alone.

Thanks for the help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants