Cloudron Forum

Hi @girish sorry for the delay. I think -D does not necessarily impact performance, my test after removing -D was much quicker but after adding it again it was just as quick. Seems like there's some kind of filesystem caching. Maybe at some point I could analyse the differences but I suspect changing this doesn't impact performance so much. The part that does impact performance a lot is the -x flag, but as far as I've seen, that will only prevent iteration on the remote (s3fs) filesystem if du is initiated on the parent dir, e.g. /mnt and not on the mount itself /mnt/s3fs. Would be a lifesaver if you could add this, but understandable if it cannot be done. If it cannot be done, a workaround to exclude certain volumes from disk usage calculation would be fine too. Or maybe you could add an option to the Disk Usage UI: Offer an option to include/exclude certain volumes before actually executing calculation

@girish thanks!

Hi @girish that's understandable, profiling is beyond what Cloudron is meant to do. However it would be useful if the charts would be more accurate. Imagine this usecase: You have an install with 10 apps. Suddenly there's a lot of incoming traffic on one of these apps, slowing the entire machine down. If this happens, at least you'd want to be able to quickly identify the app which should be stopped. Anyways, it's understandable that this doesn't get much priority given the amazing popularity on this thread

(please read warning in above comment before following instructions below). If you want to make config file changes: docker exec -ti mysql /bin/bash Edit /run/mysql/my.cnf as needed supervisorctl restart mysql It is important to note that the changes to config files are not persistent across container restarts and server reboot. In general, we have not envisioned Cloudron as a development environment, but we do have many devs using it as such. So, if there is interest, maybe we need to improve things for such use cases.

Maybe one of these? https://phoenixnap.com/blog/docker-container-monitoring-tools I'll look into Zabbix, thanks for the recommendation

This sounds like it should be a part of the build package and/or the registry package, depending on use case.

@girish it's been solved. I did a docker logout and tried again. Got the error again but this time the error was a bit more detailed. Tried it again and it worked. Thanks!