Cloudron Forum

Thx, I´ve look into that, it looks like the same!

Ah yeah, that's what I thought. Moved the build app to somewhere else. Would be nice to add --cpu-quota to the build command to mirror the apps settings (from https://dev.to/code42cate/dont-build-docker-apps-without-this-flag-48kg)

@ekevu123 Previously, we used something called "CPU Shares" (--cpu-shares in docker) . This option was a bit hard to understand since it comes to picture only when there is CPU contention between various apps (i.e when a server is overloaded to start with). We removed this and replaced it with an easier to explain "CPU Limit" (--cpu-quota in docker). This corresponds to how many cycles your app should be given. Like, you can say, give only 2 cores max to this app (in any situation). By default, apps have access to all your CPUs.

However, isn't the point that the default should be less than that so that one app cannot take down the whole server?

We couldn't think of a good default. Otherwise, apps will start out "crippled" and we thought it's better this way. I think if you have apps that are causing problems, only then should you look into tweaking this. This would be a stop gap measure before you try to report the issue and get the app fixed...

Fixed in https://git.cloudron.io/cloudron/box/-/commit/abf445e96949ab952c07b457610a1a890cf4e339 for next release.

The percentage is 100% times the CPU cores. So presumably you have 4 cores, which is then reflected in the percentage.

That's what I call an answer 🙂
Thank you very much. Very helpful and my question is answered.

@jonslab did you find what it was?

@pauljacobson ah yes, the fix for haraka is coming. I recently submitted a patch upstream for this which has now been merged - https://github.com/haraka/Haraka/pull/3104 .

@d19dotca to be honest, I think can be quite debatable, for example say three apps shape a rough sine curve across the time period, there would not be an easy visual winner. But what is also important here, currently we use what the graph library gives us and reworking this for little value is currently not worth while 🙂

@girish That's not it. You have OOMs because people install all sorts of apps and try to abuse the system, like WP and trying out large plugins.

My system has 0 OOMs. None.

Mine also has enough of IO as I asked them to limit the number of new customers on the host system.

# dd if=/dev/zero of=/tmp/test1.img bs=1G count=1 oflag=dsync ; rm /tmp/test1.img 1+0 records in 1+0 records out 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 5.50861 s, 195 MB/s

Doesn't explain 48GB mem spikes.

This only seems to be happening on 20.04 Cloudrons, not 18.04.

Btw, the main issue I think you're having is the choice of that NY datacenter, it's networking isn't great, they seem to allow burst traffic but then quickly throttle down or experience congestion.

Seattle has been way better for me.

@girish Yes, in fact I did not understand... 😞 To many logs to check with vi

@mehdi Very much interested in this topic. I love my American friends, but the EU certainly isn't without capability to respond to the data-mining free-for-all antics of the last decade. I share occasional posts on Twitter on these subjects if anyone's interested.

@girish now I've this:

alt text