[BUG] Startup on 3.1.0 consumes too much cpu about dashy HOT 18 OPEN

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.

from dashy.

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.

from dashy.

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.

from dashy.

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?

from dashy.

Same thing. Updated today and RAM & CPU overloaded

from dashy.

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.

from dashy.

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

from dashy.

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.

from dashy.

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.

from dashy.

@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!

from dashy.

@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:

from dashy.

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

from dashy.

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

from dashy.

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.

from dashy.

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.

from dashy.

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.

from dashy.

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'
}

from dashy.

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

from dashy.