Cloudron and Swap File Use
-
My server has a lot of RAM and I would prefer to leverage that rather than disk (swap). So I reduced the "swappiness" factor from 60 (Ubuntu default) to 10 expecting to reduceswapping. I can see that the server is using that value. That being said, it doesn't look like Cloudron honors swappiness. How can I fix this?
It also looks like the standard /swapfile was not being used (so I removed it), but Cloudron uses /apps.swap.
If it can't be "fixed", do I need to increase the size of my swapfile? (When I increased /apps.swap from 4GB swap to 8GB, it looks like Cloudron sucked up the extra swap.) What is the right value for max performance (assuming I have extra disk space to spare) as I add more apps?
-
Are you seeing any performance issues you are trying to fix? Usually tweaking swap behavior on linux is only useful for dedicated very well known use-case and even then the kernel might do as it likes in the end, broadly speaking.
Cloudron adds some swap space to avoid cases where otherwise the system as a whole might become unstable. Just having free swap does not even always prevent out-of-memory cases on linux and the kernel might still kill processes, regardless of free swap.
Given that Cloudron is such a generic system with various different technologies with their own memory management on top of all that (think of javascript or ruby engines), I would not spend any time trying to optimize this, usually it becomes worse.
Also note that even if swap space is used, this does not necessarily mean those memory pages are already removed from RAM, it may just that the system has some idle times and thinks offloads some rarely used memory pages i advance, even if that might never be required in the end.
That being said if you say have to pay for disk I/O then this might be a reason to reduce swappiness, though also that is a bit of a hint mostly.
-
@nebulon At times I see that the Cloudron is not responsive (browser timeouts, which could be something other than a busy Cloudron server). I am also having an issue when using external monitors to check the health of my Cloudron (Uptime Robot, BetterStack). Attempts to use the API health check to return Cloudron version sometimes fails (causing Uptime or BetterStack to issue an alert). The same problem happens using the appid API call to check my Kuma instance. Again, I am not sure why this is happening or if it relates to the swapfile and performance. The GET failures are intermittent, but frequent enough to cause me to disable these alerts.
Given the CPU/RAM/Disk of this server, I would not expect any of this to be an issue. I am not seeing anything in the box log that might suggest a problem. An article I was reading prompted me to look at the swapfile and utilization. Inside Cloudron, the monitoring chart seems to show a 50/50 split between RAM and swapfile. Ideally, Cloudron would use close to 100% RAM, but if subsystems dictate a 50/50 split, then perhaps I should increase from an 8GB swapfile to something much larger (I have enough disk to accommodate this easily).
Theoretically, suppose I allocate 1GB to /apps.swap? How would that impact Cloudron performance? Would applications crash? Wait for available swapfile RAM? Just trying to figure out how to best allocate extra resources to get better performance.
