[BUG] Dashy v2.1.2 consuming all assigned resources after changing config (either via GUI or direct conf.yml change) #1500
Assignees
Labels
🐛 Bug
[ISSUE] Ticket describing something that isn't working
Comments
|
Noticing similar behaviour, today my container also entered a crashloop with the same js out of memory error like last time, however rebuilding and redeploying solved it temporarly. |
|
Same here. After a config change, the CPU spikes and dashy no longer works. Restarting the container does not bring dashy back. Only a delete and rebuild brings dashy back online. This is right after a rebuild, I entered edit mode and hit save to disk. No changes. Dashy seems to crash. |
liss-bot
added
👤 Awaiting Maintainer Response
|
Having the same issue running on AWS ECS. Currently having to assign 1 vCPU & 2GB memory for it to successfully build using my config. Was running on 0.25 vCPU & 0.5GB memory previously. Navigating to the dashy webpage just shows - Checking the logs shows the below - |
liss-bot
added
the
👤 Awaiting Maintainer Response
|
I reverted to 2.1.1 for the time being where this is not an issue. |
liss-bot
removed
the
👤 Awaiting Maintainer Response
|
So did some testing, noticed dashy uses like 1.5GB to rebuild, when having unlimited ram(to 4GB) however then it's still not rebuilding correctly, it still exits with js heap allocation error. But that could also be due to the raspberry pis memory management with docker in between. |
|
@CrustyB @charliegrahammm @CTHRU For me it seems fixed now |
|
@CrazyWolf13 saw your message and gave build from source a try. Unfortunately I'm not proficient in Node and Vue and I stumbled from missing dependency issues into directory rename issues trying to get Dashy built, before I could create a suitable docker image to be able to test. Hope someone else can help out with testing. |
liss-bot
added
the
👤 Awaiting Maintainer Response
|
@CTHRU Sure no problem, that was more meant if one is already running on build from source without docker. In the meanwhile the docker image was updated, so you can just recreate the container and repull the :latest tag of the dashy image. Lmk if that fixes your issue. |
|
@CrazyWolf13 I tried and pulled the latest docker image. It took about 10 minutes for Dashy to become available, using 6 cores (50%) of the CPU. Max memory usage was about 1.4 GB. I don't know if that is expected behavior. When I open the website during those first ten minutes, I get 'Possible error, check logs' message while it is busy. In attachment are the stats of Docker Desktop. [EDIT] This is the log file Just wanted to give you this feedback. |
liss-bot
removed
the
👤 Awaiting Maintainer Response
|
With 0.25vCPU & 0.5GB RAM (as I was previously using), I get the below in the logs: When giving it 1vCPU & 2GB RAM, the log looks like this: The app starts successfully at this point. This is just starting the container without a custom config file applied. During this build process it eats all available CPU and memory. |
liss-bot
added
the
👤 Awaiting Maintainer Response
|
For me it used just very slightly more than 500MB depending on the size of the assets and config. Also depending on the Hardware, dashy used a lot cpu, but that is what I expect for a rebuild. So in general the errors may not even appear anymore, but the 0.25cpu and 0.5gm ram is just too lest. As minimum dashy needs 1GB Ram. |
liss-bot
removed
the
👤 Awaiting Maintainer Response
|
Yeah, as @CrazyWolf13 said, the Node base image does require a bit more RAM, first build especially |
|
As a pre-emptive action, I increased my docker instance from 2G to 4G of memory and increased the core count from 2 to 4. I see from my logs that my docker container has been running 1.73G of used memory until now, I upped the ram to 4G and loaded dashy and usage went to 1.81G. Once I saved the config, dashy instantly spiked to 4G of usage and crashed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Environment
Self-Hosted (Docker)
System
raspberry pi os lite - 6.1.0-rpi8-rpi-v8 #1 SMP PREEMPT Debian 1:6.1.73-1+rpt1 (2024-01-25) aarch64 GNU/Linux
Version
2.1.2
Describe the problem
I'm still experiencing a similar issue to #1494 , but now it happens when dashy is active.
I started from the default config:
conf.ymlfile directly (adding 1 section + 1 item).Save to Diskfrom GUI.It appears that in both cases the symptoms are very similar to issue #1494 (due to repeating rebuild? But this time not at startup time but when the changes are applied while the app is running).
Observations:
the docker container consumes all assigned CPU resources (in my case 50% op cpu)
physical memory and swap memory are slowly filled until the system falls out of memory / the memory limit of the container is reached ( example below taken before the system would become unresponsive, but it will go up till 256 and filling swap memory too).
When the container is started the first time with the default conf.yml file, everything is fine and max memory usage does not exceed 150 MB.
As soon as any change is applied while running, the above behavior is noticed.
Keeping the config changes and bringing the docker container down and up as follows, solves the issue. The application seems to be correctly updated upon restart and then idles on cpu with about 150 MB RAM usage.
This is also my current workaround to prevent the issue each time I apply a configuration change.
my
compose.yamlfile (fyi, i copied the/app/publicfolder contents of the source code to the mounted dir on the host)Additional info
No response
Please tick the boxes
The text was updated successfully, but these errors were encountered: