eG Monitoring
 

Measures reported by DockContblkioTest

The Docker utilizes a technology called cgroups or control groups (resource controller). The control groups provide a mechanism for aggregating/partitioning sets of tasks in the Docker containers into hierarchical groups with specialized behaviour, where the specialized behaviour is defined by kernel subsystems. The subsystem applies limits or acts upon a group of processes, allocates system resources and tracks resource usage. Each subsystem has specific parameters that enable resource control and reporting mechanisms. The cgroup has a “blkio” subsystem that implements a block io controller. The block io controller gives you a flexible tool to limit the disk I/O utilization of a process group, allows you to establish service level agreements with clearly defined upper limits for bandwidth and throughput. The block io controller is handled by a cgroup based management interface using which the IO policies are swiched based on user options. The IO policies are divided into two policies given below:

  • Proportional weight time based division of disk policy: It takes effect only on leaf nodes when CFQ is being used.

  • Throttling policy: This policy can be used to specify upper IO rate limits on the kernal, and is implemented in generic block layer and used on leaf nodes as well as higher level logical devices like device mapper.

The above-said IO policies are implemented for setting up limits and constraints to the kernal and define what users or groups can access the kernal, augmenting security and data protection measures. If the IO policies are broken due to various errors such as unauthorized access, then you cannot isolate a set of processes that tends to dominate resource consumption, restricting resource use to a preconfigured limit, assign sufficient memory or processing resources (either by specific nodes or relative shares) for an application or set of applications, allocate network or storage bandwidth, track assigned resources and restrict device access to specific users or groups. To avoid such implications, administrators need to monitor the IO policies at regular time intervals.

For each IO policy that is implemented in the Docker, this test monitors the rate of read and write data traffic and also reports synchoronous and asynchoronous IO operations.

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
read Indicates the rate at which the data were read from this IO policy. Mbps Compare the values of these measures across the IO policies to identify the slowest policy in terms of processing read and write operations (respectively).
write Indicates the rate at which the data were written into this IO policy. Mbps
sync Indicates the rate at which the synchronous I/O operations were performed in this IO policy. Mbps In synchronous I/O file, a thread starts an I/O operation and immediately enters a wait state until the I/O request has completed such that the I/O operations of this IO policy are performed in one-by-one manner so as to prevent unwanted data traffic.
Async Indicates the rate at which the asynchronous I/O operations were performed in this IO policy. Mbps A thread performing asynchronous file I/O sends an I/O request to the kernel by calling an appropriate function. If the request is accepted by the kernel, the calling thread continues processing another job until the kernel signals to the thread that the I/O operation is complete. Therefore, speed of the I/O operations will be increased.
total Indicates the rate at which the total I/O operations were performed in this IO policy. Mbps