[QUESTION] Dashy 1.5.6 consumes more RAM #136
Comments
|
Oh, that doesn't look good. This seems to be a Node.js error, and possibly caused my a memory leak in the version used, I've seen something similar in a previous project a while back. I will take a proper look this evening, and try and get it sorted asap. Thanks for raising it :) Which tag are you using, is it the normal amd |
Lissy93
added
‼️ High Priority
|
Hello,
Yes. My compose which no works: If I increase mem_limit, Dashy works: |
|
Thanks, so I've had a quick look, and compared the latest image with version 1.5.0 from last week. For me they look pretty similar
But I will look into this futher this evening, because if you container is needing a GB of RAM, that is an issue. |
Lissy93
added
❕ Medium Priority
|
Once built, the RAM consumption between 1.5.0 and 1.5.6 is similar yes,around 250M On the other hand, for build, 1.5.6 requires more RAM than 1.5.0 My test:
Logs Dashy 1.5.6 with limit 1024M RAM : |
|
Ah thanks for explaining, it makes sense that the build process uses more memory, but I can't think why this has gone up so much in the most recent version, I will have to go through it this evening and see what I can find. |
|
Thank you for your responsiveness as always. Sorry for the explanations, I'm trying to put as much information as possible (logs, ..), because I don't speak English, so I use google translate to help me build my sentences. |
|
On my side, no abnormal memory usage, considering I'm using the healthchecks feature which eventually increases the ram consumption (peaks are happening when watchtower upgrades all my images, at 5am) : |
Yes, I'm only talking about RAM consumption when the container was created. |
|
So I've looked into this, and I'm still not 100% sure what could have caused it, and I haven't been able to recreate it. I've created a PR (#147) to set the base image to a fixed version of alpine node I think that the build process would be a lot more performant if I had used something else other than Node.js. In the future, I would like to rewrite the server part in Go Lang, which should be more light-weight, so hopefully consume less memory. That would be a big job though, so won't happen right away. |
|
I will keep an eye on this, and reopen the issue again if this keeps happening |
|
Thank you for your explanation ! Indeed, an update of lts-alpine is quite possible, I had not thought of this at all! Thanks again for your involvement! Rewriting in another language must indeed be a long job! |
|
Hello, |
|
I'll revert the change back to the original Dockerfile, and push the multi-architecture image under a separate tag. |
|
So I've reverted to the previous Dockerfile, and will merge soon, and hopefully this will fix your issue :) I'm still not sure exactly what is causing it, as on GHCR the build never uses more than 512mb of memory. I did notice that Docker copies all assets into memory during the build, so maybe if you are using your own icons, and if they are large this might possibly have an impact? |
|
I haven't forgotten about this, the latest PR (#168) halves the size of the Docker container, and I am still looking for further ways to improve it further. How is the memory consumption going, still having issues? |
|
Hello, Before, with 750M of RAM the container could not build this. The image also reduced in size from 943.9 MB to 746.5 MB |
|
Met the same issue on Raspberry Pi with the latest image. Any solutions? |
|
I just had my Linode server crash and I had to do an out-of-band reset via Lish console. I slowly brought up my containers and it looks like it was an issue with dashy during the initial setup build. It's a 1 CPU/1 GB Linode so sounds like it may be insufficient to run dashy? If so is there a way to detect this at start so there's not the cpu lockup? The process in question was When I brought the server back up I restarted containers one by one - when I got to Dashy I saw it doing the initial start phase then said it was taking too long then it crashed. Log file and btop screenshot below in case helpful!
|
|
@EDIflyer EDIflyer the same happend to me. I was using an AWS instance, and it broke everything. 1GB and 1vCPU. It's too resource intensive! |
|
My observation: I am experiencing 1GB memory usage during first 4 minutes after dashy docker start. By using top in the console, the offender seems to be: Then, it's normalized: |
|
Dashy used to work on my docker instance but for some reason seems to lock my system on startup. Docker is running in an lxc in proxmox. The lxc has 2 gigs of ram allocated but only 900 megs free. @Lissy93 Can you reopen this issue or provide some guidance? Thanks! |
|
Hi,
Without limit the graph looks like this: @Lissy93 Please, have a look at this memory leak. Thanks for Dashy ;) |
|
A little update, memory usage goes up to 1,5G during editing Dashy.
|
Closes Lissy93#136 Signed-off-by: Bjorn Lammers <walkxnl@gmail.com>
Hello,
Since Dashy 1.5.6 it does not start anymore. Indeed, I allocate 756MB of RAM to it. With Dashy 1.5.6 this is no longer sufficient, I have to give it 1024MB.
With my container limited to 1024MB, Dashy 1.5.6 works.
I already find that allocating 756 MB of RAM is already significant. 1024MB, that starts to do a lot, my machine only has 8GB, more now that Dashy is available on ARM, a lot of ARM machine has little RAM.
Where did this high demand for RAM come from when Dashy was launched? Because we can see that once launched, Dashy consumes much less RAM (around 250MB).
Logs with the container limited to 756MB:
The text was updated successfully, but these errors were encountered: