Voluntary limits for cloud servers
News one paragraph: the opportunity to ask yourself the limits of performance. Limited by CPU, RAM and outgoing traffic.
It looks like this:
We brought to the control panel the opportunity to set limits on resource consumption to ourselves. These default settings for all virtual machines are set to "not limit", which does not differ from the behavior previously.
The scope of these settings (in addition to “play around”) is the study of new software or the launch of applications, the adequacy of which you doubt. You need to understand that if the program needs to perform 100,500 operations to complete it, then it will execute them. That with a speed of 500 operations per second, that with a speed of 100 operations per second. The only question is how quickly this one will do it.
Similarly for traffic. If the server decided to give a 100,500 MB file, then it will give it away. Either at a speed of 900Mb / s, or at a speed of 1Mb / s - only time will differ.
')
... Including the reaction time of a person to a sudden and "wrong" load. It's one thing when a mad program eats 800% of the CPU and clogs the Internet channel into the ceiling, another thing when the ceiling is 20% CPU and a couple of megabits.
In other words, the settings, I hope, will be useful to someone.
What do the limits look like in practice?
(technical part of the patter): the cap parameter of the credit-based Xen skadjule allows you to specify the limit within which the domain can be scheduled for execution.
The same, but with the arrangement: The hypervisor allows you to limit the virtual machine to the time during which it is executed. If the virtual machine "managed" to do everything before the expiration of the limit, then it "gives" the rest of the time to the hypervisor and the limit, thus, it is not noticeable. If the virtual machine reaches the limit, the hypervisor forcibly "takes" control from the virtual machine and does not give up until the beginning of the next interval. The intervals themselves are short - 10 ms.
From the point of view of the virtual machine, this limit looks like steal time. Note that since we charge for the actual time during which the virtual machine used the processor, the steal time is not paid.
What does this look like?
This is how the system load in top with the set limit of 10% looks like when cpuburn is running (money burning utility):
It seems that it took 90% of the CPU. In fact - 9%. Another one percent is occupied by system processes. Note, if you look, the stale (top right) - 80%.
Here is the same, but in terms of htop:
And atop:
Note, atop in this sense is the smartest of all - it clearly shows that the server is “not getting enough” of CPU time.
Note about steal: the value of 1% on the CPU (i.e. up to 8% for 8 cores) is normal for unlimited virtual machines - processing requests for IO and network activity at the time of data transfer to dom0 blocks the virtual machine in a state similar to on steal, if it is more than 10-15%, then your virtual machine does not have enough CPU time. Applies to all hosting on Xen'e - and rackspace, and Amazon.
By itself, the parameter allows you to limit up to 1% of the CPU, but even by 10% the machine becomes somewhat thoughtful, so we limited the control panel to 5%, otherwise the user risks not waiting for the download to complete.
(technical patter) The qos_ratelimit_kpbs parameter for netback allows you to limit the speed of data transferred from a domain.
Here is the 4 Mbit / s limit on the interface:
Human description: the para-virtualized network device in Hen consists of two halves. One - netfront, is in the virtual machine. The second half, netback, is in dom0. When traffic arrives addressed to a virtual machine, it is transmitted through a rather cunning mechanism for transferring pages between domains (also called zero copy) to a virtual machine. The reverse process is similar.
It is important that this process (like everything in xen'e) is cooperative, that is, you need to simultaneously send “desire” on the one hand, and desire to “accept” on the other. If the receiving party does not want to receive data, then the ring buffer (a special data structure that resides in shared memory between the domains and is used to coordinate the work of the components) simply overflows. Since it is a “ring”, the sender has no options for action - either he waits for the recipient to read the data (and moves the pointers in the ring buffer), or he will erase the data about what data to send.
Thus, the recipient has the ability to limit the speed of data reception - just “slower to read” is sufficient.
This is exactly what the netback (half the driver in dom0) does when the limit option is set. It just reads the data from the network adapter of the virtual machine more slowly.
The question arises: what about the incoming traffic?
The situation here is completely different: the traffic has already been sent. We can either drop it or pass it on. If we did not have time to transmit, then the traffic is dropped (otherwise, it will begin to accumulate, clogging the RAM). It is not possible to limit it by speed, you can only discarding the excess. And this is fraught with significant degradation of the quality of the network.
It looks like this:
Do not like fast? You can slowly!
We brought to the control panel the opportunity to set limits on resource consumption to ourselves. These default settings for all virtual machines are set to "not limit", which does not differ from the behavior previously.
The scope of these settings (in addition to “play around”) is the study of new software or the launch of applications, the adequacy of which you doubt. You need to understand that if the program needs to perform 100,500 operations to complete it, then it will execute them. That with a speed of 500 operations per second, that with a speed of 100 operations per second. The only question is how quickly this one will do it.
Similarly for traffic. If the server decided to give a 100,500 MB file, then it will give it away. Either at a speed of 900Mb / s, or at a speed of 1Mb / s - only time will differ.
')
... Including the reaction time of a person to a sudden and "wrong" load. It's one thing when a mad program eats 800% of the CPU and clogs the Internet channel into the ceiling, another thing when the ceiling is 20% CPU and a couple of megabits.
In other words, the settings, I hope, will be useful to someone.
What do the limits look like in practice?
CPU
(technical part of the patter): the cap parameter of the credit-based Xen skadjule allows you to specify the limit within which the domain can be scheduled for execution.
The same, but with the arrangement: The hypervisor allows you to limit the virtual machine to the time during which it is executed. If the virtual machine "managed" to do everything before the expiration of the limit, then it "gives" the rest of the time to the hypervisor and the limit, thus, it is not noticeable. If the virtual machine reaches the limit, the hypervisor forcibly "takes" control from the virtual machine and does not give up until the beginning of the next interval. The intervals themselves are short - 10 ms.
From the point of view of the virtual machine, this limit looks like steal time. Note that since we charge for the actual time during which the virtual machine used the processor, the steal time is not paid.
What does this look like?
This is how the system load in top with the set limit of 10% looks like when cpuburn is running (money burning utility):
It seems that it took 90% of the CPU. In fact - 9%. Another one percent is occupied by system processes. Note, if you look, the stale (top right) - 80%.
Here is the same, but in terms of htop:
And atop:
Note, atop in this sense is the smartest of all - it clearly shows that the server is “not getting enough” of CPU time.
Note about steal: the value of 1% on the CPU (i.e. up to 8% for 8 cores) is normal for unlimited virtual machines - processing requests for IO and network activity at the time of data transfer to dom0 blocks the virtual machine in a state similar to on steal, if it is more than 10-15%, then your virtual machine does not have enough CPU time. Applies to all hosting on Xen'e - and rackspace, and Amazon.
By itself, the parameter allows you to limit up to 1% of the CPU, but even by 10% the machine becomes somewhat thoughtful, so we limited the control panel to 5%, otherwise the user risks not waiting for the download to complete.
Outbound traffic
(technical patter) The qos_ratelimit_kpbs parameter for netback allows you to limit the speed of data transferred from a domain.
Here is the 4 Mbit / s limit on the interface:
Human description: the para-virtualized network device in Hen consists of two halves. One - netfront, is in the virtual machine. The second half, netback, is in dom0. When traffic arrives addressed to a virtual machine, it is transmitted through a rather cunning mechanism for transferring pages between domains (also called zero copy) to a virtual machine. The reverse process is similar.
It is important that this process (like everything in xen'e) is cooperative, that is, you need to simultaneously send “desire” on the one hand, and desire to “accept” on the other. If the receiving party does not want to receive data, then the ring buffer (a special data structure that resides in shared memory between the domains and is used to coordinate the work of the components) simply overflows. Since it is a “ring”, the sender has no options for action - either he waits for the recipient to read the data (and moves the pointers in the ring buffer), or he will erase the data about what data to send.
Thus, the recipient has the ability to limit the speed of data reception - just “slower to read” is sufficient.
This is exactly what the netback (half the driver in dom0) does when the limit option is set. It just reads the data from the network adapter of the virtual machine more slowly.The question arises: what about the incoming traffic?
The situation here is completely different: the traffic has already been sent. We can either drop it or pass it on. If we did not have time to transmit, then the traffic is dropped (otherwise, it will begin to accumulate, clogging the RAM). It is not possible to limit it by speed, you can only discarding the excess. And this is fraught with significant degradation of the quality of the network.
Source: https://habr.com/ru/post/159193/
All Articles