Control group configuration method and device, electronic equipment and storage medium

Abstract

The application discloses a control group configuration method and device, electronic equipment and storage medium, relates to the technical field of resource management, and includes a configuration file of a configuration region divided according to a control group subsystem, which is created to uniformly manage resource configuration information, an automatic loading of resource configuration is realized in a bottom-up recursive manner, and the order and consistency of the configuration process are ensured through a task table, a locking and a persistence mechanism, so that the technical problems of a complicated configuration process, high maintenance cost, increased resource conflict risk and slow system dynamic adjustment response in the existing control group configuration method can be solved, the configuration process is simplified, the maintenance cost is reduced, the resource conflict is reduced, the system dynamic adjustment response speed is improved, and the technical effects of improving the resource management efficiency and system operation stability are achieved.

Description

Technical Field

[0001] This disclosure relates to the field of resource management technology, and in particular to a method, apparatus, electronic device and storage medium for configuring a control group. Background Technology

[0002] With the rapid development of distributed computing technologies such as cloud computing and big data, Linux, as the underlying operating system platform, has become a key factor in ensuring system stability and performance optimization due to its resource management capabilities.

[0003] Control Groups, as a core resource isolation and restriction mechanism provided by the Linux kernel, are widely used in scenarios such as containerized deployment, task scheduling, and system resource allocation. They enable fine-grained control over the CPU, memory, input / output, and other resources of process groups through a hierarchical structure.

[0004] Existing control group configuration methods rely on pre-configured systemd settings, command-line tools, or distributed configuration files, lacking a unified interface and automation mechanism. This can lead to cumbersome configuration processes, high maintenance costs, increased risk of resource conflicts, and an inability to respond promptly to dynamic system adjustments, thereby affecting the efficiency of resource management and the stability of system operation. Summary of the Invention

[0005] This application provides a method, apparatus, electronic device, and storage medium for configuring control groups, in order to at least solve the problems in the related art that lead to cumbersome configuration processes, high maintenance costs, increased risk of resource conflicts, and inability to respond in a timely manner when the system is dynamically adjusted, thereby affecting the efficiency of resource management and the stability of system operation.

[0006] This application provides a method for configuring a control group, including:

[0007] Create a configuration file, which is divided into configuration areas according to the control group subsystem, and is used to store the resource configuration information of each control group and sub-user group;

[0008] In response to system startup, the configuration file is loaded, and resources are configured sequentially for the lowest-level sub-user groups in a bottom-up recursive manner.

[0009] Obtain the configuration request information of the target configuration file and write the configuration request information into the task table; wherein, during the configuration process, the target configuration file is locked, and after the configuration is completed, the lock is released and the configuration information is persisted to the corresponding configuration file.

[0010] Optionally, the step of loading the configuration file and configuring resources for the lowest-level sub-user groups in a bottom-up recursive manner in response to system startup includes:

[0011] In response to system startup, the service manager is set to start immediately after the file system is mounted. During system startup, configuration files are loaded in a bottom-up recursive manner, prioritizing the resource configurations of the lowest-level subgroups and then processing the resource configurations of the parent groups layer by layer upwards.

[0012] Optionally, the configuration request information for obtaining the target configuration file may further include:

[0013] Receive external configuration requests based on Socket listening; the request includes instructions, session ID, and configuration data; or,

[0014] Execute configuration operations via local system commands.

[0015] Optionally, the step of receiving external configuration requests based on Socket listening includes:

[0016] Bind the target device's Internet Protocol address and specified port, and receive configuration requests from external systems. The configuration requests include operation instructions, session ID, and control group information to be configured.

[0017] Optionally, the configuration operation performed via local system commands includes:

[0018] Configuration requests are received based on a predefined command-line interface; wherein, the command-line interface supports specifying the configuration operation type through command parameters and providing specific resource configuration data through standard input or configuration files.

[0019] Optionally, writing the configuration request information into the task table includes:

[0020] During the configuration process, the task table performs a file-level mutex lock operation on the target configuration file to prevent multiple processes from modifying the same configuration file at the same time, which could lead to data inconsistency.

[0021] In response to the completion of task table configuration, update the task status and return the updated task information to the requester.

[0022] Optionally, the method further includes:

[0023] Version management of configuration files is enabled, including backup, restoration, and difference comparison. It also supports rolling back to a previous version when configuration errors occur.

[0024] Optionally, the task table includes at least one of sessionid, user group name, progress status, and configuration information.

[0025] Optionally, the method further includes:

[0026] Receive a request to obtain control group configuration information, and determine the target control group to be queried based on the request;

[0027] According to the hierarchical structure of the control group, the resource configuration information of the target control group and the resource configuration information of all sub-control groups under the target control group are obtained in a top-down order.

[0028] All acquired resource configuration information is categorized and integrated according to the control group subsystem, and the categorized and integrated resource configuration information is fed back to the request initiator.

[0029] Optionally, the step of loading the configuration file and configuring resources for the lowest-level sub-user groups in a bottom-up recursive manner in response to system startup includes:

[0030] If the control group to be adjusted is a sub-control group, the upper limit of each resource configuration parameter of the sub-control group shall not exceed the upper limit of the resource configuration parameter of the parent control group to which it belongs; wherein the resource configuration adjustment process of the sub-control group is based on the currently effective resource configuration of the parent control group to which the sub-control group belongs, to ensure the consistency of resource configuration logic between control group levels.

[0031] Optionally, the method further includes:

[0032] Each control group that requires resource restrictions is assigned a separate configuration file; wherein, the configuration file is divided into independent configuration areas according to the control group subsystems;

[0033] If the service process responsible for loading the control group configuration restarts, the restarted service process will automatically read all control group configuration files in the dedicated directory and re-execute resource configuration application operations on each control group and its subordinate sub-control groups in a bottom-up recursive manner to ensure the continued effectiveness of the control group configuration.

[0034] This application also provides a configuration device for a control group, including:

[0035] A creation unit is used to create configuration files. The configuration files are divided into configuration areas according to the control group subsystems and are used to store resource configuration information for each control group and sub-user group.

[0036] The loading unit is used to load the configuration file in response to system startup and to configure resources for the lowest-level sub-user groups in a bottom-up recursive manner.

[0037] The first acquisition unit is used to acquire configuration request information of the target configuration file and write the configuration request information into the task table; wherein, during the configuration process, the target configuration file is locked, and after the configuration is completed, the lock is released and the configuration information is persisted to the corresponding configuration file.

[0038] Optionally, the loading unit is further configured to:

[0039] In response to system startup, the service manager is set to start immediately after the file system is mounted. During system startup, configuration files are loaded in a bottom-up recursive manner, prioritizing the resource configurations of the lowest-level subgroups and then processing the resource configurations of the parent groups layer by layer upwards.

[0040] Optionally, the first acquisition unit is further configured to:

[0041] Receive external configuration requests based on Socket listening; the request includes instructions, session ID, and configuration data; or,

[0042] Execute configuration operations via local system commands.

[0043] Optionally, the first acquisition unit is further configured to:

[0044] Bind the target device's Internet Protocol address and specified port, and receive configuration requests from external systems. The configuration requests include operation instructions, session ID, and control group information to be configured.

[0045] Optionally, the first acquisition unit is further configured to:

[0046] Configuration requests are received based on a predefined command-line interface; wherein, the command-line interface supports specifying the configuration operation type through command parameters and providing specific resource configuration data through standard input or configuration files.

[0047] Optionally, the first acquisition unit is further configured to:

[0048] During the configuration process, the task table performs a file-level mutex lock operation on the target configuration file to prevent multiple processes from modifying the same configuration file at the same time, which could lead to data inconsistency.

[0049] In response to the completion of task table configuration, update the task status and return the updated task information to the requester.

[0050] Optionally, the device further includes:

[0051] The management unit is used for version management of configuration files, including backup, recovery, and difference comparison of configuration files, and supports rolling back to a previous version when configuration errors occur.

[0052] Optionally, the task table includes at least one of sessionid, user group name, progress status, and configuration information.

[0053] Optionally, the device further includes:

[0054] The determining unit is used to receive a request to obtain control group configuration information and determine the target control group to be queried based on the request.

[0055] The second acquisition unit is used to acquire the resource configuration information of the target control group and the resource configuration information of all sub-control groups under the target control group in a top-down order according to the hierarchical structure of the control group.

[0056] The feedback unit is used to classify and integrate all the acquired resource configuration information according to the control group subsystem, and then feed back the classified and integrated resource configuration information to the request initiator.

[0057] Optionally, the loading unit is further configured to:

[0058] If the control group to be adjusted is a sub-control group, the upper limit of each resource configuration parameter of the sub-control group shall not exceed the upper limit of the resource configuration parameter of the parent control group to which it belongs; wherein the resource configuration adjustment process of the sub-control group is based on the currently effective resource configuration of the parent control group to which the sub-control group belongs, to ensure the consistency of resource configuration logic between control group levels.

[0059] Optionally, the device further includes:

[0060] The allocation unit is used to allocate a separate configuration file for each control group that requires resource restrictions; wherein, the configuration file is divided into independent configuration areas according to the control group subsystems;

[0061] The reading unit is used to automatically read all control group configuration files in the dedicated directory after the service process responsible for loading control group configurations restarts, and re-execute resource configuration application operations on each control group and its subordinate sub-control groups in a bottom-up recursive manner to ensure the continued effectiveness of the control group configurations.

[0062] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the configuration method of any of the above-described control groups.

[0063] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described control group configuration methods.

[0064] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described control group configuration methods.

[0065] This application addresses the technical problems of cumbersome configuration processes, high maintenance costs, increased resource conflict risks, and untimely dynamic adjustment responses in existing control group configuration methods by creating configuration files that divide configuration areas according to control group subsystems for unified management of resource configuration information. It also utilizes a bottom-up recursive approach to automate resource configuration loading and ensures the orderliness and consistency of the configuration process through task tables, locking, and persistence mechanisms (avoiding the lack of unified interfaces and automation mechanisms in existing methods). This simplifies the configuration process, reduces maintenance costs, minimizes resource conflicts, improves the dynamic adjustment response speed of the system, and ultimately enhances resource management efficiency and system stability. Attached Figure Description

[0066] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0067] Figure 1 A schematic flowchart illustrating a configuration method for a control group provided in an embodiment of this disclosure;

[0068] Figure 2 This is a schematic diagram of the configuration device for a control group provided in an embodiment of the present disclosure;

[0069] Figure 3 This is a schematic diagram of the configuration device for another control group provided in an embodiment of this disclosure. Detailed Implementation

[0070] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0071] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0072] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0073] The embodiments of this application provide a method for configuring a control group. The method is described in detail below in conjunction with the execution flow of the control group configuration method. Figure 1 This is a flowchart illustrating a method for configuring a control group according to an embodiment of the present disclosure.

[0074] like Figure 1 As shown, the method includes the following steps:

[0075] Step 101: Create a configuration file. The configuration file is divided into configuration areas according to the control group subsystem and is used to store the resource configuration information of each control group and sub-user group.

[0076] In Linux systems, cgroups, or control groups, are a physical resource isolation mechanism provided by the Linux kernel. This mechanism enables resource restrictions, isolation, and statistical functions for Linux processes or process groups. To ensure the orderly storage and management of resource configuration information for each control group and its subgroups, the configuration file must be created in a designated configuration directory within the Linux system. The core principle is to divide the configuration area according to the control group subsystem. Control group subsystems include several types, such as the CPU subsystem for limiting process CPU usage, the memory subsystem for limiting process memory usage, the blkio subsystem for limiting process block device I / O, and the cpuset subsystem for allocating individual CPU or memory nodes to processes within cgroups. Each subsystem corresponds to an independent configuration area. Within the configuration area corresponding to each subsystem, the specific resource configuration information of each control group and sub-user group under that subsystem will be stored. The resource configuration of the sub-user group must be set based on the resource configuration of the corresponding parent control group. The sub-user group cannot be configured with more resources than the parent control group. This ensures the rationality and consistency of the resource configuration hierarchy, laying the foundation for loading cgroup configuration and achieving effective resource management when the Linux system starts up.

[0077] Step 102: In response to system startup, load the configuration file and configure resources for the lowest-level sub-user groups in a bottom-up recursive manner.

[0078] The system relies on the cgroup_configd service, which prioritizes file system mounting during the system startup process and is specifically designed to respond to system startup events and handle cgroup configuration loading. When the system starts and triggers this service, cgroup_configd automatically locates the specified directory storing configuration files and reads the resource configuration information for each control group and sub-user group. Then, it performs resource configuration in a bottom-up recursive manner: because cgroups have a tree-like hierarchical structure, the bottom-level sub-user groups are the terminal groups with no lower-level groups. The recursive process first locates all bottom-level sub-user groups and prioritizes their resource configuration, strictly adhering to the rule that sub-user group resources cannot exceed those of their parent control group. The group resource setting module is then called to apply the configuration to the corresponding sub-user groups. After all bottom-level sub-user groups are configured, the process recursively moves upwards to process the parent control groups corresponding to these sub-user groups, completing the resource configuration for each level in sequence. This bottom-up recursive approach effectively avoids resource conflicts between the parent control group and the already configured child user groups, ensuring that the resource configuration of the entire cgroup hierarchy is orderly and compliant with rules, and providing a stable configuration foundation for the system's subsequent resource limiting and isolation functions.

[0079] Step 103: Obtain the configuration request information of the target configuration file and write the configuration request information into the task table; wherein, during the configuration process, the target configuration file is locked, and after the configuration is completed, the lock is released and the configuration information is persisted to the corresponding configuration file.

[0080] In Linux systems, cgroups, or control groups, are a physical resource isolation mechanism provided by the kernel. The target configuration file refers to the file created in step 101, which is used to store resource configuration information for each control group and sub-user group, divided into configuration areas according to the control group subsystem. Configuration request information can be obtained through methods provided by the resource setting module, such as configuration requests initiated locally by Linux system commands, or configuration requests received externally via the Linux local IP address and a specified port through socket listening. The request information includes instructions, session ID, and configuration data for the corresponding group. When executing step 103, the configuration request information of the target configuration file is first obtained, and then written to the task table. The task table is used to maintain single configuration progress information and mutually exclusive configurations, recording the session ID (used to identify configuration uniqueness), the group name to which the target configuration file belongs, configuration progress status, and configuration information, ensuring clear tracking of the configuration process later. During the specific configuration of the target configuration file, since each configuration item within the target configuration file exists in file form, to avoid conflicts caused by multiple configuration operations modifying the same target configuration file simultaneously, the target configuration file needs to be locked to ensure the mutual exclusion and accuracy of configuration operations. Once the configuration operation on the target configuration file is completed, the lock is immediately released, and the configuration information generated in this configuration is persistently stored in the corresponding configuration file to ensure that the configuration information is not lost due to system operation interruption, thus providing a stable configuration basis for subsequent cgroup resource management.

[0081] In some embodiments, the step of loading the configuration file in response to system startup and configuring resources for the lowest-level sub-user groups in a bottom-up recursive manner includes:

[0082] In response to system startup, the service manager is set to start immediately after the file system is mounted. During system startup, configuration files are loaded in a bottom-up recursive manner, prioritizing the resource configurations of the lowest-level subgroups and then processing the resource configurations of the parent groups layer by layer upwards.

[0083] File system mounting is a necessary prerequisite for loading cgroup configurations, because cgroup itself is a file system in the Linux system. Only after the file system is mounted can the specified directory storing cgroup configuration files be accessed normally. When the system starts, the service manager needs to be set to start immediately after the file system is mounted to ensure that the service manager can successfully read the stored configuration files. The configuration files are divided into configuration areas according to the control group subsystem. They store the resource configuration information of each control group and sub-user group, and the resource configuration quota of the sub-user group never exceeds that of the corresponding parent user group.

[0084] After the service manager starts, it loads configuration files recursively from bottom to top. The lowest-level subgroups are the terminal groups in the cgroup tree hierarchy that have no lower-level groups. The service manager prioritizes configuring resources for these lowest-level subgroups by calling the group resource setting module to apply the corresponding configurations from the configuration files to these subgroups. After all the resource configurations for the lowest-level subgroups are completed, the service manager then processes the corresponding parent groups of these subgroups layer by layer upwards, completing the resource configuration of each level of parent groups in sequence. This approach effectively avoids resource conflicts between parent groups during configuration and already configured subgroups, ensuring the orderliness and rationality of resource configuration throughout the cgroup hierarchy, and laying a stable foundation for the subsequent implementation of resource limiting and isolation functions in the Linux system.

[0085] In some embodiments, the step of obtaining the configuration request information for the target configuration file further includes:

[0086] Receive external configuration requests based on Socket listening; the request includes instructions, session ID, and configuration data; or,

[0087] Execute configuration operations via local system commands.

[0088] Sockets are the mechanism for implementing network communication or inter-process communication in Linux systems. Local system commands are instructions that can be directly executed in Linux systems to perform specific operations. Obtaining configuration request information from a target configuration file involves two specific methods.

[0089] The first method is based on receiving external configuration requests through Socket listening. First, in the Linux system, a server is set up using the resource settings module via the local IP address and a specified port. This server continuously listens for configuration requests sent from outside the system, targeting the desired configuration file. These requests must contain three key pieces of information: instructions to distinguish the specific operation type (e.g., modifying a resource configuration in the target configuration file or querying related configurations); a session ID to uniquely identify each configuration request and prevent confusion between different requests; and configuration data, which contains the specific resource configuration content related to the target configuration file, such as the CPU subsystem utilization limit value under a specific control group. When the server receives these external requests via Socket listening, it parses the request information and extracts the valid configuration request information related to the target configuration file.

[0090] The second method is to execute configuration operations via local system commands. On a Linux system, users or system programs can directly invoke preset local system commands to initiate configuration requests for a target configuration file. When executing this command, configuration-related information must be included, such as instructions, session ID, and configuration data, serving the same purpose as the corresponding information in external requests. After the local system command is executed, the system will locate the corresponding target configuration file based on the instructions and related data in the command, and extract the necessary configuration request information from it, preparing for subsequent writing of the configuration request information into the task table and carrying out configuration operations.

[0091] In some embodiments, receiving external configuration requests based on Socket listening includes:

[0092] Bind the target device's Internet Protocol address and specified port, and receive configuration requests from external systems. The configuration requests include operation instructions, session ID, and control group information to be configured.

[0093] When receiving external configuration requests via Socket listening, the first step is to bind the target device's Internet Protocol address (IPA) to a specified port on the target device's Linux system using the resource settings module. This binding step is fundamental to ensuring accurate transmission of external configuration requests. By binding a specific IPA and port, the external system can clearly locate the server on the target device that handles cgroup configuration requests, preventing requests from failing to reach the server due to unclear addresses or ports. After binding, the server will continuously listen via the bound IPA and port using Socket listening, capturing cgroup configuration requests sent from external systems in real time. The configuration request sent by the external system must contain three key pieces of information: the operation instruction, which specifies the type of operation for this configuration, such as modifying the resource limits of a control group or adding a new control group configuration; the session ID, which uniquely identifies this configuration request to prevent confusion between different external requests and ensure that each configuration operation can be accurately traced; and the control group information to be configured, which specifies the control group to be configured, including the control group name, its hierarchy, and associated subsystems (such as the CPU subsystem, memory subsystem, etc.), so that the server can accurately locate the configuration file of the corresponding control group and prepare for subsequent configuration request information processing and configuration operations.

[0094] In some embodiments, performing the configuration operation via local system commands includes:

[0095] Configuration requests are received based on a predefined command-line interface; wherein, the command-line interface supports specifying the configuration operation type through command parameters and providing specific resource configuration data through standard input or configuration files.

[0096] When performing configuration operations via local system commands, the core relies on a predefined command-line interface to receive configuration requests. Users or locally running programs can invoke the corresponding local system commands in the system terminal or automation scripts to initiate configuration requests for cgroups through this predefined interface. When invoking a command, the type of configuration operation must be specified through command parameters. For example, the command parameter "config-set" corresponds to a resource configuration setting operation, "config-get" corresponds to a configuration information query operation, and "config-reload" corresponds to a configuration reload operation. The system identifies these command parameters to determine the specific target of the command execution and then initiates the corresponding processing flow.

[0097] Specific resource configuration data can be provided in two ways: one is through standard input, where users or programs can input data in real time after command execution; the other is through configuration files, where users can write resource configuration data into a specified configuration file according to the subsystem's format, and specify the file path through parameters when calling the command, allowing the system to read the data from that file. Once the command-line interface receives the command parameters and resource configuration data, it integrates them into valid configuration request information, laying the foundation for subsequent operations such as writing to the task table, locking the configuration file, and persistence, ensuring efficient and accurate execution of local cgroup configurations.

[0098] In some embodiments, writing the configuration request information into the task table includes:

[0099] During the configuration process, the task table performs a file-level mutex lock operation on the target configuration file to prevent multiple processes from modifying the same configuration file at the same time, which could lead to data inconsistency.

[0100] In response to the completion of task table configuration, update the task status and return the updated task information to the requester.

[0101] When writing configuration request information to the task table, the first step is to completely record the obtained configuration request information (including operation commands, session ID, control group information to be configured, and specific resource configuration data) into the task table to ensure that the processing of the configuration request can be clearly tracked later. Next, the task table will perform a file-level mutex lock operation on the target configuration file involved in this configuration. This is because in a multi-process concurrent Linux system environment, multiple processes may simultaneously initiate modification requests for the same target configuration file. A file-level mutex lock can forcefully ensure that only one process can modify the target configuration file at any given time, fundamentally preventing configuration data corruption and loss caused by concurrent modifications, and ensuring the accuracy of the configuration process.

[0102] Once all configuration operations corresponding to the task table are completed, the system will immediately respond and update the task status in the task table, for example, changing the task status from "Configuring" to "Configuration Completed". At the same time, it will integrate the updated complete task information, including the session ID of the configuration request, the name of the control group to which the target configuration file belongs, the final resource configuration result, etc., and promptly return this updated task information to the requester who initiated the configuration request, so that the requester can keep track of the configuration operation results in real time, providing a basis for possible subsequent configuration verification or adjustment, and ensuring the closed loop and traceability of the entire cgroup configuration process.

[0103] In some embodiments, the method further includes:

[0104] Version management of configuration files is enabled, including backup, restoration, and difference comparison. It also supports rolling back to a previous version when configuration errors occur.

[0105] Configuration file version management needs to cover backup, recovery, difference comparison, and error rollback functions. In the configuration file backup stage, the system automatically triggers a backup before each modification operation, and also supports scheduled backups. The backup content includes not only the complete data of the current configuration file but also a version identifier, backup timestamp, and operator information. Backup files are stored in a pre-defined dedicated directory (e.g., / etc / cgroup_config / backup) and named with version number or timestamp to ensure each backup version is clearly distinguishable. When configuration file recovery is required, if an anomaly is detected in the current configuration file (e.g., incorrect configuration parameters causing resource control failure) or the system malfunctions due to configuration issues, a target historical version can be selected from the backup directory. A pre-defined recovery command will then overwrite the current erroneous configuration file with this version's configuration file. After recovery, the system will automatically call the group resource settings module to reload the recovered configuration file, restoring the cgroup resource configuration to its corresponding historical state. The difference comparison function supports comparing the current configuration file with any historical backup version, as well as comparing configuration differences between different historical versions. The comparison process accurately identifies changes in the values ​​of configuration items in each subsystem.

[0106] For example, the usage limits of the CPU subsystem and the memory usage limits of the memory subsystem are clearly presented, along with the specific numerical differences, helping operators quickly locate configuration change points. When configuration errors cause cgroups to fail to perform resource limiting and isolation functions properly, or trigger system service anomalies, an error rollback operation can be triggered. Based on a backed-up historical working version, the rollback can be completed with simple commands. After the rollback, the system will verify the validity of the configuration, ensuring that the cgroup resource configuration is restored to a state where resources can be managed normally, thus guaranteeing the stability of cgroup resource management in the Linux system.

[0107] In some embodiments, the task table includes at least one of sessionid, user group name, progress status, and configuration information.

[0108] In some embodiments, the method further includes:

[0109] Receive a request to obtain control group configuration information, and determine the target control group to be queried based on the request;

[0110] According to the hierarchical structure of the control group, the resource configuration information of the target control group and the resource configuration information of all sub-control groups under the target control group are obtained in a top-down order.

[0111] All acquired resource configuration information is categorized and integrated according to the control group subsystem, and the categorized and integrated resource configuration information is fed back to the request initiator.

[0112] The system receives requests to retrieve control group configuration information. These requests can be initiated through methods supported by the resource settings module, such as external requests sent via Socket listening or local requests initiated via system commands. The system extracts key identification information from the requests to determine the target control group to be queried, for example, by locating the corresponding target control group based on the control group name or unique identifier carried in the request. Next, following the hierarchical structure of the control groups, the system retrieves configuration information in a top-down order: first, it reads the target control group's own resource configuration information, which is stored in configuration files divided into subsystems, covering the specific resource limits and allocation data of the control group under each subsystem; then, it traverses down layer by layer to all sub-control groups under the target control group, retrieving the resource configuration information of each sub-control group in turn, ensuring complete coverage of the configuration content of the target control group and all its sub-control groups, and avoiding omissions.

[0113] All acquired resource configuration information is categorized and integrated according to the control group subsystems. For example, all configuration data involving the CPU subsystem is grouped into one category, configuration data of the memory subsystem is grouped into another category, and configuration data of the blkio subsystem is categorized separately, making the configuration information structure clear and easy to view. Then, depending on the method of initiating the request, the categorized and integrated resource configuration information is fed back to the request initiator. If it is an external socket request, the feedback is transmitted over the network; if it is a local system command request, the feedback is directly output to the terminal, ensuring that the request initiator accurately obtains the required control group configuration information.

[0114] In some embodiments, the step of loading the configuration file in response to system startup and configuring resources for the lowest-level sub-user groups in a bottom-up recursive manner includes:

[0115] If the control group to be adjusted is a sub-control group, the upper limit of each resource configuration parameter of the sub-control group shall not exceed the upper limit of the resource configuration parameter of the parent control group to which it belongs; wherein the resource configuration adjustment process of the sub-control group is based on the currently effective resource configuration of the parent control group to which the sub-control group belongs, to ensure the consistency of resource configuration logic between control group levels.

[0116] During the system startup, configuration file loading, and resource configuration of the lowest-level sub-user groups in a bottom-up recursive manner, if the control group to be adjusted is a sub-control group, the upper limit constraint of resource configuration parameters must be strictly followed—the upper limit value of each resource configuration parameter of the sub-control group must not exceed the upper limit value of the resource configuration parameters of its parent control group. This is because the hierarchical structure of cgroups determines that the resource allocation of sub-control groups depends on the parent control group. The parent control group defines the boundaries of resource usage for the sub-control groups. For example, if the CPU utilization limit of the parent control group is set to 50%, then the CPU utilization limit of its subordinate sub-control groups cannot exceed 50% no matter how it is adjusted. If the memory usage limit of the parent control group is set to 8G, the memory usage limit of the sub-control group must also be within 8G to avoid the situation where the resource demand of the sub-control group exceeds the capacity of the parent control group. Meanwhile, the resource configuration adjustment process of the sub-control group is not based on the historical configuration or preset initial configuration of the parent control group. Instead, it is based on the currently effective resource configuration of the parent control group to which the sub-control group belongs. By reading the resource control parameters currently being executed by the parent control group, the reasonable range of adjustment for the sub-control group is determined. This adjustment method can ensure that the effective resource configuration rules established by the parent control group are not broken, thereby ensuring the consistency of resource configuration logic between control group levels. After the cgroup system starts up and loads the configuration, the resource allocation of each level of control group can not only comply with the subordinate relationship constraints, but also achieve orderly resource isolation and restriction.

[0117] In some embodiments, the method further includes:

[0118] Each control group that requires resource restrictions is assigned a separate configuration file; wherein, the configuration file is divided into independent configuration areas according to the control group subsystems;

[0119] Each control group requiring resource limits is assigned a separate configuration file. This allows for independent storage of resource configurations for each control group, preventing confusion between configurations from different groups and facilitating subsequent targeted modifications and management. Furthermore, each independent configuration file is divided into separate configuration areas based on the control group's subsystems. For example, the CPU subsystem area stores CPU utilization limit parameters, the memory subsystem area stores memory usage quota parameters, and the blkio subsystem area stores block device I / O limit parameters. This clear separation of subsystem configuration areas facilitates quick location and adjustment of specific resource configurations. Furthermore, if the service process responsible for loading control group configurations (cgroup_configd service) restarts, it will automatically read all control group configuration files in its dedicated directory (i.e., / etc / cgroup_config directory, which is the default directory for storing all independent configuration files of all control groups) without manual intervention. Then, it will re-execute resource configuration application operations on each control group and its subordinate sub-control groups in a bottom-up recursive manner. It will first process the resource configuration of the lowest-level sub-control groups to ensure that the upper limit of the resource configuration parameters of the sub-control groups does not exceed that of their parent control groups, and then process the configuration of the parent control groups layer by layer upwards. In this way, it ensures that the resource configuration of each control group can be quickly restored and conform to the hierarchical constraints after the service process restarts, thereby ensuring the continued effectiveness of the control group configuration and maintaining the stable management of process resources by the Linux system.

[0120] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0121] Embodiments of this application also provide a configuration device for a control group. Figure 2 This is a schematic diagram of the configuration device for a control group provided in an embodiment of the present disclosure, as shown below. Figure 2 As shown, it includes:

[0122] The creation unit 21 is used to create a configuration file. The configuration file is divided into configuration areas according to the control group subsystem and is used to store the resource configuration information of each control group and sub-user group.

[0123] Loading unit 22 is used to load the configuration file in response to system startup, and to configure resources for the lowest-level sub-user groups in a bottom-up recursive manner.

[0124] The first acquisition unit 23 is used to acquire configuration request information of the target configuration file and write the configuration request information into the task table; wherein, during the configuration process, the target configuration file is locked, and after the configuration is completed, the lock is released and the configuration information is persisted to the corresponding configuration file.

[0125] Furthermore, in one possible implementation of this disclosure embodiment, the loading unit 22 is further configured to:

[0126] In response to system startup, the service manager is set to start immediately after the file system is mounted. During system startup, configuration files are loaded in a bottom-up recursive manner, prioritizing the resource configurations of the lowest-level subgroups and then processing the resource configurations of the parent groups layer by layer upwards.

[0127] Furthermore, in one possible implementation of this disclosure, the first acquisition unit 23 is further configured to:

[0128] Receive external configuration requests based on Socket listening; the request includes instructions, session ID, and configuration data; or,

[0129] Execute configuration operations via local system commands.

[0130] Furthermore, in one possible implementation of this disclosure, the first acquisition unit 23 is further configured to:

[0131] Bind the target device's Internet Protocol address and specified port, and receive configuration requests from external systems. The configuration requests include operation instructions, session ID, and control group information to be configured.

[0132] Furthermore, in one possible implementation of this disclosure, the first acquisition unit 23 is further configured to:

[0133] Configuration requests are received based on a predefined command-line interface; wherein, the command-line interface supports specifying the configuration operation type through command parameters and providing specific resource configuration data through standard input or configuration files.

[0134] Furthermore, in one possible implementation of this disclosure, the first acquisition unit 23 is further configured to:

[0135] During the configuration process, the task table performs a file-level mutex lock operation on the target configuration file to prevent multiple processes from modifying the same configuration file at the same time, which could lead to data inconsistency.

[0136] In response to the completion of task table configuration, update the task status and return the updated task information to the requester.

[0137] Furthermore, in one possible implementation of the embodiments of this disclosure, such as Figure 3 As shown, the device further includes:

[0138] Management unit 24 is used for version management of configuration files, including backup, recovery and difference comparison of configuration files, and supports rolling back to historical versions when configuration errors occur.

[0139] Furthermore, in one possible implementation of this disclosure embodiment, the task table includes at least one of sessionid, user group name, progress status, and configuration information.

[0140] Furthermore, in one possible implementation of the embodiments of this disclosure, such as Figure 3 As shown, the device further includes:

[0141] Determining unit 25 is used to receive a request to obtain control group configuration information and determine the target control group to be queried based on the request.

[0142] The second acquisition unit 26 is used to acquire the resource configuration information of the target control group and the resource configuration information of all sub-control groups under the target control group in a top-down order according to the hierarchical structure of the control group.

[0143] Feedback unit 27 is used to classify and integrate all the acquired resource configuration information according to the control group subsystem, and to feed back the classified and integrated resource configuration information to the request initiator.

[0144] Furthermore, in one possible implementation of this disclosure embodiment, the loading unit 22 is further configured to:

[0145] If the control group to be adjusted is a sub-control group, the upper limit of each resource configuration parameter of the sub-control group shall not exceed the upper limit of the resource configuration parameter of the parent control group to which it belongs; wherein the resource configuration adjustment process of the sub-control group is based on the currently effective resource configuration of the parent control group to which the sub-control group belongs, to ensure the consistency of resource configuration logic between control group levels.

[0146] Furthermore, in one possible implementation of the embodiments of this disclosure, such as Figure 3 As shown, the device further includes:

[0147] The allocation unit 28 is used to allocate a separate configuration file for each control group that requires resource restrictions; wherein, the configuration file is divided into independent configuration areas according to the control group subsystem;

[0148] The reading unit 29 is used to automatically read all control group configuration files in the dedicated directory after the service process responsible for loading control group configurations restarts, and re-execute resource configuration application operations on each control group and its subordinate sub-control groups in a bottom-up recursive manner to ensure the continued effectiveness of the control group configurations.

[0149] For a description of the features in the embodiment corresponding to the configuration device of the control group, please refer to the relevant description in the embodiment corresponding to the configuration method of the control group, which will not be repeated here.

[0150] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above-described control group configuration method embodiments.

[0151] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described control group configuration method embodiments when it is run.

[0152] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0153] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described control group configuration method embodiments.

[0154] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in any of the above-described control group configuration method embodiments.

[0155] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0156] The foregoing has provided a detailed description of a configuration method, apparatus, electronic device, and storage medium for a control group. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for configuring a control group, characterized in that, include: Create a configuration file, which is divided into configuration areas according to the control group subsystems and is used to store the resource configuration information of each control group and sub-control group; In response to system startup, the configuration file is loaded, and resources are configured sequentially for the lowest-level sub-control groups in a bottom-up recursive manner. Obtain the configuration request information of the target configuration file and write the configuration request information into the task table; wherein, during the configuration process, the target configuration file is locked, and after the configuration is completed, the lock is released and the configuration information is persisted to the corresponding configuration file; The step of responding to system startup, loading the configuration file, and configuring resources for the lowest-level sub-control groups in a bottom-up recursive manner includes: In response to system startup, the service manager is set to start immediately after the file system is mounted. During system startup, configuration files are loaded in a bottom-up recursive manner, prioritizing the resource configurations of the lowest-level sub-control groups and then processing the resource configurations of the parent control groups layer by layer upwards.

2. The method according to claim 1, characterized in that, The configuration request information for obtaining the target configuration file also includes: Receive external configuration requests based on Socket listening; the request includes instructions, session ID, and configuration data; or, Execute configuration operations via local system commands.

3. The method according to claim 2, characterized in that, The method of receiving external configuration requests based on Socket listening includes: Bind the target device's Internet Protocol address and a specified port, and receive configuration requests from external systems. The configuration requests include operation instructions, session ID, and control group information to be configured.

4. The method according to claim 2, characterized in that, The configuration operation performed via local system commands includes: Configuration requests are received based on a predefined command-line interface; wherein, the command-line interface supports specifying the configuration operation type through command parameters and providing specific resource configuration data through standard input or configuration files.

5. The method according to claim 1, characterized in that, The step of writing the configuration request information into the task table includes: During the configuration process, the task table performs a file-level mutex lock operation on the target configuration file to prevent multiple processes from modifying the same configuration file at the same time, which could lead to data inconsistency. In response to the completion of task table configuration, update the task status and return the updated task information to the requester.

6. The method according to claim 1, characterized in that, The method further includes: Version management of configuration files is enabled, including backup, restoration, and difference comparison. It also supports rolling back to a previous version when configuration errors occur.

7. The method according to claim 1, characterized in that, The task table includes at least one of the following: sessionid, control group name, progress status, and configuration information.

8. The method according to claim 1, characterized in that, The method further includes: Receive a request to obtain control group configuration information, and determine the target control group to be queried based on the request; According to the hierarchical structure of the control group, the resource configuration information of the target control group and the resource configuration information of all sub-control groups under the target control group are obtained in a top-down order. All acquired resource configuration information is categorized and integrated according to the control group subsystem, and the categorized and integrated resource configuration information is fed back to the request initiator.

9. The method according to claim 1, characterized in that, The process of responding to system startup, loading the configuration file, and configuring resources for the lowest-level sub-control groups in a bottom-up recursive manner includes: If the control group to be adjusted is a sub-control group, the upper limit of each resource configuration parameter of the sub-control group shall not exceed the upper limit of the resource configuration parameter of the parent control group to which it belongs; wherein the resource configuration adjustment process of the sub-control group is based on the currently effective resource configuration of the parent control group to which the sub-control group belongs, to ensure the consistency of resource configuration logic between control group levels.

10. The method according to claim 1, characterized in that, The method further includes: Each control group that requires resource restrictions is assigned a separate configuration file; wherein, the configuration file is divided into independent configuration areas according to the control group subsystems; If the service process responsible for loading the control group configuration restarts, the restarted service process will automatically read all control group configuration files in the dedicated directory and re-execute resource configuration application operations on each control group and its subordinate sub-control groups in a bottom-up recursive manner to ensure the continued effectiveness of the control group configuration.

11. A configuration device for a control group, characterized in that, include: A creation unit is used to create configuration files. The configuration files are divided into configuration areas according to the control group subsystems and are used to store the resource configuration information of each control group and sub-control group. The loading unit is used to load the configuration file in response to system startup and to configure resources for the lowest-level sub-control group in a bottom-up recursive manner. The first acquisition unit is used to acquire configuration request information of the target configuration file and write the configuration request information into the task table; wherein, during the configuration process, the target configuration file is locked, and after the configuration is completed, the lock is released and the configuration information is persisted to the corresponding configuration file; The loading unit is further configured to: In response to system startup, the service manager is set to start immediately after the file system is mounted. During system startup, configuration files are loaded in a bottom-up recursive manner, prioritizing the resource configurations of the lowest-level subgroups and then processing the resource configurations of the parent groups layer by layer upwards.

12. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the configuration method for the control group as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the configuration method for the control group as described in any one of claims 1 to 10.

14. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the configuration method for the control group as described in any one of claims 1 to 10.

Images