New app install CPU share : change default
-
@robi okay, but here are some more questions/concerns.
-
what happens when an app reaches the limit (say 20%)? Does it throttle speeds or crash like when an app runs OOM?
-
we have “recommended/minimum” RAM figures to use for each app, but no info on CPU usage. If the staff assign a global default, then some apps might need more cpu shares. In this case, how do I figure out what’s the lowest number of shares we should set to run the app reliably?
-
how would this work if it’s percentage based since each VPS has different resources? 10% might work fine on one VPS but crash on another ($5 droplet).
-
-
@robi okay, but here are some more questions/concerns.
-
what happens when an app reaches the limit (say 20%)? Does it throttle speeds or crash like when an app runs OOM?
-
we have “recommended/minimum” RAM figures to use for each app, but no info on CPU usage. If the staff assign a global default, then some apps might need more cpu shares. In this case, how do I figure out what’s the lowest number of shares we should set to run the app reliably?
-
how would this work if it’s percentage based since each VPS has different resources? 10% might work fine on one VPS but crash on another ($5 droplet).
@humptydumpty said in New app install CPU share : change default:
@robi okay, but here are some more questions/concerns.
- what happens when an app reaches the limit (say 20%)? Does it throttle speeds or crash like when an app runs OOM?
No, it just slows down.
- we have “recommended/minimum” RAM figures to use for each app, but no info on CPU usage. If the staff assign a global default, then some apps might need more cpu shares. In this case, how do I figure out what’s the lowest number of shares we should set to run the app reliably?
There is no need to that. See above.
- how would this work if it’s percentage based since each VPS has different resources? 10% might work fine on one VPS but crash on another ($5 droplet).
Again, it cannot crash from CPU limits. Only RAM and how the app handles running out of memory.
CPUs are shared in time, up to % of overall CPU(s).
RAM is not shared, but used in chunks up to an individual and then overall physical limit.
-
-
@humptydumpty said in New app install CPU share : change default:
@robi okay, but here are some more questions/concerns.
- what happens when an app reaches the limit (say 20%)? Does it throttle speeds or crash like when an app runs OOM?
No, it just slows down.
- we have “recommended/minimum” RAM figures to use for each app, but no info on CPU usage. If the staff assign a global default, then some apps might need more cpu shares. In this case, how do I figure out what’s the lowest number of shares we should set to run the app reliably?
There is no need to that. See above.
- how would this work if it’s percentage based since each VPS has different resources? 10% might work fine on one VPS but crash on another ($5 droplet).
Again, it cannot crash from CPU limits. Only RAM and how the app handles running out of memory.
CPUs are shared in time, up to % of overall CPU(s).
RAM is not shared, but used in chunks up to an individual and then overall physical limit.
-
@robi thanks for the explanation!
@humptydumpty You're welcome.
Don't be afraid to test it by setting the CPU shares really low and observe what happens.
-
This doesn't actually allocate CPU the way you think. As @robi pointed out, it allocates cpu shares - how much to allocate to which app when resources are short. By default, app sees all the CPU
I will refer https://docs.docker.com/config/containers/resource_constraints/#cpu :
Set this flag to a value greater or less than the default of 1024 to increase or reduce the container's weight, and give it access to a greater or lesser proportion of the host machine's CPU cycles. **This is only enforced when CPU cycles are constrained.** When plenty of CPU cycles are available, all containers use as much CPU as they need. In that way, this is a soft limit. --cpu-shares doesn't prevent containers from being scheduled in Swarm mode. It prioritizes container CPU resources for the available CPU cycles. It doesn't guarantee or reserve any specific CPU access.In practice, I have found this very hard to "measure". I tried to summarize the above in https://docs.cloudron.io/apps/#cpu-shares (screenshot) but maybe it's not clear enough.
-
No, I think I understand the concept of CPU shares.
I just think it is bizarre / bad practice to set the default to 50%.If the setting has a practical impact when overall system is under load, then why set it high for all apps as a default.
If it doesn't have a practical impact, why bother having it OR why set it at 50% ?Anyway, it doesn't really matter, I guess.
-
No, I think I understand the concept of CPU shares.
I just think it is bizarre / bad practice to set the default to 50%.If the setting has a practical impact when overall system is under load, then why set it high for all apps as a default.
If it doesn't have a practical impact, why bother having it OR why set it at 50% ?Anyway, it doesn't really matter, I guess.
@timconsidine said in New app install CPU share : change default:
I just think it is bizarre / bad practice to set the default to 50%.
Why? have you actually hit a problem of some some sort that requires a solution?
@timconsidine said in New app install CPU share : change default:
If it doesn't have a practical impact, why bother having it
Fair question, i guess.
@timconsidine said in New app install CPU share : change default:
Anyway, it doesn't really matter, I guess.
My thoughts exactly.
I think the only time I've ever adjusted mine has been to give Nextcloud even more than 50% (I've given it 75%) in the hope it might help speed it up.
Oh, and on one of my PeerTube instance too (a transcoding videos seems to one of the few things I do on my server that actually eats up a fair bit of CPU).
@humptydumpty said in New app install CPU share : change default:
The graph shows usage/spikes over 100% sometimes which doesn’t make sense at all
That's when there are multiple CPUs (which there normally are). My server seemingly has 12 CPUs as my graph goes up to 1200% (but in the last 30 days it's never actually gone above 225%)
-
This doesn't actually allocate CPU the way you think. As @robi pointed out, it allocates cpu shares - how much to allocate to which app when resources are short. By default, app sees all the CPU
I will refer https://docs.docker.com/config/containers/resource_constraints/#cpu :
Set this flag to a value greater or less than the default of 1024 to increase or reduce the container's weight, and give it access to a greater or lesser proportion of the host machine's CPU cycles. **This is only enforced when CPU cycles are constrained.** When plenty of CPU cycles are available, all containers use as much CPU as they need. In that way, this is a soft limit. --cpu-shares doesn't prevent containers from being scheduled in Swarm mode. It prioritizes container CPU resources for the available CPU cycles. It doesn't guarantee or reserve any specific CPU access.In practice, I have found this very hard to "measure". I tried to summarize the above in https://docs.cloudron.io/apps/#cpu-shares (screenshot) but maybe it's not clear enough.
@girish said in New app install CPU share : change default:
I tried to summarize the above in https://docs.cloudron.io/apps/#cpu-shares (screenshot) but maybe it's not clear enough.
You've written there:
The CPU share setting is a percentage relative to each app
Does that mean that if one leaves all the apps on 50% the setting is basically doing nothing? But that any more/ less than 50% would give relatively more/ less CPU time to that app?
-
@girish said in New app install CPU share : change default:
I tried to summarize the above in https://docs.cloudron.io/apps/#cpu-shares (screenshot) but maybe it's not clear enough.
You've written there:
The CPU share setting is a percentage relative to each app
Does that mean that if one leaves all the apps on 50% the setting is basically doing nothing? But that any more/ less than 50% would give relatively more/ less CPU time to that app?
