A new way to think about limits

[jacob]

Hello, first of all, thanks for the great work! Im using CloudLinux, and i know how LVE works (i think): it limits the cpu by a value. For example, if I set 25% of n cpu, it limit the 25% of the total (n) of cpu. Is that correct? But I think its too static. So, this is my feature request:

Why not set the limit dynamically? I mean, the minimum use of cpu is 25%, but if the CPU is not loaded (no other users using the cpu), LVE assign 100% to the user. If we have 2 users, assing 50% to each user. Now, i don want to open a question about the numbers, i want to speak about a new idea of limits, and its an option of course. If a sysadmin need rigid limits, He can use it.

What do you think? Thank you :-)

[accounts]

> CloudLinux allows to set % of CPU being used relative to total number of CPU cores available on the server. This means that 5% setting on 8 core server will be 40% of single core allocated for LVE. On 4 core server 5% would mean 20% of single core.
> In addition to CPU limits each LVE is limited by number of cores that it can use. The default is set to 1. There is a small overhead related to number of sites * number of cores per site. So, a server with 32 cores and 5,000 sites will have a lot of overhead. Yet, setting just one core per LVE reduces that overhead by 32. In most cases, one core per LVE should be enough.
>
> The number of cores settings takes precedence. For example if you have 25% CPU limit, 1 core per LVE, and 8 core server -- each LVE will be limited by 100/8 =~ 12%, instead of 25% CPU, as at most one core will be used by each LVE (1 core on 8 core server ~= 12% of total CPU capacity)
> So, here is the way this works –
>
> If you have 4 cores available and you assign one core to the LVE, the absolute most this core can consume is 25% (1core x 100) / 4 (total cores) of a single core.
>
> If you have 8 cores available and you assign one core to the LVE, the absolute most this one core can consume is 12.5% (1core x100) / 8 (total cores) of a single core.
>
> However, if you increase the nCPU value to two cores – this now changes. For the examples above these are the changes;
>
> If you have 4 cores available and you assign TWO cores to the LVE, the absolute most each core can consume is 50% (2cores x 100) / 4 (total cores) of each core.
>
> If you have 8 cores available and you assign TWO cores to the LVE, the absolute most each core can consume is 25% (2cores x 100) / 8 (total cores) for each core.
>
> So, the first example demonstrates that the most CPU you can assign to the LVE is either 25% or 12.5% depending on the number of cores available to your system.
>
> Raising the CPU % above the 25% or 12.5% will have no effect – the documentation states explicitly;
>
> Quote:
> The number of cores settings takes precedence

[info]

Thank you, but

> Now, i dont want to open a question about the numbers, i want to speak about a new idea of limits, and its an option of course. If a sysadmin need rigid limits, He can use it.

Why not use 2 core of 2 if anyone is using the server? With 2 user, one core per user if available. I think this can help a lot using all available resources. Do you agree?

[clm]

Hello,

Fr om what I understand CloudLinux will automaticaly give each user his fair share. So in theory if you allow each user the equivilant of 1 CPU and you have 4 users requesting each 1 CPU and only have 2CPUs on that server then each user would get 1/2 a CPU.

CloudLinux is planning to move from 100% = all CPUs to 100% = 1 CPU. CloudLinux 6 is already compatible but as its a big change they are panning it and making sure everything will go well.

I think what could be good would be to have a burstable amount of CPU so you could allow a whole CPU so long as the average usage is below a defined value.

For example, set a maximum average of 1/2 a CPU and allow bursts up to 1CPU. If a user tops 1/2 a CPU avergae he could be lim ited to 1/2 a CPU until his average goes below 1/2 a CPU again…

Would this be possible ?

[mgaidia]

I guess Nicolas idea is to share unused cpu (if there is any left) between users who hits the limit.
For example if at instant T there is 30% free cpu and 2 users hit their limits, the 30% is given to both users equally in case they together needs less than 30% cpu, If a user only need 10% more cpu and the other 20% or more then the 30% cpu left should be devided that way and not equally.

[info]

Exactly majdi, i try to explain better: Ive a total cpu power of 100. Now, please, don stop to think about number of cores, cpu speed, etc. The total is a fake number called 100. I know that every user can use 5 of 100 (again, its not a percentage, just a number to make the idea). Now, I know that 20 users can run simultaneously (20*5).

But, at this time, If I have 10 users on my server, the limits of cloudlinux use half cpu (10*5). I think its better if the limits can be shared with this equation: (standard limits (actually used) + unused cpu)/number of active user at this time. So, what happen in this case? We have 10 users, and they can user 10/100 of cpu each one, and I can use all the cpu. I think this can be a "killer feature", and a big improvement in speed and stability.

Thank you

[clm]

I can see where you are getting with burstable limits and only burstable if the ressources are available.

In order to do this, you would need to be able to instantaneously reduce CPU limits if more CPU is requested by other sites.

If you were to do this, you would need to reserve CPU for system ressources so not to slow down the system because a single user is using up all the available ressources. Sounds quite complicated to get working smoothly !

[iseletsk]

The real problem of burstable limits are broken expectations, and trying to prove to the customer that his site was using too much before, and now that the server is more loaded, you can no longer allow customer to burst -- causing his site to be slow.

Think about it -- for 3 months customer enjoys fast site, and then -- his site is slow. No change in traffic patterns, same number of visitors, etc...

This is pretty much what ruined OpenVZ - people oversold on burstable limits, causing customers complain about stability, when in reality the only thing that happened was lack of room to burst.
This has even higher possibility to happen on shared hosting servers.