Cloudron Forum

I'm with @nebulon, I see this as difficult to support, harder to code for - and more user friction. I usually never support more user friction unless it's dire. I think configuring after installation is more than acceptable. It's not like we can't write scripts using their API to macro your suggestion too, but I digress.

@d19dotca You can try https://git.cloudron.io/cloudron/box/-/commit/3c565defca000feb21c47e9d8c9ada4c62c11cef and then systemctl restart box. Alternately, you just use the docker CLI until the next release: usr/bin/docker update --memory 805306368 --memory-swap 1610612736 mail The containers are named mysql, postgresql, mail, mongodb.

Correct. We don't need to re-create container to change the memory limit. But we still need to restart it after adjusting memory limit because of the limitations in our packaging. I think over time we have learnt that it is not a good idea to setup apache to auto-scale based on container memory limit. Those things are very dependent on the app/plugin use. I think java apps require a restart at this point since the JVM gets passed in the heap memory as a flag on startup, maybe there is a workaround for this as well, have to investigate. But at that point, we can atleast make the memory limit code not re-create container which I think is where bulk of the slowness is.

@nebulon Thanks for your reply. After thinking about it, the graph chosen is better to view memory usage (which fluctuate much more than disk). I would then suggest separating both information: keep the current graph for the app usage (the Y axis adapting to the app using the most memory) add a bar for total memory used, modelled on the total disk usage (could be a single colour for memory usage) [image: total disk usage] This would help maximize the amount of information you can visualize in one go and help detect spikes better.

FYI - related discussion: https://forum.cloudron.io/topic/5960/setting-memory_limit-dynamically-in-wordpress-developer-package

Usually, "Killed" means it ran out of memory when importing. Can you try to restore again and see "dmesg -w" output in parallel to see if that is indeed the case? You can bump the memory limit for the restore logic as indicate here - https://cloudron.io/documentation/troubleshooting/#backups

@necrevistonnezr indeed, previous versions of Cloudron would allocate more memory for redis based on the app's memory limit. This limit was not settable by the user. In 5.2, we have made the redis limits visible and configurable by the user. Our 5.2 migration script should ideally could have been smarter and allocated more memory to redis.

@YurkshireLad The memory recommendation is the absolute minimum memory below which the app won't run reliably. Like even with 1 user, it won't run properly below that recommendation. The amount of memory required to host 100 users... is hard to know. Usually, the answer to this depends on the how all these users user Rocket.Chat. If they use simultaneously and if they use it from multiple devices etc. Cloudron will give you a notification (email) if an app is running out of memory. So, you can just take it slow and increase the app's memory limit as you go. You can also look into the upstream project's memory recommendation for 100 users.

I manually installed Mastadon on a Digital Ocean 1Gb droplet (unrelated to Cloudron), and with only 1 user and 5 posts, it ran out of memory. I bumped the droplet up to the 2Gb option and it ran smoothly.

@masonbee The memory limit setting is the "maximum memory" before which the app is killed for over use. It is not "reserved memory" i.e it's not pre-allocated to the app and thus cannot be used by any other app. The "maximum memory" simply ensures that a single web app cannot bring down the whole system.

@nebulon It's a good start!

Here we go : https://docs.cloudron.io/apps/#low-resource-warning

Would be great if you could update this thread with your findings. Also please note that the memory settings for the addons are currently not preserved across app restores or even server reboots. We are working on this fix and you can see the status of it at https://git.cloudron.io/cloudron/box/issues/566