An arithmetic electricity and refrigeration integrated operation method and system

Abstract

This invention relates to the field of computing power scheduling technology, and more particularly to an integrated computing, power, and cooling operation and maintenance method and system. The method includes: responding to power grid scheduling commands, identifying non-urgent computing tasks and obtaining the cooling status parameters of their respective nodes; defining an interruptible transaction contract for the task and configuring a double-buffered state storage area; when receiving an interruption or migration command, pausing the task at an interruptible point, generating a lightweight causal log and solidifying the confirmed state, while simultaneously reducing the cooling output of the current node; migrating the task to a target node and sending historical heat generation data and required cooling capacity parameters; when resuming the task, repairing only uncommitted write operations based on the log, and increasing the cooling capacity of the target node before repair; resuming task execution after the cooling capacity meets the heat dissipation requirements. This invention, through the coordinated scheduling of computing power and cooling, achieves interruptible task migration and pre-allocation of cooling capacity in response to power grid commands, reducing the integrated operation and maintenance costs of computing, power, and cooling.

Description

Technical Field

[0001] This invention relates to the field of computing power scheduling technology, and in particular to an integrated operation and maintenance method and system for computing, power, and cooling. Background Technology

[0002] In traditional data centers, computing task scheduling, power resource management, and cooling system control operate independently. The computing task scheduler only focuses on task execution efficiency and service quality. The power management unit passively responds to grid commands, often using direct power rationing, which affects business continuity. The cooling system, controlled independently based on preset temperature thresholds, is difficult to dynamically match with the computing load. When the grid issues peak shaving or load reduction commands, existing technologies lack the means to coordinate and optimize computing power reduction, power release, and cooling regulation. This results in either sacrificing the integrity of computing tasks, causing data loss and recalculation costs, or the cooling system continuing to operate at full power, generating ineffective energy consumption. It is impossible to achieve safe task interruption and on-demand allocation of cooling capacity in response to grid commands.

[0003] Chinese Patent Publication No. CN120873882A discloses a data center construction and intelligent operation and maintenance management system, including a dynamic environment perception module, a heterogeneous device protocol adaptation module, a multi-dimensional resource dynamic scheduling module, a latent fault prediction module, and an energy efficiency optimization execution module. It constructs an environmental feature matrix by deploying multi-modal sensors to collect physical environment data such as temperature gradient, current harmonic components, and fiber strain rate; it uses a semantic slot transfer algorithm to achieve standard semantic mapping of heterogeneous protocols; it establishes and dynamically updates a resource topology map based on a hypergraph neural network; it uses a dual-channel spatiotemporal convolutional network to achieve fault prediction; and it combines a fault probability matrix to generate dynamic optimization strategies for cooling, power, and network dimensions, forming a closed-loop optimization control. This invention achieves integrated collaboration of multi-source information fusion, intelligent equipment control, and adaptive energy efficiency optimization, improving the intelligence, reliability, and energy efficiency of data center operation and maintenance.

[0004] However, existing technologies still have the following problems:

[0005] The problem of coordinated control between computing tasks and cooling systems under power grid command response has not been solved, and there is a lack of collaborative mechanisms for interruptible task migration and pre-allocation of cooling capacity. Summary of the Invention

[0006] To address this, the present invention provides an integrated operation and maintenance method and system for computing, power, and cooling systems, which overcomes the problems in the prior art of failing to solve the problem of linkage control between computing tasks and cooling systems under power grid command response, and lacking a collaborative mechanism for interruptible task migration and pre-allocation of cooling capacity.

[0007] To achieve the above objectives, the present invention provides an integrated operation and maintenance method for computing, power supply, and cooling systems, comprising:

[0008] Step S1: In response to the power grid dispatching command, identify non-emergency computing tasks from the computing task cluster and obtain the cooling status parameters of the computing node where the non-emergency computing task is currently located.

[0009] Step S2: Define an interruptible transaction contract for the non-urgent computing task and configure a double-buffered state storage area, while recording the predicted heat generation and actual heat generation generated by executing the non-urgent computing task.

[0010] Step S3: When the non-urgent computing task receives an interruption instruction or migration instruction, the non-urgent computing task is suspended at the interruptible point specified by the interruptible transaction contract, a lightweight causal log is generated, the confirmed state is solidified, and the cooling output of the computing node where the non-urgent computing task is currently located is reduced according to the predicted heat generation and the actual heat generation.

[0011] Step S4: Migrate the contents of the paused non-emergency computing task and its double-buffered state storage area to the target computing node, and send the historical heat generation data and required cooling capacity parameters corresponding to the non-emergency computing task to the target computing node.

[0012] Step S5: When restoring the non-urgent computing task on the target computing node, based on the confirmed status and the lightweight causal log, only the uncommitted subset of write operations are repaired, and before the repair, the cooling capacity of the target computing node is increased based on the historical heat generation data and the required cooling capacity parameters.

[0013] Step S6: After the repair is completed, when the cooling capacity of the target computing node meets the heat dissipation requirements of the non-urgent computing task after it is restored, the execution of the non-urgent computing task is resumed.

[0014] Further, in step S1, non-urgent computing tasks are identified from the computing task cluster, including:

[0015] Step S11: Obtain the current computing resource utilization rate, predicted remaining execution time, and cooling redundancy of the current computing node for each computing task in the computing task cluster.

[0016] Step S12: Calculate the total amount of computing resources to be released for computing tasks that need to be suspended or migrated, based on the load reduction required by the power grid dispatching instruction.

[0017] Step S13: Determine the interruption urgency of each computing task based on the current computing resource utilization rate, predicted remaining execution time, and cooling redundancy of the node where it is located.

[0018] Step S14: Determine non-urgent computing tasks from the computing task cluster based on the interruption urgency.

[0019] Further, in step S2, an interruptible transaction contract is defined for the non-urgent computing task, including:

[0020] Step S211: Identify all write operations in the non-urgent computing task, and divide the write operations into multiple atomic submission units according to the predicted heat generation, wherein each atomic submission unit corresponds to a predicted heat generation increment interval.

[0021] Step S212: Insert checkpoint markers at the start and end positions of each atomic submission unit;

[0022] Step S213: Record the location information of each checkpoint mark and the predicted heat increment value corresponding to each atomic submission unit into the contract metadata as the interruptible transaction contract.

[0023] Further, in step S2, a double-buffered state storage area is configured for the non-urgent computing task, including:

[0024] Step S221: Allocate a first buffer and a second buffer in memory for the non-urgent computing task, wherein the first buffer and the second buffer have the same storage structure;

[0025] Step S222: Set the first buffer as an active buffer to receive and store intermediate state data generated during the execution of the non-urgent computing task;

[0026] Step S223: Set the second buffer as a spare buffer to keep it idle when the first buffer is written to.

[0027] Further, in step S3, a lightweight causal log is generated, including:

[0028] Step S31: Record the position number of the last checkpoint marker when the non-urgent computing task is paused;

[0029] Step S32: Capture all write operations that the non-urgent computing task has not yet committed at the pause time, and record the last write timestamp of the data block read by each write operation;

[0030] Step S33: Arrange the uncommitted write operations into a write operation sequence according to their execution order, and mark the sequence number of the previous write operation that each write operation depends on.

[0031] Step S34: The location number of the last checkpoint, the sequence of write operations, and the sequence number of the previous write operation that each write operation depends on are encapsulated together into the lightweight causal log.

[0032] Further, in step S3, reducing the cooling output of the computing node where the non-urgent computing task is currently located includes:

[0033] Based on the difference between the predicted heat generation and the actual heat generation, calculate the redundant heat value released after the non-urgent computing task is paused;

[0034] Based on the redundant heat value and the cooling status parameters of the current computing node, determine the reduction in cooling output.

[0035] The cooling output is reduced according to the stated reduction amount.

[0036] Furthermore, in step S5, the subset of uncommitted write operations is repaired, including:

[0037] Step S51: Parse the position number of the last checkpoint marker, the sequence of write operations, and the sequence number of the previous write operation that each write operation depends on from the lightweight causal log.

[0038] Step S52: Determine the recovery starting point of the non-urgent computing task based on the location number of the last checkpoint marker;

[0039] Step S53: Starting from the recovery starting point, traverse the sequence of write operations, and according to the sequence number of the previous write operations that each write operation depends on, re-execute only the write operations that have not yet been committed and whose dependent previous write operations have all been completed.

[0040] Furthermore, in step S5, increasing the cooling capacity of the target computing node includes:

[0041] Extract the average and peak calorific values ​​of the non-emergency computing task before it was paused from the historical calorific data;

[0042] Obtain the predicted cooling power required after the non-urgent computing task resumes from the required cooling capacity parameters;

[0043] The target increment of cooling capacity is determined based on the peak heat output, the predicted cooling power, and the current cooling status of the target computing node.

[0044] Increase the cooling capacity according to the stated target increment.

[0045] Furthermore, the target increment for cooling capacity is determined, including:

[0046] The larger of the peak heat generation and the predicted cooling power is taken as the required cooling capacity.

[0047] Based on the current cooling status of the target computing node, obtain its inlet air temperature, current cooling power, cooling redundancy, and available cooling capacity.

[0048] When the inlet air temperature is higher than the preset temperature threshold or the cooling redundancy is lower than the preset redundancy threshold, the available cooling capacity is multiplied by a discount factor to obtain the adjusted available cooling capacity.

[0049] Calculate the difference between the required cooling capacity and the adjusted available cooling capacity, and use the difference as the target increment of the cooling capacity.

[0050] A system applied to the integrated operation and maintenance method of computing, power supply and cooling includes:

[0051] The task identification module is used to identify non-urgent computing tasks from the computing task cluster in response to power grid dispatch instructions, and to obtain the cooling status parameters of the computing node where the non-urgent computing task is currently located.

[0052] The contract management module is used to define interruptible transaction contracts for the non-urgent computing tasks and configure a double-buffered state storage area, while recording the predicted heat generation and actual heat generation generated by executing the non-urgent computing tasks.

[0053] The task pause module is used to pause the non-urgent computing task at the interruptible point specified by the interruptible transaction contract when the non-urgent computing task receives an interruption instruction or migration instruction, generate a lightweight causal log, solidify the confirmed state, and reduce the cooling output of the computing node where the non-urgent computing task is currently located based on the predicted heat generation and the actual heat generation.

[0054] The task migration module is used to migrate the paused non-urgent computing tasks and the contents of their double-buffered state storage areas to the target computing node, and to send the historical heat generation data and required cooling capacity parameters corresponding to the non-urgent computing tasks to the target computing node.

[0055] The task repair module is used to repair only the subset of uncommitted write operations when restoring the non-urgent computing task on the target computing node, based on the confirmed status and the lightweight causal log. Before repair, the cooling capacity of the target computing node is increased based on the historical heat generation data and the required cooling capacity parameters.

[0056] The task recovery module is used to resume the execution of the non-urgent computing task after the repair is completed, when the cooling capacity of the target computing node meets the heat dissipation requirements of the non-urgent computing task after recovery.

[0057] Compared with the prior art, the beneficial effects of the present invention are that it calculates the interruption urgency by comprehensively calculating the task resource occupancy rate, remaining execution time and node cooling redundancy. This enables the identified non-urgent computing tasks to not only efficiently release computing resources to meet the grid load reduction command requirements, but also to prioritize interrupting or migrating tasks located on nodes with insufficient cooling capacity. This relieves the cooling pressure in hotspot areas while responding to grid dispatch, and achieves the synergistic benefits of computing power offloading and cooling power optimization.

[0058] Furthermore, this invention divides the write operations of a task into atomic commit units based on the predicted heat generation increment and inserts checkpoint markers through an interruptible transaction contract, ensuring that the atomicity of the transaction is not compromised when the task is paused at any interruptible point, thus avoiding data inconsistency. At the same time, through the role-swapping mechanism between the active and standby buffers in the dual-buffered state storage area, it achieves non-blocking solidification and fast snapshot of the intermediate state of the task, so that the task can immediately enter the migration process without waiting for the data to be written to disk after being paused. Under the premise of ensuring the consistency of task data, it significantly shortens the response latency from task interruption to migration start, providing a low-latency state preservation foundation for the subsequent collaborative scheduling of computing power and cooling power.

[0059] Furthermore, this invention records the last checkpoint marker position, the sequence of uncommitted write operations, and the dependency sequence numbers between operations using a lightweight causal log. This ensures that only the minimum necessary set of write operations needs to be redone during task recovery, avoiding the computational and energy consumption overhead caused by full recalculation. Simultaneously, it determines the redundant heat value by calculating the difference between the predicted heat generation and the measured heat generation, and dynamically determines the reduction range of cooling output by combining the cooling redundancy and inlet air temperature in the cooling status parameters. It also automatically reverts to normal operation when the temperature is abnormal, achieving precise reduction of cooling output and safety protection after the task is paused. Under the response of power grid commands, this invention not only ensures the efficiency of task recovery but also reduces the ineffective power consumption of the cooling system, thereby reducing the overall operation and maintenance costs of computing, power, and cooling systems.

[0060] Furthermore, this invention utilizes a lightweight causal log and incremental repair mechanism, enabling task recovery to only re-execute write operations that have not yet been committed and whose dependent conditions are met. Combined with data block timestamp verification, it ensures cross-task data consistency, avoiding the computational and energy overhead of full recalculation. Simultaneously, it determines the required cooling capacity by jointly determining peak heat generation and predicted cooling power, dynamically adjusting available cooling capacity based on target node inlet air temperature and cooling redundancy, calculating the target incremental cooling capacity, and increasing cooling capacity in advance before repair, ensuring that cooling capacity is in place when the task resumes. These two aspects work together to ensure data consistency and execution efficiency during task recovery under grid command response, while also achieving on-demand pre-allocation and precise supply of cooling capacity, effectively reducing the overall operation and maintenance costs of computing, power, and cooling systems. Attached Figure Description

[0061] Figure 1 This is a flowchart of the integrated operation and maintenance method for computing, power supply and cooling in this embodiment;

[0062] Figure 2 This is a flowchart illustrating the identification of non-urgent computing tasks in the integrated operation and maintenance method for computing, power, and cooling in this embodiment.

[0063] Figure 3 This is a schematic diagram of the integrated operation and maintenance system for computing, power, and cooling in this embodiment. Detailed Implementation

[0064] To make the objectives and advantages of the present invention clearer, the present invention will be further described below with reference to embodiments; it should be understood that the specific embodiments described herein are merely for explaining the present invention and are not intended to limit the present invention.

[0065] Preferred embodiments of the present invention will now be described with reference to the accompanying drawings. Those skilled in the art should understand that these embodiments are merely illustrative of the technical principles of the present invention and are not intended to limit the scope of protection of the present invention.

[0066] Please see Figures 1-2 As shown, Figure 1 This is a flowchart of the integrated operation and maintenance method for computing, power supply and cooling in this embodiment; Figure 2 This is a flowchart illustrating the identification of non-urgent computing tasks in the integrated operation and maintenance method for computing, power, and cooling in this embodiment.

[0067] This embodiment provides an integrated operation and maintenance method for computing, power supply, and cooling systems, including:

[0068] Step S1: In response to the power grid dispatching command, identify non-emergency computing tasks from the computing task cluster and obtain the cooling status parameters of the computing node where the non-emergency computing task is currently located.

[0069] Step S2: Define an interruptible transaction contract for the non-urgent computing task and configure a double-buffered state storage area, while recording the predicted heat generation and actual heat generation generated by executing the non-urgent computing task.

[0070] Step S3: When the non-urgent computing task receives an interruption instruction or migration instruction, the non-urgent computing task is suspended at the interruptible point specified by the interruptible transaction contract, a lightweight causal log is generated, the confirmed state is solidified, and the cooling output of the computing node where the non-urgent computing task is currently located is reduced according to the predicted heat generation and the actual heat generation.

[0071] Step S4: Migrate the contents of the paused non-emergency computing task and its double-buffered state storage area to the target computing node, and send the historical heat generation data and required cooling capacity parameters corresponding to the non-emergency computing task to the target computing node.

[0072] Step S5: When restoring the non-urgent computing task on the target computing node, based on the confirmed status and the lightweight causal log, only the uncommitted subset of write operations are repaired, and before the repair, the cooling capacity of the target computing node is increased based on the historical heat generation data and the required cooling capacity parameters.

[0073] Step S6: After the repair is completed, when the cooling capacity of the target computing node meets the heat dissipation requirements of the non-urgent computing task after it is restored, the execution of the non-urgent computing task is resumed.

[0074] In this embodiment of the invention, the cooling status parameters include, but are not limited to, the inlet air temperature, outlet air temperature, current power of the cooling equipment, cooling redundancy, refrigerant flow rate, or cooling fan speed of the current computing node. Specifically, the inlet air temperature reflects the air temperature at the node's inlet and is a fundamental indicator for determining whether the node is overheating; the difference between the outlet air temperature and the inlet air temperature reflects the heat emission intensity of the computing equipment within the node; the current power of the cooling equipment represents the electrical power consumed by the node's cooling system; the cooling redundancy represents the ratio of the node's current cooling capacity to its total cooling capacity minus the used cooling capacity, used to determine whether the node has sufficient capacity to handle additional heat loads; the refrigerant flow rate reflects the current operating intensity of the refrigerant circulation system; and the cooling fan speed reflects the current heat dissipation capacity of the air-cooled system.

[0075] The historical heat generation data includes, but is not limited to, the average heat generation, peak heat generation, rate of change of heat generation, and the mapping curve of heat generation versus computing load for non-urgent computing tasks within each time window before the pause. The average heat generation is used to assess the heat dissipation requirements during steady-state task operation; the peak heat generation is used to assess the instantaneous heat dissipation peaks that may occur during the computationally intensive phase of the task; the rate of change of heat generation is used to predict the rate of increase in heat generation after the task resumes; and the mapping curve of heat generation versus computing load is used to dynamically estimate the real-time heat generation based on the resource usage after the task resumes.

[0076] The required cooling capacity parameters include, but are not limited to, the minimum cooling power, recommended cooling power, peak cooling power, and cooling response time requirements required after the resumption of non-emergency computing tasks. The minimum cooling power represents the minimum cooling capacity required to maintain basic operation without triggering overheat protection after task resumption; the recommended cooling power represents the cooling capacity required for normal operation of the task under typical load; the peak cooling power represents the maximum cooling capacity the task may require under the highest computing load; and the cooling response time requirement represents the maximum allowable time delay from the start of task resumption to the point where the cooling capacity reaches the recommended cooling power, used to guide the timing of increasing cooling capacity in advance before repairs are performed on target nodes.

[0077] In this embodiment of the invention, before a non-urgent computing task starts, the system establishes a heat generation prediction model based on the task's historical execution data or offline performance analysis results. The predicted heat generation is calculated as follows: the task's instruction types (such as integer operations, floating-point operations, memory access, and I / O operations) are categorized, the expected execution count of each type of instruction is counted, multiplied by the unit heat generation coefficient of that type of instruction, and then summed to obtain the overall predicted heat generation of the task; or the task is divided into multiple execution stages, and the predicted heat generation of each stage is calculated based on its computational intensity, memory access frequency, and estimated execution time. The predicted heat generation is expressed in incremental form, i.e., the incremental value of the predicted heat generation corresponding to each atomic submission unit.

[0078] The actual heat generation is collected as follows: temperature sensors are deployed at the CPU chip, memory slots, or server air intake of the computing node where the task is currently located. By reading the sensor values ​​and combining them with the node's thermal resistance model, the actual heat dissipated during task execution is calculated; or, the actual heat generation generated by the task is inferred by measuring the power consumption increment of the computing node during task execution, multiplying it by a time window, and considering the heat exchange efficiency of the cooling system. The actual heat generation is collected continuously according to the time window and associated with the corresponding atomic submission unit number or checkpoint marker.

[0079] In this embodiment of the invention, the safe operating temperature lower limit T_min: calculates the lower limit of the node's inlet air temperature, which is the median of the recommended operating temperature range in the node's hardware specifications minus 20% of the range width, with a typical value of 15℃; the safe operating temperature upper limit T_max: calculates the upper limit of the node's inlet air temperature, which is the median of the recommended operating temperature range in the node's hardware specifications plus 20% of the range width, with a typical value of 35℃; the temperature rise alarm threshold: the inlet air temperature rise rate exceeds 0.5℃ / s or the cumulative rise exceeds 3℃ within 1 minute, this value is determined based on the 95th percentile of historical temperature changes of a typical air-cooled cabinet after a task pause; the preset cooling redundancy threshold R_th: the node's cooling redundancy is considered saturated when it is below 20%, this value is obtained by subtracting a 5% safety margin from the cooling system design redundancy (usually 25%); ΔQ_atom: the heat generation granularity of the atomic submission unit, which is 2% of the total predicted heat generation of the task or 1kJ (the smaller value), with adaptive adjustment based on historical instruction distribution preferred.

[0080] Specifically, in step S1, non-urgent computing tasks are identified from the computing task cluster, including:

[0081] Step S11: Obtain the current computing resource utilization rate, predicted remaining execution time, and cooling redundancy of the current computing node for each computing task in the computing task cluster.

[0082] Step S12: Calculate the total amount of computing resources to be released for computing tasks that need to be suspended or migrated, based on the load reduction required by the power grid dispatching instruction.

[0083] Step S13: Determine the interruption urgency of each computing task based on the current computing resource utilization rate, predicted remaining execution time, and cooling redundancy of the node where it is located.

[0084] Step S14: Determine non-urgent computing tasks from the computing task cluster based on the interruption urgency.

[0085] In this embodiment of the invention, the current computing resource utilization rate of each executing computing task is obtained from the scheduler of the computing task cluster, the predicted remaining execution time is read from the task configuration file, and the current cooling redundancy is obtained from the cooling management unit of the computing node where the task is located. The cooling redundancy represents the difference between the current cooling capacity and the total cooling capacity of the node and the used cooling capacity, reflecting the node's ability to withstand additional heat load. The load reduction parameter carried in the power grid dispatch instruction is parsed. This parameter represents the power value that the data center needs to reduce based on the current power consumption. According to the mapping relationship between the average power consumption of the current computing node and the computing resource utilization rate, the system converts the power value that needs to be reduced into the total amount of computing resources that need to be released, that is, the sum of the number of CPU cores, memory capacity or GPU computing power occupied by the computing tasks that need to be paused or migrated.

[0086] ;

[0087] in, It is a small positive number to prevent division by zero errors; w1, w2, w3 are dynamically adjustable weight coefficients, with initial values ​​of 0.4, 0.4, and 0.2 respectively; the higher the resource utilization rate, the shorter the remaining execution time, and the lower the cooling redundancy of the computing task, the higher its interruption urgency.

[0088] The current computing resource utilization rate, predicted remaining execution time, and cooling redundancy of the node where the task is located are weighted and fused together for each computing task. A higher current computing resource utilization rate means that releasing the task will free up more resources; a shorter predicted remaining execution time means that interrupting the task will result in less progress loss; and a lower cooling redundancy means that the node where the task is located urgently needs to reduce heat generation. The interruption urgency of each task is calculated by combining the above three factors. The higher the interruption urgency, the more priority the task should be selected for interruption or migration. All computing tasks are sorted from high to low interruption urgency, and tasks are selected one by one until the total amount of computing resources released reaches the calculated total amount of computing resources to be released. The selected computing tasks are treated as non-urgent computing tasks and enter the subsequent interruption or migration process, while the unselected computing tasks continue to execute normally.

[0089] This invention calculates the urgency of interruptions by comprehensively considering three dimensions: task resource utilization rate, remaining execution time, and node cooling redundancy. This allows identified non-urgent computing tasks to efficiently release computing resources to meet the grid load reduction command requirements, and prioritize tasks located on nodes with insufficient cooling capacity for interruption or migration. This alleviates the cooling pressure in hotspot areas while responding to grid dispatch, achieving synergistic benefits of computing power offloading and cooling optimization.

[0090] Specifically, in step S2, an interruptible transaction contract is defined for the non-urgent computing task, including:

[0091] Step S211: Identify all write operations in the non-urgent computing task, and divide the write operations into multiple atomic submission units according to the predicted heat generation, wherein each atomic submission unit corresponds to a predicted heat generation increment interval.

[0092] Step S212: Insert checkpoint markers at the start and end positions of each atomic submission unit;

[0093] Step S213: Record the location information of each checkpoint mark and the predicted heat increment value corresponding to each atomic submission unit into the contract metadata as the interruptible transaction contract.

[0094] In this embodiment of the invention, this step establishes a quantized mapping relationship between write operation sequences and predicted heat generation by constructing an "instruction-power consumption mapping table" and combining it with runtime performance counters, thereby grouping write operations according to the predicted heat generation increment. The grouping process is as follows:

[0095] First, before executing the non-urgent computing task, the system offline constructs an "instruction-power consumption mapping table" for the computing node or a reference node of the same model where the task is located. This mapping table records the average power consumption per execution of various instructions (including integer arithmetic instructions, floating-point arithmetic instructions, memory loading instructions, memory storage instructions (write operations), branch jump instructions, etc.), in joules per execution. The mapping table is constructed as follows: a set of micro-benchmark programs are run on the reference node. Each micro-benchmark program repeatedly executes a single type of instruction. The power consumption increment of the node during the execution of the instruction is measured using a high-precision power meter. Combined with the number of instruction executions and the running time, the average power consumption value P_instr for that instruction type is calculated. For write operations, the power consumption value P_write(size) is further calibrated according to the size of the data written (e.g., 1 byte, 4 bytes, 8 bytes, or consecutive multiple bytes).

[0096] Secondly, after the non-urgent computing task begins execution, the system activates a hardware performance counter or instruction sampler to perform real-time sampling and statistics on the instruction stream of the task execution. The system maintains a sliding time window (e.g., 100 milliseconds), and within each time window, it accumulates the execution counts of various instructions (especially write operations). For write operations, the corresponding P_write(size) is obtained by looking up a table based on the size of the data written, and the cumulative predicted heat generation of write operations within that time window is accumulated to obtain Q_window_write = Σ(count_write_size * P_write(size)). At the same time, the system also accumulates the heat generation of other types of instructions Q_window_other, obtaining the total predicted heat generation within that time window Q_window_total = Q_window_write + Q_window_other. Then, the system dynamically divides write operations into atomic commit units based on the global predicted heat generation of the task and the preset atomic commit unit heat generation granularity parameter ΔQ_atom (unit: joules). The value of ΔQ_atom ranges from 1% to 5% of the total predicted heat generation of the task, or can be pre-configured by the system administrator according to the response sensitivity requirements of the power grid dispatch instructions (the faster the response, the smaller the granularity). The partitioning algorithm is as follows:

[0097] Initialize an atomic commit unit, set its accumulated heat output Q_unit to zero, and clear the write operation list within that unit. Iterate through each write operation in the task according to the original execution order of the instructions. When a write operation w is encountered, look up its predicted heat output Q_w. Check if Q_unit + Q_w ≤ ΔQ_atom is true: if true, add the write operation w to the current atomic commit unit and update Q_unit = Q_unit + Q_w. If false, close the current atomic commit unit, and its corresponding predicted heat output increment interval is (accumulated Q_unit_start, Q_unit_end), where Q_unit_end = Q_unit_start + Q_unit. Then create a new atomic commit unit, making write operation w the first write operation in the new unit, and reset Q_unit = Q_w. Repeat the above process until all write operations have been traversed. The end value of the predicted heat output increment interval of the last atomic commit unit is not greater than the total predicted heat output of the task.

[0098] Based on the above division, the write operations contained in each atomic commit unit are expected to increase the cumulative heat generation of the task by a roughly fixed increment (not exceeding ΔQ_atom) after execution. The system records the start and end write operation positions of each atomic commit unit, as well as the corresponding predicted heat generation increment interval (Q_start, Q_end), in the contract metadata. Finally, to address power consumption deviations caused by differences in hardware across different computing nodes, the system collects the actual heat generation of the current computing node in real time during task execution (inferred from the onboard temperature sensor and power consumption model) and dynamically corrects the power consumption coefficient in the "instruction-power consumption mapping table". The correction method is as follows: after each atomic commit unit is executed, the ratio α = Q_actual / Q_predicted of the actual heat generation Q_actual and the predicted heat generation Q_predicted within that unit is calculated. If α deviates from 1 by more than a preset threshold (e.g., 10%), the predicted heat generation of subsequent write operations is corrected: Q_w_corrected = Q_w × α, and the corrected value is used to determine the division of subsequent atomic commit units, achieving adaptive adjustment.

[0099] In this embodiment of the invention, static code analysis or runtime bytecode instrumentation is performed on non-urgent computing tasks to identify all write operations in the task, including memory writes, database updates, file writes, and other operations that change the system state. Based on the recorded predicted heat generation of the task, the continuous sequence of write operations is divided into multiple atomic commit units according to the incremental range of the predicted heat generation. The write operations within each atomic commit unit are considered as an indivisible whole, and each atomic commit unit corresponds to a predicted heat generation incremental range. That is, after the write operations within this unit are completed, the cumulative heat generation of the task is expected to increase by a fixed step value. Checkpoint markers are inserted at the start and end positions of each atomic commit unit. The checkpoint marker includes the type of the marker, the number of the atomic commit unit to which it belongs, and the predicted value of the current cumulative heat generation. When the task reaches the start checkpoint, the system records the current state and allows subsequent write operations to begin. When the task reaches the end checkpoint, the system confirms that all write operations within the atomic commit unit have been completed and can be safely committed.

[0100] The system records the location information of each checkpoint (such as line number, instruction offset, or function entry address) and the predicted heat increment value corresponding to each atomic commit unit in the contract metadata, forming an interruptible transaction contract. This contract is stored in shared memory or a distributed coordination service. Through this contract, when a task receives an interruption instruction, it can quickly locate the starting checkpoint of the most recent incomplete atomic commit unit as the interruptible point based on the currently accumulated actual heat, ensuring that the atomicity of the transaction is not violated during pause.

[0101] Specifically, in step S2, a double-buffered state storage area is configured for the non-urgent computing task, including:

[0102] Step S221: Allocate a first buffer and a second buffer in memory for the non-urgent computing task, wherein the first buffer and the second buffer have the same storage structure;

[0103] Step S222: Set the first buffer as an active buffer to receive and store intermediate state data generated during the execution of the non-urgent computing task;

[0104] Step S223: Set the second buffer as a spare buffer to keep it idle when the first buffer is written to.

[0105] In this embodiment of the invention, when a non-urgent computing task starts, the system allocates two memory regions of the same size and with identical storage structures from the memory of the computing node, serving as a first buffer and a second buffer, respectively. The two buffers have the same field definitions and data structures, capable of completely storing intermediate state data generated during task execution, including local variable values, register snapshots, heap object references, and transaction context version numbers. The system initializes the first buffer as the active buffer, and all intermediate state data generated during task execution is written to the first buffer in real time. The active buffer maintains a current write pointer; the pointer moves forward with each written state record, ensuring that data is stored continuously in the order of its generation. Simultaneously, the active buffer records the amount of data currently written, the write timestamp, and the corresponding atomic commit unit number.

[0106] The second buffer is initialized as a standby buffer. During normal write operations to the first buffer, the standby buffer remains idle and does not participate in any data write operations. During idle periods, the standby buffer is cleared or marked as overwriteable, awaiting role swapping with the active buffer. When the task reaches the checkpoint specified by the interruptible transaction contract, the system triggers the buffer swapping mechanism: the roles of the first and second buffers are swapped; the original active buffer becomes the standby buffer and is marked as ready for migration, with its internally stored intermediate state data serving as a stable snapshot of the task state for subsequent migration; the original standby buffer becomes the new active buffer, clears its original contents, and begins receiving subsequent intermediate state data generated by the task.

[0107] This invention divides the write operations of a task into atomic commit units based on the predicted heat generation increment and inserts checkpoint markers through interruptible transaction contracts. This ensures that the atomicity of the transaction is not compromised when the task is paused at any interruptible point, thus avoiding data inconsistency. At the same time, through the role-swapping mechanism between the active and standby buffers in the dual-buffered state storage area, it achieves non-blocking solidification and fast snapshot of the task's intermediate state. This allows the task to immediately enter the migration process after being paused without waiting for data to be written to disk. While ensuring the consistency of task data, it significantly shortens the response latency from task interruption to migration startup, providing a low-latency state preservation foundation for the subsequent collaborative scheduling of computing power and cooling power.

[0108] Specifically, in step S3, a lightweight causal log is generated, including:

[0109] Step S31: Record the position number of the last checkpoint marker when the non-urgent computing task is paused;

[0110] Step S32: Capture all write operations that the non-urgent computing task has not yet committed at the pause time, and record the last write timestamp of the data block read by each write operation;

[0111] Step S33: Arrange the uncommitted write operations into a write operation sequence according to their execution order, and mark the sequence number of the previous write operation that each write operation depends on.

[0112] Step S34: The location number of the last checkpoint, the sequence of write operations, and the sequence number of the previous write operation that each write operation depends on are encapsulated together into the lightweight causal log.

[0113] In this embodiment of the invention, when a non-urgent computing task receives an interruption or migration instruction and prepares to pause, the system first reads the position the task has reached from the interruptible transaction contract and determines the position number of the last passed checkpoint. This position number corresponds to the line number or instruction offset of the last completed atomic commit unit end checkpoint in the task execution flow, and the system records this position number as the recovery start point identifier. The system scans the task's current transaction execution context and captures all write operations that have not yet been committed at the time of pause. For each uncommitted write operation, the system records the last write timestamp of the data block it reads. This timestamp is obtained from the metadata of the storage system where the data block resides and indicates the time when the data block was last modified. By recording the last write timestamp, the system can determine during recovery whether the data block being read has been modified by other tasks during the task pause, thereby deciding whether to reread it or adopt other consistency strategies.

[0114] The system arranges the captured, uncommitted write operations into a write operation sequence according to their original execution order, preserving the temporal relationship between operations. For each write operation in the sequence, the system analyzes the source of its input data to determine whether the write operation depends on the output of a previous write operation in the sequence. If write operation B needs to read the data written by write operation A as input, then write operation B is marked as dependent on write operation A, and the sequence number of the previous write operation that write operation B depends on is recorded in the log. The dependency marking uses a sequence number reference method; for example, if the 5th write operation in the write operation sequence depends on the 2nd write operation, then the dependency sequence number is marked as 2. The system encapsulates the position number of the last checkpoint mark, the complete write operation sequence, and the sequence number of the previous write operation that each write operation depends on into a data structure as a lightweight causal log. This log is stored in shared memory in a compact binary format and is associated with the contents of the buffers marked as transitionable in the double-buffered state storage area. Lightweight causal logs do not record specific data of committed write operations, nor do they record complete system state snapshots. They only record the minimum dependency information required for recovery, so the log size is small and the generation speed is fast.

[0115] Specifically, in step S3, reducing the cooling output of the computing node where the non-urgent computing task is currently located includes:

[0116] Based on the difference between the predicted heat generation and the actual heat generation, calculate the redundant heat value released after the non-urgent computing task is paused;

[0117] Based on the redundant heat value and the cooling status parameters of the current computing node, determine the reduction in cooling output.

[0118] The cooling output is reduced according to the stated reduction amount.

[0119] In this embodiment of the invention, when a non-urgent computing task is paused, the system reads the predicted cumulative heat generation and the actual cumulative heat generation of the task during the current execution phase from the task context, and calculates the difference between the predicted and actual heat generation. If the actual heat generation is lower than the predicted heat generation, the difference is positive, indicating that the task actually dissipates less heat than expected, and the redundant heat generation released after the task is paused is this difference. If the actual heat generation is higher than the predicted heat generation, the difference is negative, indicating that the task's actual heat dissipation exceeds expectations. In this case, the redundant heat generation value is set to zero to avoid excessive reduction in cooling output leading to node overheating.

[0120] The system acquires the current cooling status parameters of the computing node, including the current cooling output power, inlet air temperature, outlet air temperature, cooling redundancy, and the total heat generated by other computing tasks still running on the node. The system determines the reduction in cooling output based on the redundant heat value and the current cooling redundancy: the redundant heat value is divided by the node's current cooling output power to obtain the heat redundancy ratio; the smaller of this ratio and the cooling redundancy is used as the reduction coefficient, and the reduction is equal to the current cooling output power multiplied by this reduction coefficient. If the node's current inlet air temperature is lower than the node's preset safe operating temperature limit, the reduction coefficient is increased by a fixed increment, which is one-tenth of the current cooling redundancy; if the inlet air temperature is higher than the safe operating temperature limit, the reduction coefficient is set to zero. The safe operating temperature limits are determined by the median of the operating temperature range in the node's hardware specifications; for example, the middle third of the operating temperature range recommended in the CPU specifications is taken as the safe operating range.

[0121] The system executes a cooling output reduction operation according to a predetermined reduction range: it sends a command to the node's cooling controller to multiply the current speed of the cooling fan by (1 minus the reduction range coefficient) to obtain the target speed, or reduces the refrigerant pump flow rate and increases the set temperature of the cooling equipment by the same proportion. After executing the reduction operation, the system continuously monitors the node's inlet air temperature. If the inlet air temperature rises at a rate exceeding 0.5 degrees Celsius per second or accumulates to more than 3 degrees Celsius within one minute, the system automatically halves the reduction range until the temperature change rate stabilizes. The aforementioned temperature rise rate threshold and cumulative rise threshold are determined by the statistical upper quantile of the node's historical normal fluctuation range of inlet air temperature, with twice the upper limit of the normal fluctuation range in historical data taken as the safety threshold.

[0122] This invention records the last checkpoint marker position, the sequence of uncommitted write operations, and the dependency numbers between operations using a lightweight causal log. This allows the task to resume by redoing only the minimum necessary set of write operations, avoiding the computational and energy overhead of a full recalculation. Simultaneously, it determines the redundant heat value by calculating the difference between the predicted and measured heat generation, and dynamically determines the reduction in cooling output based on the cooling redundancy and inlet air temperature parameters in the cooling status parameters. It also automatically adjusts back to normal operation when temperatures are abnormal, achieving precise reduction in cooling output and safety protection after the task is paused. Under the response of power grid commands, this invention ensures efficient task recovery while reducing the ineffective power consumption of the cooling system, thus lowering the overall operation and maintenance costs of computing, power, and cooling systems.

[0123] In this embodiment of the invention, the following contents of the suspended non-urgent computing task are migrated to the target computing node: all contents of the current active buffer (the buffer being written to); all contents of the current standby buffer (containing the last stable snapshot); the latest write position pointers and role markers of the two buffers; when the target node recovers, the system first loads the stable snapshot in the standby buffer as the basic state of the task, and then merges and repairs the uncommitted write operations based on the incremental data in the active buffer and the lightweight causal log.

[0124] Specifically, in step S5, the subset of uncommitted write operations is repaired, including:

[0125] Step S51: Parse the position number of the last checkpoint marker, the sequence of write operations, and the sequence number of the previous write operation that each write operation depends on from the lightweight causal log.

[0126] Step S52: Determine the recovery starting point of the non-urgent computing task based on the location number of the last checkpoint marker;

[0127] Step S53: Starting from the recovery starting point, traverse the sequence of write operations, and according to the sequence number of the previous write operations that each write operation depends on, re-execute only the write operations that have not yet been committed and whose dependent previous write operations have all been completed.

[0128] In this embodiment of the invention, when a non-urgent computing task is about to resume on the target computing node, the system first reads the lightweight causal log associated with the task from shared memory or distributed storage. The log is deserialized and parsed to extract three core data points: the position number of the last checkpoint marker, the sequence of uncommitted write operations, and the sequence number of the previous write operation that each write operation depends on. Based on the parsed position number of the last checkpoint marker, the system locates the end point of the last completed atomic commit unit before the task was paused. This position number is used as the starting point for resumption; the task resumes execution from the first instruction after this position, while all committed write operations before this position are considered complete and do not need to be reprocessed.

[0129] Starting from the recovery point, the system iterates through each write operation in the original order of the write operation sequence. For the currently encountered write operation, the system checks its dependency flags: if the write operation does not depend on any previous write operations, it is directly re-executed; if the write operation depends on the sequence number of a previous write operation in the sequence, the system checks whether that previous write operation has been completed and re-executed. Only when the dependent previous write operation has been completed does the current write operation meet the execution conditions, and the system executes the write operation; if the dependent previous write operation has not yet been completed, the system skips the current write operation and continues to traverse subsequent write operations, returning to process the current write operation only after the dependent operation has been completed in subsequent traversals, or using multiple rounds of traversal until all write operations that meet the dependency conditions are re-executed.

[0130] Before re-executing each write operation, the system checks the last write timestamp of the data block being read. This timestamp is compared to the last write timestamp of the data block recorded when the task was paused: if they match, it means the data block was not modified by other tasks during the task pause, and the write operation can be performed directly using the current data block content; if they do not match, it means the data block has been updated by other tasks, and the system triggers a data consistency check process, rereading the latest version of the data block and adjusting the target value of the write operation before execution.

[0131] Specifically, in step S5, increasing the cooling capacity of the target computing node includes:

[0132] Extract the average and peak calorific values ​​of the non-emergency computing task before it was paused from the historical calorific data;

[0133] Obtain the predicted cooling power required after the non-urgent computing task resumes from the required cooling capacity parameters;

[0134] The target increment of cooling capacity is determined based on the peak heat output, the predicted cooling power, and the current cooling status of the target computing node.

[0135] Increase the cooling capacity according to the stated target increment.

[0136] Specifically, determining the target increment for cooling capacity includes:

[0137] The larger of the peak heat generation and the predicted cooling power is taken as the required cooling capacity.

[0138] Based on the current cooling status of the target computing node, obtain its inlet air temperature, current cooling power, cooling redundancy, and available cooling capacity.

[0139] When the inlet air temperature is higher than the preset temperature threshold or the cooling redundancy is lower than the preset redundancy threshold, the available cooling capacity is multiplied by a discount factor to obtain the adjusted available cooling capacity.

[0140] Calculate the difference between the required cooling capacity and the adjusted available cooling capacity, and use the difference as the target increment of the cooling capacity.

[0141] In this embodiment of the invention, before a non-urgent computing task is prepared for repair on the target computing node, the system first extracts two feature values ​​from the task's historical heat generation data: the average heat generation before the pause and the peak heat generation. The average heat generation reflects the steady-state heat dissipation requirement of the task during normal execution, while the peak heat generation reflects the maximum instantaneous heat dissipation requirement that the task may experience during computationally intensive phases. Simultaneously, the system obtains the predicted cooling power required after the task resumes from the required cooling capacity parameters. This predicted cooling power is calculated using the task's historical execution data and a predicted heat generation model. The system compares the extracted peak heat generation with the predicted cooling power and takes the larger value as the required cooling capacity. Taking the larger value ensures that the cooling capacity allocated to the target node can simultaneously cover both the task's historical maximum heat generation and the model-predicted cooling requirement, avoiding overheating of the task after resumption due to insufficient cooling.

[0142] The system sends a query request to the cooling management unit of the target computing node to obtain the node's current cooling status, including inlet air temperature, current cooling output power, cooling redundancy, and available cooling capacity. Available cooling capacity represents the maximum additional cooling power the node can provide beyond the cooling capacity already allocated to existing tasks, under the current cooling equipment configuration. The system determines whether to adjust the available cooling capacity based on the obtained inlet air temperature and cooling redundancy: if the current inlet air temperature is higher than a preset temperature threshold, it indicates that the node's inlet air environment is already too hot, and directly increasing the cooling capacity to its full potential may overload the cooling system or result in poor performance. In this case, the available cooling capacity is multiplied by a discount factor less than 1 to obtain the adjusted available cooling capacity. If the current cooling redundancy is lower than a preset redundancy threshold, it indicates that the node's cooling capacity is close to saturation, and the same discount adjustment applies. The preset temperature threshold is the upper limit of the recommended operating temperature range in the node's hardware specifications minus a safety margin, which is one-tenth of the range width. The preset redundancy threshold is 20%, meaning that a discount adjustment is triggered when the remaining cooling capacity is less than one-fifth of the total cooling capacity. The discount factor is the ratio of the current cooling redundancy to the preset redundancy threshold, but it cannot exceed 0.8. If the inlet air temperature does not exceed the threshold and the cooling redundancy is not lower than the threshold, the adjusted available cooling capacity is equal to the original available cooling capacity.

[0143] The system calculates the difference between the required cooling capacity and the adjusted available cooling capacity, using this difference as the target increment for cooling capacity. If the difference is less than or equal to zero, it indicates that the existing available cooling capacity of the target node already meets the demand, and the target increment is set to zero, requiring no additional cooling capacity. If the difference is positive, the system executes a cooling capacity increase operation according to this target increment. The specific adjustment process and rules are as follows:

[0144] The system first converts the target increment into the cooling fan speed increment. The conversion rule is as follows: obtain the rated maximum speed and current speed of the cooling fan at the target node, calculate the maximum cooling power increment that can be provided by increasing the fan speed from the current value to the maximum value, and denoted as the maximum increaseable power of the fan. The system calculates the ratio of the target increment to the maximum increaseable power of the fan to obtain the fan speed demand ratio. If this ratio is less than or equal to 1, the target speed is equal to the current speed multiplied by (1 plus this ratio), but does not exceed the rated maximum speed. If this ratio is greater than 1, it means that increasing the fan speed alone cannot meet the target increment. The system first increases the fan speed to the rated maximum speed to obtain all the cooling increment that the fan can provide, and then transfers the remaining unmet cooling increment to the next level of adjustment.

[0145] For cooling increments that are not met after fan adjustment, the system initiates refrigerant pump flow regulation. The system acquires the current and maximum flow setpoints of the refrigerant pump, calculates the cooling power increment that can be provided by increasing the flow rate from the current value to the maximum value, and records this as the pump's maximum increaseable power. The system divides the remaining unmet cooling increment by the pump's maximum increaseable power to obtain the flow demand ratio. The system increases the refrigerant pump valve opening or increases the pump's operating frequency according to this ratio. The target flow setpoint is equal to the current flow setpoint multiplied by (1 plus this ratio), but does not exceed the maximum flow setpoint. Flow regulation uses a step-by-step approach, increasing the maximum flow rate by 5% each time. After each step, a sampling period (e.g., two seconds) is waited to observe the inlet air temperature change trend. If the temperature drop rate exceeds 0.2 degrees Celsius per second, the regulation is terminated early to avoid over-cooling.

[0146] If there is still insufficient cooling capacity after adjusting fan speed and refrigerant pump flow, the system will initiate temperature adjustment for the refrigeration equipment. The system will adjust the current set temperature of the refrigeration equipment downwards, with the adjustment amount proportional to the remaining unmet cooling capacity. The conversion rule is: for every unit increase in cooling power required, the set temperature will be lowered by 0.5 degrees Celsius, but the lowered set temperature will not be lower than the equipment's minimum allowable set temperature (e.g., 15 degrees Celsius). Temperature adjustment is performed gradually downwards, waiting for one adjustment cycle (e.g., ten seconds) after each degree decrease to observe changes in inlet air temperature and the operating status of the refrigeration equipment. If the inlet air temperature has dropped below the preset temperature threshold, further downward adjustment will stop.

[0147] If the cooling increment is still not fully met after the above three-level adjustment is completed, the system activates the backup cooling units. The system detects whether there are backup cooling units in standby or low-power state in the target node. If so, they are activated one by one in priority order. For each backup cooling unit activated, the system obtains the rated cooling power that unit can provide and deducts this power value from the remaining unmet cooling increment until the remaining increment is zero or all backup units have been activated.

[0148] Throughout the adjustment process, the system continuously monitors the inlet air temperature and cooling redundancy of the target node, collecting data every two seconds. The initial inlet air temperature T0 is recorded before adjustment begins, and the current inlet air temperature T_curr is collected in real-time during adjustment. The system judges the adjustment progress and decides whether to terminate early according to the following rules: If the current inlet air temperature T_curr has dropped below the preset temperature threshold and remained stable for more than two sampling cycles, while the cooling redundancy has risen back above the preset redundancy threshold, then the cooling capacity is deemed to meet the demand, and subsequent adjustment steps are immediately terminated, even if the target increment has not been fully achieved. If the current inlet air temperature decreases at a rate exceeding 0.5 degrees Celsius per second, it indicates that the cooling capacity is increasing too rapidly and may lead to overcooling. The system pauses subsequent adjustment steps, maintains the current cooling output, and waits for the temperature to stabilize before deciding whether to continue adjustment based on the deviation between the actual temperature and the target temperature. If the current inlet air temperature decreases by less than 0.5 degrees Celsius within 30 seconds of the start of adjustment, it indicates that the current adjustment method is insufficient, and the system directly skips the current adjustment level and enters the next higher level of adjustment.

[0149] After confirming that the cooling capacity has been increased to the required level, the system notifies the task repair module to begin the repair operation. During the repair process, the system continues to monitor the intake air temperature once per second. If the temperature rises again above the preset temperature threshold, the system triggers a supplementary adjustment process, incrementally adjusting in the order of fan priority, flow rate second, set temperature third, and backup unit last, until the repair is complete. Through this graded and step-by-step adjustment process and real-time monitoring feedback, the system achieves a precise and smooth increase in cooling capacity, avoiding over-adjustment and oscillation, and ensuring that the cooling capacity is fully in place when the task resumes execution.

[0150] This invention utilizes a lightweight causal log and incremental repair mechanism, enabling task recovery to only re-execute write operations that have not yet been committed and whose dependent conditions are met. Combined with data block timestamp verification, it ensures cross-task data consistency, avoiding the computational and energy overhead of full recalculation. Simultaneously, it determines the required cooling capacity by jointly analyzing peak heat generation and predicted cooling power, dynamically adjusting available cooling capacity based on target node inlet air temperature and cooling redundancy. It calculates the target incremental cooling capacity and pre-increases cooling capacity before repair, ensuring that cooling capacity is in place when the task resumes. These two aspects work together to guarantee data consistency and execution efficiency during task recovery under grid command response, while also achieving on-demand pre-allocation and precise supply of cooling capacity, effectively reducing the overall operation and maintenance costs of computing, power, and cooling systems.

[0151] Please see Figure 3 As shown, Figure 3 This is a schematic diagram of the integrated operation and maintenance system for computing, power, and cooling in this embodiment.

[0152] Specifically, a system applied to the integrated computing, power supply, and cooling operation and maintenance method includes:

[0153] The task identification module is used to identify non-urgent computing tasks from the computing task cluster in response to power grid dispatch instructions, and to obtain the cooling status parameters of the computing node where the non-urgent computing task is currently located.

[0154] The contract management module, connected to the task identification module, is used to define interruptible transaction contracts for the non-urgent computing tasks and configure a double-buffered state storage area, while recording the predicted heat generation and actual heat generation generated by executing the non-urgent computing tasks.

[0155] The task pause module, connected to the contract management module, is used to pause the non-urgent computing task at the interruptible point specified by the interruptible transaction contract when the non-urgent computing task receives an interruption instruction or migration instruction, generate a lightweight causal log, solidify the confirmed state, and reduce the cooling output of the computing node where the non-urgent computing task is currently located based on the predicted heat generation and the actual heat generation.

[0156] The task migration module, connected to the task pause module, is used to migrate the paused non-urgent computing tasks and the contents of their double-buffered state storage areas to the target computing node, and to send the historical heat generation data and required cooling capacity parameters corresponding to the non-urgent computing tasks to the target computing node.

[0157] The task repair module, connected to the task migration module, is used to repair only the subset of uncommitted write operations when restoring the non-urgent computing task on the target computing node, based on the confirmed status and the lightweight causal log. Before repair, the cooling capacity of the target computing node is increased based on the historical heat generation data and the required cooling capacity parameters.

[0158] The task recovery module, connected to the task repair module, is used to resume the execution of the non-urgent computing task after the repair is completed, when the cooling capacity of the target computing node meets the heat dissipation requirements of the non-urgent computing task after recovery.

[0159] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of the present invention.

Claims

1. An integrated computing and cooling operation and maintenance method, characterized in that, include: Step S1: In response to the power grid dispatching command, identify non-emergency computing tasks from the computing task cluster and obtain the cooling status parameters of the computing node where the non-emergency computing task is currently located. Step S2: Define an interruptible transaction contract for the non-urgent computing task and configure a double-buffered state storage area, while recording the predicted heat generation and actual heat generation generated by executing the non-urgent computing task. Step S3: When the non-urgent computing task receives an interruption instruction or migration instruction, the non-urgent computing task is suspended at the interruptible point specified by the interruptible transaction contract, a lightweight causal log is generated, the confirmed state is solidified, and the cooling output of the computing node where the non-urgent computing task is currently located is reduced according to the predicted heat generation and the actual heat generation. Step S4: Migrate the contents of the paused non-emergency computing task and its double-buffered state storage area to the target computing node, and send the historical heat generation data and required cooling capacity parameters corresponding to the non-emergency computing task to the target computing node. Step S5: When restoring the non-urgent computing task on the target computing node, based on the confirmed status and the lightweight causal log, only the uncommitted subset of write operations are repaired, and before the repair, the cooling capacity of the target computing node is increased based on the historical heat generation data and the required cooling capacity parameters. Step S6: After the repair is completed, when the cooling capacity of the target computing node meets the heat dissipation requirements of the non-urgent computing task after it is restored, the execution of the non-urgent computing task is resumed.

2. The all-electric integrated operation and maintenance method according to claim 1, characterized in that, In step S1, non-urgent computing tasks are identified from the computing task cluster, including: Step S11: Obtain the current computing resource utilization rate, predicted remaining execution time, and cooling redundancy of the current computing node for each computing task in the computing task cluster. Step S12: Calculate the total amount of computing resources to be released for computing tasks that need to be suspended or migrated, based on the load reduction required by the power grid dispatching instruction. Step S13: Determine the interruption urgency of each computing task based on the current computing resource utilization rate, predicted remaining execution time, and cooling redundancy of the node where it is located. Step S14: Determine non-urgent computing tasks from the computing task cluster based on the interruption urgency.

3. The all-electric integrated operation and maintenance method according to claim 1, characterized in that, In step S2, an interruptible transaction contract is defined for the non-urgent computing task, including: Step S211: Identify all write operations in the non-urgent computing task, and divide the write operations into multiple atomic submission units according to the predicted heat generation, wherein each atomic submission unit corresponds to a predicted heat generation increment interval. Step S212: Insert checkpoint markers at the start and end positions of each atomic submission unit; Step S213: Record the location information of each checkpoint mark and the predicted heat increment value corresponding to each atomic submission unit into the contract metadata as the interruptible transaction contract.

4. The all-electric integrated operation and maintenance method according to claim 1, characterized in that, In step S2, a double-buffered state storage area is configured for the non-urgent computing task, including: Step S221: Allocate a first buffer and a second buffer in memory for the non-urgent computing task, wherein the first buffer and the second buffer have the same storage structure; Step S222: Set the first buffer as an active buffer to receive and store intermediate state data generated during the execution of the non-urgent computing task; Step S223: Set the second buffer as a spare buffer to keep it idle when the first buffer is written to.

5. The all-electric integrated operation and maintenance method according to claim 1, characterized in that, In step S3, a lightweight causal log is generated, including: Step S31: Record the position number of the last checkpoint marker when the non-urgent computing task is paused; Step S32: Capture all write operations that the non-urgent computing task has not yet committed at the pause time, and record the last write timestamp of the data block read by each write operation; Step S33: Arrange the uncommitted write operations into a write operation sequence according to their execution order, and mark the sequence number of the previous write operation that each write operation depends on. Step S34: The location number of the last checkpoint, the sequence of write operations, and the sequence number of the previous write operation that each write operation depends on are encapsulated together into the lightweight causal log.

6. The all-electric integrated operation and maintenance method according to claim 1, characterized in that, In step S3, reducing the cooling output of the computing node where the non-urgent computing task is currently located includes: Based on the difference between the predicted heat generation and the actual heat generation, calculate the redundant heat value released after the non-urgent computing task is paused; Based on the redundant heat value and the cooling status parameters of the current computing node, determine the reduction in cooling output. The cooling output is reduced according to the stated reduction amount.

7. The all-electric integrated operation and maintenance method according to claim 1, characterized in that, In step S5, the subset of uncommitted write operations is repaired, including: Step S51: Parse the position number of the last checkpoint marker, the sequence of write operations, and the sequence number of the previous write operation that each write operation depends on from the lightweight causal log. Step S52: Determine the recovery starting point of the non-urgent computing task based on the location number of the last checkpoint marker; Step S53: Starting from the recovery starting point, traverse the sequence of write operations, and according to the sequence number of the previous write operations that each write operation depends on, re-execute only the write operations that have not yet been committed and whose dependent previous write operations have all been completed.

8. The integrated operation and maintenance method for computing, power supply, and cooling as described in claim 1, characterized in that, In step S5, increasing the cooling capacity of the target computing node includes: Extract the average and peak calorific values ​​of the non-emergency computing task before it was paused from the historical calorific data; Obtain the predicted cooling power required after the non-urgent computing task resumes from the required cooling capacity parameters; The target increment of cooling capacity is determined based on the peak heat output, the predicted cooling power, and the current cooling status of the target computing node. Increase the cooling capacity according to the stated target increment.

9. The integrated operation and maintenance method for computing, power supply, and cooling systems according to claim 8, characterized in that, Determine the target increment for cooling capacity, including: The larger of the peak heat generation and the predicted cooling power is taken as the required cooling capacity. Based on the current cooling status of the target computing node, obtain its inlet air temperature, current cooling power, cooling redundancy, and available cooling capacity. When the inlet air temperature is higher than the preset temperature threshold or the cooling redundancy is lower than the preset redundancy threshold, the available cooling capacity is multiplied by a discount factor to obtain the adjusted available cooling capacity. Calculate the difference between the required cooling capacity and the adjusted available cooling capacity, and use the difference as the target increment of the cooling capacity.

10. A system applied to the integrated operation and maintenance method for computing, power supply, and cooling as described in any one of claims 1-9, characterized in that, include: The task identification module is used to identify non-urgent computing tasks from the computing task cluster in response to power grid dispatch instructions, and to obtain the cooling status parameters of the computing node where the non-urgent computing task is currently located. The contract management module is used to define interruptible transaction contracts for the non-urgent computing tasks and configure a double-buffered state storage area, while recording the predicted heat generation and actual heat generation generated by executing the non-urgent computing tasks. The task pause module is used to pause the non-urgent computing task at the interruptible point specified by the interruptible transaction contract when the non-urgent computing task receives an interruption instruction or migration instruction, generate a lightweight causal log, solidify the confirmed state, and reduce the cooling output of the computing node where the non-urgent computing task is currently located based on the predicted heat generation and the actual heat generation. The task migration module is used to migrate the paused non-urgent computing tasks and the contents of their double-buffered state storage areas to the target computing node, and to send the historical heat generation data and required cooling capacity parameters corresponding to the non-urgent computing tasks to the target computing node. The task repair module is used to repair only the subset of uncommitted write operations when restoring the non-urgent computing task on the target computing node, based on the confirmed status and the lightweight causal log. Before repair, the cooling capacity of the target computing node is increased based on the historical heat generation data and the required cooling capacity parameters. The task recovery module is used to resume the execution of the non-urgent computing task after the repair is completed, when the cooling capacity of the target computing node meets the heat dissipation requirements of the non-urgent computing task after recovery.

Images