Partition system process CPU utilization rate monitoring system and control method thereof

Abstract

The invention provides a partition system process CPU utilization rate monitoring system and a control method thereof, and the system comprises a local collection module which is deployed in each partition, collects the CPU time data of all processes in the partition in real time, and calculates the CPU utilization rate of the processes; the global coordination module receives the data acquired by the local acquisition module in each partition in real time, performs data aggregation and unified storage, and does not directly participate in process monitoring in the partition; the exception detection module is used for distinguishing process exceptions, local acquisition module exceptions and data transmission exceptions according to the stored data; an isolation adaptive distributed architecture design is adopted, and a local acquisition module is set to only access CPU time data of an internal process of a partition where the local acquisition module is located; and meanwhile, a global coordination module is arranged and does not directly intervene in process scheduling in the partition, so that the damage of traditional cross-partition monitoring to an isolation boundary is avoided, and the standard requirements of core partition systems such as ARINC653 and the like are met.

Description

Technical Field

[0001] This invention relates to the technical field of CPU monitoring in partitioned systems, specifically to a system for monitoring the CPU utilization of processes in a partitioned system and its control method. Background Technology

[0002] Partitioning systems, through temporal and spatial isolation mechanisms, enable the secure coexistence of applications with different criticality levels on the same hardware platform, and are widely used in core fields such as avionics and industrial control. In these systems, the CPU, as the core computing resource, directly affects the real-time performance and reliability of applications. If a process in a partition experiences excessive CPU usage, it may breach the isolation boundary and interfere with the operation of other partitions; conversely, if a process in a partition has too low CPU utilization, it will result in resource waste.

[0003] Therefore, it is necessary to monitor the CPU utilization of processes within the partition system in real time to ensure that the CPU utilization of processes within the partition system operates at maximum efficiency.

[0004] Existing CPU monitoring tools (such as top and sar) have significant limitations, mainly in the following aspects: 1) The sampling period is relatively long (the default sampling period is usually more than 1 second), making it difficult to capture millisecond-level CPU spikes of processes in the partition system, which can easily lead to monitoring distortion. 2) Lack of adaptation to partition isolation characteristics; cross-partition monitoring is prone to destroying spatial isolation boundaries and violating the requirements of partition system standards such as ARINC653. 3) High-frequency sampling results in excessive system overhead, and the frequent switching between user mode and kernel mode introduces additional performance interference, affecting the real-time performance of partitioned applications.

[0005] 4) In addition, existing partition monitoring solutions mostly focus on the overall status of service components and lack the ability to finely monitor process-level CPU utilization.

[0006] Therefore, there is an urgent need for a process CPU utilization monitoring method that balances isolation, high accuracy, and low overhead, so as to achieve accurate perception and early warning of anomalies in the running status of processes within a partition. Summary of the Invention

[0007] To address the deficiencies and shortcomings of the existing technologies, this invention provides a system for monitoring CPU utilization of partitioned system processes and its control method.

[0008] The specific solution provided by this invention is as follows: A system for monitoring CPU usage of processes in a partitioned system, characterized in that: the system comprises: The local acquisition module is deployed within each partition. It collects CPU time data of all processes within the partition in real time and calculates the CPU utilization of the processes. A global coordination module is deployed in the middle layer and connects to each partition and its internal local acquisition module. The global coordination module receives data collected in real time by the local acquisition module within each partition, performs data aggregation and unified storage, and does not directly participate in the process monitoring within the partition. An anomaly detection module is connected to the global coordination module to distinguish between process anomalies, local acquisition module anomalies, and data transmission anomalies based on the comparison between the actual process CPU usage and a preset threshold.

[0009] As a further preferred embodiment of the present invention, the partitioning system includes a three-layer architecture consisting of a bottom layer, a middle layer, and a top layer: The underlying layer includes a hardware platform, which is connected to the middle layer via data. The hardware platform includes at least a multi-core CPU and memory corresponding to each partition. The intermediate layer includes a partition management module. The intermediate layer is connected to the top layer to achieve time and space isolation between partitions. At the same time, it allocates resources to each partition. The partition management module only perceives the overall CPU status within each partition and does not directly interfere with process scheduling within the partition. The top layer includes multiple independent partitions, each containing its own operating environment and application processes, and each partition manages its own process scheduling.

[0010] As a further preferred embodiment of the present invention, the local acquisition module adopts a hybrid acquisition strategy of event tracking and supplementary sampling to collect CPU time data of all processes within the partition in real time.

[0011] As a further preferred embodiment of the present invention, the event tracking and collection strategy includes: mounting a preset program in the partition kernel to process switching and scheduler execution events; when a process switching event or scheduler execution event occurs, recording the process identifier, CPU core number and event timestamp of the current process, and calculating the runtime of the process on the current CPU core.

[0012] As a further preferred embodiment of the present invention, the supplementary sampling acquisition strategy includes: for hardware-level events, performing supplementary sampling of the CPU according to a preset period, and simultaneously acquiring CPU time data occupied by processes in the hardware-level events.

[0013] As a further preferred embodiment of the present invention, the local acquisition module calculates the process CPU utilization according to the following formula: CPU utilization = (CPU time used by the process / sampling period) × 100%; and where, The CPU time occupied by a process includes user-mode runtime and kernel-mode runtime.

[0014] As a further preferred embodiment of the present invention, the sampling period can be adjusted according to the CPU utilization rate: When the CPU utilization rate exceeds 80% or the standard deviation of fluctuation is greater than 3 times the mean, the sampling period is automatically adjusted to 10ms; When the CPU utilization rate is detected to be less than 80% and the standard deviation of the fluctuation is less than 3 times the mean, the sampling period is automatically adjusted to 100ms.

[0015] As a further preferred embodiment of the present invention, when the global coordination module receives data collected in real time by the local acquisition module within each partition, it ensures data integrity through verification, discards damaged data, and notifies the corresponding partition to resend the data.

[0016] As a further preferred embodiment of the present invention, when the global coordination module receives data for aggregation and unified storage, it aggregates and stores the process CPU utilization data of each partition into a circular buffer according to the timestamp, and writes the CPU time data just sampled into persistent storage and retains it for a preset time for subsequent analysis.

[0017] Furthermore, the present invention also provides a control method for a partitioned system process CPU utilization monitoring system, characterized by comprising the following steps: S100: The local acquisition module collects CPU time data of all processes within the partition in real time and calculates the CPU utilization of the processes. S200: The global coordination module receives data collected in real time by the local acquisition modules within each partition, and performs data aggregation and unified storage. S300: The anomaly detection module distinguishes between process anomalies, local acquisition module anomalies, and data transmission anomalies based on stored data.

[0018] Compared with existing technologies, the technical effects that this invention can achieve include: 1) This invention provides a partitioned system process CPU utilization monitoring system and its control method. It adopts an isolation-adaptive distributed architecture design, and sets the local acquisition module to only access the CPU time data of processes within its own partition and not to obtain data across partitions. At the same time, it sets the global coordination module to not directly interfere with the process scheduling within the partition, thereby avoiding the destruction of isolation boundaries by traditional cross-partition monitoring from the root, and meeting the requirements of core partitioned system standards such as ARINC653.

[0019] 2) This invention provides a system and control method for monitoring the CPU utilization of processes in a partitioned system. It employs a high-precision, low-overhead hybrid acquisition strategy, using a combination of event tracing and supplementary sampling to collect CPU time data of all processes within the partition in real time. On one hand, the event tracing sampling strategy accurately captures process event timestamps and runtime, achieving non-intrusive acquisition without modifying the kernel source code. On the other hand, the supplementary sampling strategy samples CPU time data from hardware-level events, covering fine-grained hardware metrics that are difficult for the event tracing sampling strategy to reach, reducing sampling overhead while ensuring the accuracy and comprehensiveness of data acquisition.

[0020] 3) This invention provides a partitioned system process CPU utilization monitoring system and its control method. It also sets a dynamic adjustment mechanism for the sampling period, so that the sampling period can be adjusted according to the CPU utilization. In normal scenarios, a sampling period of 100ms is used to balance overhead and accuracy, while in high-load / high-fluctuation scenarios, it automatically switches to 10ms to achieve high-frequency sampling. This not only accurately captures millisecond-level CPU spikes (error ≤1%), but also controls the CPU overhead of the local acquisition module itself to within 1%, avoiding interference that affects the real-time performance of the monitoring application.

[0021] 4) This invention provides a partitioned system process CPU utilization monitoring system and its control method, which can achieve millisecond-level fine-grained sampling, accurately capture instantaneous fluctuations in process CPU utilization, and realize refined monitoring capabilities for process-level CPU utilization.

[0022] 5) This invention provides a system for monitoring the CPU usage of a partitioned system process and its control method. By setting up an anomaly detection module, it can distinguish between process anomalies, local acquisition module anomalies, and data transmission anomalies based on stored data, and can effectively realize anomaly detection and fault location. Attached Figure Description

[0023] Figure 1 The diagram shown is a logical structure diagram of the system provided by the present invention.

[0024] Figure 2 The diagram shown is a flowchart of the steps of the method provided by the present invention. Detailed Implementation

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

[0026] In the description of this invention, it should be noted that the terms "upper," "lower," "inner," "outer," "front end," "rear end," "both ends," "one end," and "the other end," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0027] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installed," "equipped with," "connected," etc., should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium; it can be a connection within two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0028] [First Embodiment] like Figure 1 As shown, the first embodiment of the present invention provides a system for monitoring the CPU usage of partitioned system processes. In this embodiment, the partitioning system includes a three-layer architecture: a bottom layer, a middle layer, and a top layer. The underlying layer includes a hardware platform, and the underlying layer is connected to the middle layer for data connection. The hardware platform includes at least a multi-core CPU and memory corresponding to each partition. The middle layer includes a partition management module, such as a virtual machine monitoring program like Hypervisor. The middle layer connects with the top layer to achieve time and space isolation between partitions, and allocates resources to each partition, such as CPU resources or vCPU (virtual CPU) resources. The partition management module only perceives the overall CPU status within each partition and does not directly interfere with process scheduling within the partition. The top layer consists of multiple independent partitions, each containing its own runtime environment and application processes, and each partition manages its own process scheduling.

[0029] The improvement made in this embodiment compared to the prior art is that the monitoring system provided in this embodiment includes: The local acquisition module is deployed within each partition. It collects CPU time data of all processes within the partition in real time and calculates the CPU utilization of the processes. In this embodiment, the local acquisition module uses a hybrid acquisition strategy of event tracking and supplementary sampling to collect CPU time data of all processes within the partition in real time.

[0030] The event tracking and collection strategy includes: mounting preset programs to process switching and scheduler execution events in the partitioned kernel; when a process switching event or scheduler execution event occurs, recording the process identifier, CPU core number, and event timestamp of the current process, and calculating the runtime of the process on the current CPU core.

[0031] Event tracing and collection strategies can be implemented using the compiler's weak symbol feature. This feature allows programs with the same name to be executed safely in kernel space. They can be mounted to system events without modifying the kernel source code, achieving non-intrusive data collection and effectively reducing the overhead of switching between user mode and kernel mode.

[0032] The specific operation process is as follows: The weak program is mounted in the partition kernel to the sched:process_switch (process switching) and sched:schedule (scheduler execution) events. When a process switching event or a scheduler execution event occurs, the PID, CPU core number and event timestamp of the current process are recorded, and the runtime of the process on the current CPU core is calculated.

[0033] The supplementary sampling strategy includes: for hardware-level events, supplementary sampling of the CPU is performed according to a preset period, and at the same time, the CPU time occupied by the process in the hardware-level event is obtained.

[0034] Supplementary sampling strategies can be implemented using the Perf tool, which can access the hardware performance monitoring unit (PMU) and supports sampling based on hardware-level events, such as sampling once every 1000 CPU cycles, thus avoiding the redundant overhead caused by polling at fixed sampling intervals.

[0035] This embodiment combines the advantages of both approaches to achieve high-precision, low-overhead CPU time data acquisition. It employs a hybrid acquisition strategy combining event tracing and supplementary sampling to collect CPU time data for all processes within the partition in real time. On one hand, the event tracing sampling strategy accurately captures process event timestamps and runtime, enabling non-intrusive acquisition without modifying the kernel source code. On the other hand, the supplementary sampling strategy samples CPU time data from hardware-level events, covering fine-grained hardware metrics that are difficult for the event tracing sampling strategy to reach, reducing sampling overhead while ensuring the accuracy and comprehensiveness of the data acquisition.

[0036] In this embodiment, when the local acquisition module calculates the process CPU utilization, the CPU utilization is defined as the percentage of CPU time occupied by a process per unit of time, and the process CPU utilization is calculated according to the following formula: CPU utilization = (CPU time used by the process / sampling period) × 100%; and where, The CPU time occupied by a process includes user-mode runtime and kernel-mode runtime.

[0037] Traditional calculation methods rely on periodic readings of system files such as / proc / stat, while this embodiment uses event-driven sampling to obtain more accurate time data by capturing process scheduling events (such as process_switch).

[0038] Preferably, the sampling period in this embodiment can be adjusted according to the CPU utilization rate: When CPU utilization exceeds 80% or the standard deviation of fluctuation is greater than 3 times the mean, the sampling period is automatically adjusted to 10ms. When the CPU utilization rate is detected to be less than 80% and the standard deviation of the fluctuation is less than 3 times the mean, the sampling period is automatically adjusted to 100ms.

[0039] By setting a dynamic adjustment mechanism for the sampling period, the sampling period can be adjusted according to the CPU utilization. In normal scenarios, a sampling period of 100ms is used to balance overhead and accuracy, while in high-load / high-fluctuation scenarios, it automatically switches to 10ms to achieve high-frequency sampling. This accurately captures millisecond-level CPU spikes (error ≤1%) while keeping the CPU overhead of the local acquisition module itself within 1%, avoiding interference that could affect the real-time performance of the monitoring application.

[0040] like Figure 1 As shown, the monitoring system provided in this embodiment also includes a global coordination module. The global coordination module is deployed in the middle layer and connects with each partition and its internal local acquisition module. The global coordination module receives the data collected in real time by the local acquisition module within each partition, performs data aggregation and unified storage, and does not directly participate in the process monitoring within the partition. When the global coordination module receives data collected in real time by the local acquisition modules within each partition, it verifies the data to ensure its integrity, discards corrupted data, and notifies the corresponding partition to resend the data.

[0041] When the global coordination module receives and performs data aggregation and unified storage, it aggregates and stores the process CPU utilization data of each partition according to the timestamp into the ring buffer to reduce memory copy overhead. At the same time, it writes the CPU time data that has just been sampled into persistent storage and retains it for a preset time for subsequent analysis. For example, it can write the fine-grained CPU time data of 1 second that has just been sampled into persistent storage and retain it for 7 days for subsequent analysis.

[0042] This embodiment adopts an isolation-adaptive distributed architecture design, setting the local acquisition module to only access the CPU time data of processes within its own partition and not to acquire data across partitions; at the same time, the global coordination module is set not to directly interfere with the process scheduling within the partition, fundamentally avoiding the destruction of isolation boundaries by traditional cross-partition monitoring, and meeting the requirements of core partition system standards such as ARINC653.

[0043] like Figure 1 As shown, the monitoring system provided in this embodiment is also equipped with an anomaly detection module. The anomaly detection module is connected to the global coordination module to distinguish between process anomalies, local acquisition module anomalies, and data transmission anomalies based on the comparison results of the actual process CPU utilization and the preset threshold.

[0044] In one preferred embodiment, preset thresholds can be set in advance for process anomalies, local acquisition module anomalies, and data transmission anomalies. For example, these can be process judgment thresholds, module judgment thresholds, and transmission judgment thresholds, respectively. The actual process CPU utilization is then compared with the process judgment threshold, module judgment threshold, and transmission judgment threshold in sequence. When the actual process CPU utilization does not exceed the process judgment threshold, module judgment threshold, and transmission judgment threshold, the anomaly detection module determines that there is no anomaly at present. When the actual CPU usage of a process exceeds the process judgment threshold, the anomaly detection module determines that the current process is abnormal. When the actual process CPU usage exceeds the module's judgment threshold, the anomaly detection module determines that the current local acquisition module is abnormal; When the actual process CPU utilization exceeds the transmission judgment threshold, the anomaly detection module determines that there is an anomaly in the current data transmission. When the anomaly detection module determines that an anomaly exists, it can put the abnormal process, module, or data into hibernation control and issue corresponding anomaly prompts and alarm messages to remind the user.

[0045] [Application Examples] An experimental platform for a multi-core partitioned system based on Matrix653 was built. The hardware configuration was Phytium E2000 (4 cores) and 2GB of memory. Each partition ran the ARINC653 process and deployed three types of typical applications: periodic tasks (10ms cycle), computationally intensive tasks (floating operations), and I / O intensive tasks (file read and write).

[0046] The performance differences between the monitoring system in this embodiment and the weak method of the traditional top tool with a fixed 10ms sampling were compared. The evaluation metrics included: monitoring accuracy and system overhead.

[0047] Monitoring accuracy verification: By injecting a 100ms instantaneous spike with 100% CPU utilization, the capture capabilities of different methods were tested: the traditional top tool (1s sampling) failed to capture the spike and reported a utilization rate of 10%; the fixed 10ms weak method successfully captured the spike, but with a 5% error; while the monitoring system in this embodiment dynamically switched to a 10ms sampling period and accurately captured the spike with an error controlled within 1%, verifying its high accuracy advantage.

[0048] System overhead verification: When the system is running at full load (overall CPU utilization of 90%), the CPU overhead of each method is tested: the overhead of the traditional top tool is 2.3%, the overhead of the fixed 10ms weak method is 1.8%, and the average overhead of the dynamic sampling strategy of the monitoring system in this embodiment is 0.7%, which is lower than the target threshold of 1%, proving its low overhead characteristics and that it will not affect the real-time performance of the monitored application.

[0049] [Second Embodiment] The second embodiment of the present invention also provides a control method for a partitioned system process CPU utilization monitoring system, comprising the following steps: S100: The local acquisition module collects CPU time data of all processes within the partition in real time and calculates the CPU utilization of the processes. S200: The global coordination module receives data collected in real time by the local acquisition modules within each partition, and performs data aggregation and unified storage. S300: The anomaly detection module distinguishes between process anomalies, local acquisition module anomalies, and data transmission anomalies based on stored data.

[0050] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A zoned system process CPU usage monitoring system, characterized by: The system includes: The local acquisition module is deployed within each partition. It collects CPU time data of all processes within the partition in real time and calculates the CPU utilization of the processes. A global coordination module is deployed in the middle layer and connects to each partition and its internal local acquisition module. The global coordination module receives data collected in real time by the local acquisition module within each partition, performs data aggregation and unified storage, and does not directly participate in the process monitoring within the partition. An anomaly detection module is connected to the global coordination module to distinguish between process anomalies, local acquisition module anomalies, and data transmission anomalies based on the comparison between the actual process CPU usage and a preset threshold.

2. The system of claim 1, wherein: The partitioning system comprises a three-tier architecture: a bottom layer, a middle layer, and a top layer. The underlying layer includes a hardware platform, which is connected to the middle layer via data. The hardware platform includes at least a multi-core CPU and memory corresponding to each partition. The intermediate layer includes a partition management module. The intermediate layer is connected to the top layer to achieve time and space isolation between partitions. At the same time, it allocates resources to each partition. The partition management module only perceives the overall CPU status within each partition and does not directly interfere with process scheduling within the partition. The top layer includes multiple independent partitions, each containing its own operating environment and application processes, and each partition manages its own process scheduling.

3. The system of claim 1, wherein: The local acquisition module uses a hybrid acquisition strategy of event tracking and supplementary sampling to collect CPU time data of all processes within the partition in real time.

4. The system of claim 3, wherein: The event tracking and collection strategy includes: mounting a preset program in the partition kernel to process switching and scheduler execution events; when a process switching event or scheduler execution event occurs, recording the process identifier, CPU core number and event timestamp of the current process, and calculating the runtime of the process on the current CPU core.

5. The system of claim 4, wherein: The supplementary sampling strategy includes: for hardware-level events, performing supplementary sampling of the CPU according to a preset period, and simultaneously acquiring CPU time data occupied by processes in the hardware-level events.

6. The CPU utilization monitoring system for a partitioned system process according to claim 5, characterized in that: The local acquisition module calculates the process CPU utilization using the following formula: CPU utilization = (CPU time used by the process / sampling period) × 100%; and where, The CPU time occupied by a process includes user-mode runtime and kernel-mode runtime.

7. A partitioned system process CPU utilization monitoring system according to claim 6, characterized in that: The sampling period can be adjusted according to the CPU utilization rate: When the CPU utilization rate exceeds 80% or the standard deviation of fluctuation is greater than 3 times the mean, the sampling period is automatically adjusted to 10ms; When the CPU utilization rate is detected to be less than 80% and the standard deviation of the fluctuation is less than 3 times the mean, the sampling period is automatically adjusted to 100ms.

8. The CPU utilization monitoring system for a partitioned system process according to claim 1, characterized in that: When the global coordination module receives data collected in real time by the local acquisition module within each partition, it verifies the data to ensure its integrity, discards damaged data, and notifies the corresponding partition to resend the data.

9. A partitioned system process CPU utilization monitoring system according to claim 8, characterized in that: When the global coordination module receives data for aggregation and unified storage, it aggregates and stores the process CPU utilization data of each partition into a circular buffer according to the timestamp. At the same time, it writes the CPU time data that has just been sampled into persistent storage and retains it for a preset time for subsequent analysis.

10. A control method for a partitioned system process CPU utilization monitoring system according to any one of claims 1-9, characterized in that: Includes the following steps: S100: The local acquisition module collects CPU time data of all processes within the partition in real time and calculates the CPU utilization of the processes. S200: The global coordination module receives data collected in real time by the local acquisition modules within each partition, and performs data aggregation and unified storage. S300: The anomaly detection module distinguishes between process anomalies, local acquisition module anomalies, and data transmission anomalies based on stored data.

Images