[BUG] Startup on 3.1.0 consumes too much cpu

[twsouthwick]

Environment

Self-Hosted (Docker)

System

Docker version 26.1.1, build 4cf5afa

Version

3.1.0

Describe the problem

After launching the container with switching to 3.1.0, the memory/cpu consumption starts going through the roof. I hadn't put constraints on this container (now I do :)) and it was taking over my VM:

6e8b003b68a1   dashy                       190.58%   739.2MiB / 1GiB       72.19%    8.11kB / 1.68kB   897kB / 24.6kB    212

it will cycle through very quickly to take all the available memory/cpu.

Additional info

No response

Please tick the boxes

• [X] You have explained the issue clearly, and included all relevant info
• [X] You are using a supported version of Dashy
• [X] You've checked that this issue hasn't already been raised
• [X] You've checked the docs and troubleshooting guide
• [X] You agree to the code of conduct

[CrazyWolf13]

Hi I can't seem to reproduce your issue, neither lissy I guess.

Could you share a bit more? RAM usage on dashy container available ram, cpu usage.

Does it ever go down, or just the first build?

[DerLokich]

Same thing. Updated today and RAM & CPU overloaded

[CrazyWolf13]

Same thing. Updated today and RAM & CPU overloaded

Could you provide more details?

Does dashy always consume such high amouts, just at start? Can you share like some more info about ram and cpu usage of the container? This can be viewed the easiest with portainer.

[DerLokich]

Same thing. Updated today and RAM & CPU overloaded

Could you provide more details?

Does dashy always consume such high amouts, just at start? Can you share like some more info about ram and cpu usage of the container? This can be viewed the easiest with portainer.

I just make repull to update dashy and right after start i see 4 processes "vue-cli-service build", that consume all avaible memory and CPU, so other containers were not avaible. Even console works with huge lags... Only hard reset helps and right after rebbot need to quick stop dashy

[CrazyWolf13]

Please be more specific.

Does the usage go down after some time, like 5 min at max?

How much RAM exactly? How much have you assigned?

The first build of dashy takes a bit more ressources, but there aren't any more rebuilds neccessary later on.

[DerLokich]

Please be more specific.

Does the usage go down after some time, like 5 min at max?

How much RAM exactly? How much have you assigned?

The first build of dashy takes a bit more ressources, but there aren't any more rebuilds neccessary later on.

I've waited about 30 mins, but as other contaniers doesn't working, i do hard reset. Host 2 Gb RAM, 2 vCPU, all avaible for dashy.

[CrazyWolf13]

@DerLokich

Just for testing, could you extend it to 3GB RAM ?

And would you mind sending a screenshot of the ressource usage from container start to like 10minutes? After freshly pulling the image?

This can be done with portainer:

docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest

Thanks!

[CrazyWolf13]

To @twsouthwick

1GB is a bit less for dashy, could you try with 2GB? Dashy uses quite a big amount of ressources for the first build, but since V3, there are no more rebuilds neccessary on config changes.

While I got it to work with a raspberrypi which only has 1GB of RAM, memory management is different compared to like a VM or a big server running dashy.

[DerLokich]

@DerLokich

Just for testing, could you extend it to 3GB RAM ?

And would you mind sending a screenshot of the ressource usage from container start to like 10minutes? After freshly pulling the image?

This can be done with portainer:

docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer-ce:latest

Thanks!

Can't extend, it's VPS in another country :).

Just for testing i tried to take screenshot in portainer, but VM stuck after eating all resources... Only last output of htop avaible now:

[DerLokich]

Waited till now, so it's about 90 min, no effect. Hard reset VM.

[twsouthwick]

I've updated it to 3gb, and even with the resource constraints, my VM becomes unresponsive:

services:
  dashy:
    container_name: 'dashy'
    image: lissy93/dashy:3.1.0
    restart: no #unless-stopped
    deploy:
      resources:
        limits:
          cpus: '2'
          memory: 3gb

I'll try to gather some more details this weekendn

[twsouthwick]

Out of curiosity, what is the value of rebuilding the dashboard in the container? Why not just ship a prebuilt component with the container? I think historically dashy needed the config as part of the build, but now it doesn't need it, right? It makes the dashboard a fairly heavyweight system as it is.

[CrazyWolf13]

Out of curiosity, what is the value of rebuilding the dashboard in the container?

I think currently it needs to rebuild for other things like for example auth needs a rebuild, custom css, added files like icons, defaultView change and some other very specific things.

So in general file changes or additions not related to conf.yml still require a rebuild.

@Lissy93 Please correct me if I'm wrong.

[CrazyWolf13]

I'll try to gather some more details this weekendn

Thanks, that'd be awesome!

Because I really cannot reproduce this here and I think lissy has also never been able to reproduce this issue.

[bobodevil]

I've had the same issue as well. I thought it was my issue, so I rebuilt the container, but it just chewed up the CPU and memory again.

Edit: I had my watchtower auto update. I just read about the 3.0+ update. changing -p 8080:8080 and /app/user-data/conf.yml fixed my issue.

[Lissy93]

I'll look into this, as somethings definatley not right here, while Node (used for build) is a bit heavy, it shouldn't ever be consuming that amount of resources.

So far, haven't been able to reproduce.

@DerLokich - it looks like build is being run multiple times, which is weird because it is only needed once.

[twsouthwick]

Looks like memory consumption isn't the issue - but it spikes to 20cpus and then the system sends a kill as it's taken all the cpus of the machine.

And the system sends a kill:

 WARN  A new version of sass-loader is available. Please upgrade for best experience.
error Command failed with signal "SIGKILL".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
node:events:496
      throw er; // Unhandled 'error' event
      ^

Error: write EPIPE
    at target._send (node:internal/child_process:879:20)
    at target.send (node:internal/child_process:752:19)
    at callback (/app/node_modules/worker-farm/lib/child/index.js:32:17)
    at module.exports (/app/node_modules/terser-webpack-plugin/dist/worker.js:13:5)
    at handle (/app/node_modules/worker-farm/lib/child/index.js:44:8)
    at process.<anonymous> (/app/node_modules/worker-farm/lib/child/index.js:55:3)
    at process.emit (node:events:518:28)
    at emit (node:internal/child_process:951:14)
    at process.processTicksAndRejections (node:internal/process/task_queues:83:21)
Emitted 'error' event on process instance at:
    at node:internal/child_process:883:39
    at process.processTicksAndRejections (node:internal/process/task_queues:77:11) {
  errno: -32,
  code: 'EPIPE',
  syscall: 'write'
}

Node.js v20.11.1
node:events:496
      throw er; // Unhandled 'error' event
      ^

Error: write EPIPE
    at target._send (node:internal/child_process:879:20)
    at target.send (node:internal/child_process:752:19)
    at callback (/app/node_modules/worker-farm/lib/child/index.js:32:17)
    at module.exports (/app/node_modules/terser-webpack-plugin/dist/worker.js:13:5)
    at handle (/app/node_modules/worker-farm/lib/child/index.js:44:8)
    at process.<anonymous> (/app/node_modules/worker-farm/lib/child/index.js:55:3)
    at process.emit (node:events:518:28)
    at emit (node:internal/child_process:951:14)
    at process.processTicksAndRejections (node:internal/process/task_queues:83:21)
Emitted 'error' event on process instance at:
    at node:internal/child_process:883:39
    at process.processTicksAndRejections (node:internal/process/task_queues:77:11) {
  errno: -32,
  code: 'EPIPE',
  syscall: 'write'
}

[kzkvv]

I see logs and it looks like Dashy is building in docker while startup. It looks strange. It consumes almost all my VPS resources (I have a small VPS with 2 CPU and 2GB RAM. It also takes a lot of time, I've been waiting about 5 minutes and Dashy still doesn't start :( Maybe I missunderstand the main idea, but I think any application should be built once, packaged once into docker-image. Once, not N-times during each (or first) startup. Or are there some technical reasons to perform build during container startup?

There is a part of my docker-compose with Dashy:

  dashy:
    image: lissy93/dashy
    container_name: dashy
    ports:
      - "4000:8080"
    # Set any environmental variables
    environment:
      - NODE_ENV=production
    # Specify your user ID and group ID. You can find this by running `id -u` and `id -g`
      - UID=1000
      - GID=1000
    restart: unless-stopped
    healthcheck:
      test: ['CMD', 'node', '/app/services/healthcheck']
      interval: 1m30s
      timeout: 10s
      retries: 3
      start_period: 40s

[DerLokich]

Guys, any news about this issue? :)

[sutr90]

I have the same behavior. The app rebuilds on every update of the compose file:

Using Dashy V-3.1.1. Update Check Complete

✅ Dashy is Up-to-Date

-  Building for production...

 WARN  A new version of sass-loader is available. Please upgrade for best experience.

 DONE  Compiled successfully in 47128ms9:22:12 AM

[dacagi]

I'm also kind of having this issue. I'm running v3.1.1 with Docker on a Raspberry 4, with 4GB of RAM. I am able to run one instance, CPU and RAM usage almost tops but it stabilizes after a couple of minutes. If I try to spin up a second container, the host freezes and I have to cut the power.

Prior to v3 I was able to run 3 instances at the same time whilst I was doing some tests. I wasn't usually letting them rebuild at the same time, the system froze, but it ended up working if I had patience enough. I mean I usually started them sequentially to avoid the total lack of response so I could keep working, but if I wanted to I could start all 3 go for a coffee and come back.

This is to say that I do notice a big change in behavior. Earlier I believe every rebuild took about 1GB RAM and around 40% CPU, so running two was fine, the third one was already pushing the limits. Now CPU is usually above 50% during build, with peaks over 90. And RAM usage went from 1,4 to 2,8GB peaking at 3,3GB.

I don't really see this as an issue with the app but probably with some framework. You were one of the reasons I started learning Vue and after my tiny personal project grew a bit I'm also seeing how the performance of the build process tanks. I love this project so I'm happy to help. Let me know if I can provide any specific details or logs.