Task pool priority adjustment method and device, equipment and medium

Abstract

The embodiment of the invention discloses a task pool priority adjustment method and device, equipment and a medium, and is applied to a specified system, the task pool priority adjustment method comprises the steps that the priority of each task queue in a task pool is defined according to service requirements and task characteristics, and each task queue comprises a plurality of tasks; calling the tasks in each task queue in the task pool based on a preset task scheduling algorithm; acquiring a real-time load parameter of the specified system; and if the real-time load parameter exceeds a preset threshold value, adjusting the tasks in each task queue.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a method, device, equipment, and medium for adjusting task pool priority. Background Art

[0002] Task pooling is a mechanism for managing and scheduling tasks, widely used in computer science and software engineering. The origins of task pooling can be traced back to the development of concurrent programming and multithreading. In traditional single-threaded programming, tasks are typically executed sequentially, with one task completing before the next. However, with the increase in computer processing power and the prevalence of multi-core processors, executing multiple tasks simultaneously has become a more efficient approach. Task pooling has emerged as a solution to this problem. It can distribute multiple tasks to multiple threads for simultaneous execution, thereby improving system concurrency and execution efficiency.

[0003] The existing task pool allocates task queues by predefined fixed priorities and cannot dynamically adjust queue weights according to real-time business needs (such as sudden traffic and changes in task characteristics). Summary of the Invention

[0004] One or more embodiments of this specification provide a task pool priority adjustment method, apparatus, device, and medium for solving the technical problems raised in the background technology.

[0005] One or more embodiments of this specification adopt the following technical solutions:

[0006] One or more embodiments of this specification provide a method for adjusting task pool priorities, the method being applied to a specified system and comprising:

[0007] Defining the priority of each task queue in the task pool according to business requirements and task characteristics, wherein the task queue includes multiple tasks;

[0008] In the task pool, tasks in each task queue are called based on a preset task scheduling algorithm;

[0009] Obtaining real-time load parameters of the specified system;

[0010] If the real-time load parameter exceeds a preset threshold, the tasks in each task queue are adjusted.

[0011] It should be noted that this method breaks through the limitations of static scheduling with fixed priorities in traditional task pools by introducing a dynamic weight feedback mechanism, and solves the core contradiction of "mismatch between preset priorities and dynamic business scenarios". While fixed priority settings can initially reflect business logic (such as assigning queue weights by task type), they are unable to detect load fluctuations during system runtime (such as resource crowding caused by a sudden influx of traffic into a high-priority queue). Real-time load parameter thresholds trigger priority adjustments, essentially inferring resource allocation imbalances from load signals (for example, a high-priority queue continuously occupies the CPU due to a backlog of tasks, while medium- and low-priority queues are unable to initiate critical tasks due to insufficient resources). Dynamic task queue adjustment decouples system load from business needs and remaps them. If high load is caused by a surge in tasks in a high-priority queue, its resource quota is temporarily increased and the priority of non-urgent queues is downgraded to avoid global performance degradation caused by overload of a single queue. If load anomalies arise from resource fragmentation caused by multiple queues competing for resources, queue weights are restructured based on task characteristics (such as I / O-intensive versus compute-intensive) to optimize resource utilization topology. This results in a flexible priority strategy that enables the task pool to ensure core business responsiveness in emergency scenarios (for example, prioritizing payment transaction queues) while maintaining overall system resilience by dynamically downgrading non-critical tasks (such as asynchronous log write queues), achieving a real-time balance between business value and resource efficiency.

[0012] Furthermore, the method further comprises:

[0013] When a new task is added to the task pool, the new task is placed in a corresponding task queue according to the priority of the new task.

[0014] It should be noted that this solution solves the problems of rigid resource allocation and delayed priority response caused by "static queue division" in traditional task pools through a dynamic classification mechanism when tasks are queued. New tasks are queued by priority, directly anchoring their characteristics to business objectives (such as real-time and criticality), avoiding scheduling conflicts caused by the mixing of high- and low-priority tasks in a unified queue (such as low-priority, long-running tasks blocking high-priority, urgent tasks). Combined with dynamic queue weight adjustment (such as queue resource reallocation when load exceeds a threshold), priority-based queuing forms a two-tiered control system. Horizontally, tasks are categorized and assigned to corresponding queues using priority labels, naturally isolating task flows of varying value densities and reducing scheduler decision complexity. Vertically, when system load fluctuates, dynamic adjustment of queue weights can allocate resources in a targeted manner (such as temporarily increasing thread quotas in high-priority queues), ensuring that critical task processing is not delayed due to fixed queue resources. This mechanism is particularly critical in bursty traffic scenarios. The continuous enqueuing of new high-priority tasks triggers an adaptive increase in queue weights, creating a resource-preemptive response that avoids the backlog of urgent tasks caused by static queue resource allocation. Simultaneously, resource reduction in low-priority queues inhibits the submission of non-core tasks, achieving business-value-oriented load shaving.

[0015] Furthermore, the preset threshold is a dynamic threshold, and if the real-time load parameter exceeds the preset threshold, adjusting the tasks in each task queue includes:

[0016] Collecting periodic load data of the designated system within a historical time window;

[0017] Performing Fourier transform analysis on the load data to identify the main frequency fluctuation characteristics of the load in the designated system;

[0018] An exponential smoothing prediction model is constructed based on the main frequency fluctuation characteristics to dynamically generate load threshold intervals for future time segments;

[0019] When the real-time load parameter exceeds the load threshold range, the tasks in each task queue are adjusted.

[0020] It should be noted that this solution solves the problem of "misjudgment of resource oscillation" caused by the traditional fixed threshold mechanism ignoring the periodic law of load through dynamic threshold interval prediction and main frequency feature driven adjustment. Fixed threshold presets are difficult to adapt to the inherent periodic fluctuations of system load (such as alternation of daytime peaks and nighttime low peaks), and are prone to trigger invalid queue adjustments when the load fluctuates naturally, causing "pseudo-overload" losses caused by repeated expansion and contraction of resource allocation; Fourier transform identifies the main frequency characteristics to extract the periodic law of load data (such as traffic peaks in hours or task pulses in seconds), revealing the steady-state fluctuation pattern and sudden abnormal characteristics of the system load, and providing a spectral dimension basis for the dynamic threshold; the exponential smoothing prediction model predicts future load trends based on historical main frequency characteristics, and generates dynamic threshold intervals (such as the threshold during the peak period is shifted upward, The trough threshold is lowered) so that the threshold setting resonates with the natural cycle of the load; the out-of-interval dynamic adjustment is only triggered when the load deviates from the predicted fluctuation pattern (such as sudden traffic breaking through the peak threshold or abnormal low load causing idle resources), accurately distinguishing between "periodic normal load" and "real abnormal load", and avoiding excessive response to regular fluctuations; thus, the task queue adjustment is upgraded from "stress-based passive response" to "cycle-aware active adaptation", which not only reduces the resource fragmentation loss caused by invalid scheduling, but also can quickly isolate risk queues under real abnormal loads, thereby improving the system's anti-interference ability and resource utilization continuity.

[0021] Furthermore, the adjusting of tasks in each task queue includes:

[0022] Detect task chains with dependencies in each task queue in real time and generate a task dependency graph;

[0023] Dynamically calculating the priority attenuation coefficient of each dependent layer according to the degree of deviation from the load threshold interval;

[0024] The tasks in each task queue are adjusted based on the priority decay coefficient.

[0025] It should be noted that this solution solves the contradiction between "static priority allocation" and "task dependency chain resource deadlock" in traditional task scheduling through a dependency-aware dynamic priority decay mechanism. When dealing with task chains with dependencies, fixed-priority scheduling ignores the hierarchical dependency characteristics, which can easily lead to insufficient resource preemption of predecessor tasks (such as low-priority subtasks blocking high-priority parent tasks), forming dependency-conducting congestion; task dependency graph construction locates critical path tasks (such as end-level tasks without additional dependencies) by real-time analysis of task chain hierarchical relationships (such as parent-child tasks, parallel branch tasks), revealing the key blocking points of task execution; dynamic calculation of priority decay coefficient converts the degree of deviation from the load threshold interval into a priority adjustment weight: when the load far exceeds the high threshold, non-critical paths are prioritized. It applies exponential decay to critical path tasks (such as non-essential tasks in parallel branches) to quickly release resources to supply critical paths; when the load is lower than the threshold range, the decay coefficient is restored to activate the parallel processing of non-critical tasks, thereby improving the overall throughput efficiency; this mechanism forms a dependency-sensitive resource rush capability under sudden high loads: it gives priority to guaranteeing the execution of critical path tasks, cuts off invalid resource consumption in the dependency chain (such as low-priority tasks waiting in loops), and makes the completion time of complex dependent task flows no longer affected by loosely coupled tasks. It is especially suitable for the end-to-end timeliness guarantee of cross-node task scheduling under the microservice architecture.

[0026] Furthermore, the adjusting of tasks in each task queue includes:

[0027] Real-time identification of long-term tasks in each task queue that have an execution time exceeding the preset duration;

[0028] Constructing an execution feature matrix of the long-term task, wherein the execution feature matrix includes CPU occupancy, memory increment, and I / O request frequency;

[0029] Classifying the long-period tasks based on the correlation between the real-time load parameter and the execution feature matrix to obtain a classification result;

[0030] A resource block pre-allocation strategy is performed on tasks of the same type according to the classification result.

[0031] It should be noted that this solution solves the problem of rigid resource allocation and local performance collapse caused by "blindness of resource occupancy of long-cycle tasks" in traditional task scheduling through a resource pre-allocation mechanism driven by long-cycle task characteristics. Long-cycle task identification focuses on task types that have a continuous impact on system load (such as data analysis batch processing and large-scale file transcoding), to avoid obscuring the efficient scheduling window of short tasks due to their long execution cycle and unpredictable resource occupancy; execution feature matrix construction converts the resource consumption mode of tasks (such as CPU intensive, memory resident or I / O blocking) into quantifiable indicators, revealing the implicit occupancy level and fluctuation pattern of system resources by long-cycle tasks; real-time load association classification dynamically adjusts the classification strategy based on the current system status. For example, when the CPU load is saturated, long tasks with high CPU occupancy are classified as "delay sensitive", and independent computing units are pre-allocated first to isolate resource competition. When memory fragmentation is severe, long tasks with high memory requirements are classified as "space-compact" and continuous memory blocks are pre-allocated to reduce paging overhead. The resource block pre-allocation strategy reserves resources in batches based on the characteristics of similar tasks, forming the shortest matching path between resource supply and task demand, avoiding the additional overhead caused by repeated resource application and release during the execution of long-term tasks, and reducing the queuing delay of short tasks by avoiding resource competition. As a result, the system can dynamically cut the resource pool in mixed load scenarios (such as concurrent real-time interactive tasks and long-term tasks), achieving the dual goals of isolated resource supply for long tasks and low-latency response for short tasks, breaking the vicious cycle of "long-tail tasks dragging down the real-time performance of the system."

[0032] Furthermore, the resource block pre-allocation strategy includes:

[0033] Divide the hot data buffer in the memory allocation unit and establish a mapping relationship between task type and buffer address;

[0034] Real-time monitoring of the frequency of cross-page table accesses during task execution, and injection of the feature matrix according to time slices;

[0035] Generate an iterative task type classifier based on the updated feature matrix and reconstruct the mapping relationship between task type and buffer address;

[0036] When a continuous address access pattern is detected, the target buffer is located according to the reconstructed mapping relationship;

[0037] The physical page frame mapping range of the target buffer is dynamically extended to the adjacent memory block, and an I / O batch merge operation is triggered according to a current cross-page table access frequency threshold.

[0038] It should be noted that this solution solves the problems of memory locality degradation and I / O efficiency degradation caused by "static paging strategy" and "task access characteristics mismatch" in traditional memory management through a dynamic paging optimization mechanism driven by memory access patterns. The dynamic mapping of hot data buffers strongly associates task types with physical addresses, builds the spatiotemporal continuity of "memory access hotspots" based on real-time access frequency, breaks the randomness of traditional fixed page frame allocation, and reduces TLB misses and memory addressing fragmentation caused by cross-page table jumps; cross-page table access monitoring and feature iteration continuously correct the task classification logic by capturing access patterns within the time slice (such as burst intensive reads or intermittent writes), so that the buffer mapping relationship dynamically adapts to the memory behavior migration during the task execution phase (such as the transition from sequential access to random access), avoiding resource mismatches caused by task phase deviations in static classifiers; continuous access mode triggers page frame extension based on real-time access continuity detection, actively expanding adjacent physical page frames to form continuous memory blocks. , converges access actions that originally spanned multiple discontinuous pages into a local continuous space, significantly reducing the frequency of page fault interrupts and memory bus contention; the I / O batch merging strategy aggregates scattered I / O requests into batch operations (such as merging adjacent sector reads and writes) when the cross-page access frequency exceeds the threshold, and reduces the storage medium's seek latency and protocol interaction overhead by strengthening the access space locality, so that the I / O throughput efficiency and memory access behavior are coordinated and optimized; thereby constructing a memory-storage collaborative acceleration channel, and under the premise of ensuring the security of task memory isolation, through dynamic topology adjustment of physical page frames and intelligent adaptation of I / O scheduling, resolves the "ant colony effect" of long-tail task memory access, and improves the end-to-end execution consistency of data-intensive tasks in high-concurrency scenarios.

[0039] Furthermore, calling tasks in each task queue based on a preset task scheduling algorithm in the task pool includes:

[0040] In the task pool, tasks in each task queue are called based on a priority preemption algorithm.

[0041] It should be noted that this solution solves the problem of high-priority task response delay and low-priority task resource idling caused by "non-preemptive scheduling" in the traditional task pool through the dynamic intervention mechanism of the priority preemptive algorithm. Although static priority scheduling presets task queue priorities, it lacks preemption capabilities. High-priority tasks must wait for currently executing low-priority tasks to complete, resulting in urgent tasks (such as real-time transaction requests) being blocked by non-critical tasks (such as log backups), leading to priority inversion delays. The priority preemption algorithm empowers high-priority tasks to interrupt the execution of low-priority tasks. By instantly preempting CPU resources, high-value tasks are inserted at the forefront of the execution flow, eliminating inter-queue wait chains and strictly aligning task response timeliness with business value density. This mechanism is particularly critical in sudden high-load scenarios. When the system is flooded with high-priority tasks, preemptive scheduling quickly clears the high-priority queue, resulting in a steep curve in task processing timeliness and avoiding avalanche-like delays in critical business operations caused by queue backlogs. At the same time, preempted low-priority tasks enter a recoverable state and resume execution after resources are released, preventing duplicate computation and resource waste caused by forced termination. This creates a business-value-oriented elastic preemption channel that ensures instantaneous response for high-priority tasks while maintaining resource recoverability for low-priority tasks, achieving a dual leap in system throughput efficiency and business value realization capabilities.

[0042] One or more embodiments of this specification provide a task pool priority adjustment device, applied to a specified system, including:

[0043] A definition unit, which defines the priority of each task queue in the task pool according to business requirements and task characteristics, wherein the task queue includes multiple tasks;

[0044] A calling unit, which calls tasks in each task queue in the task pool based on a preset task scheduling algorithm;

[0045] An acquiring unit, configured to acquire real-time load parameters of the designated system;

[0046] The adjustment unit adjusts the tasks in each task queue if the real-time load parameter exceeds a preset threshold.

[0047] One or more embodiments of this specification provide a task pool priority adjustment device, applied to a specified system, including:

[0048] at least one processor; and,

[0049] a memory communicatively connected to the at least one processor; wherein,

[0050] The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to:

[0051] Defining the priority of each task queue in the task pool according to business requirements and task characteristics, wherein the task queue includes multiple tasks;

[0052] In the task pool, tasks in each task queue are called based on a preset task scheduling algorithm;

[0053] Obtaining real-time load parameters of the specified system;

[0054] If the real-time load parameter exceeds a preset threshold, the tasks in each task queue are adjusted.

[0055] One or more embodiments of this specification provide a non-volatile computer storage medium, applied to a specified system, storing computer-executable instructions. When executed by a computer, the computer-executable instructions can achieve:

[0056] Defining the priority of each task queue in the task pool according to business requirements and task characteristics, wherein the task queue includes multiple tasks;

[0057] In the task pool, tasks in each task queue are called based on a preset task scheduling algorithm;

[0058] Obtaining real-time load parameters of the specified system;

[0059] If the real-time load parameter exceeds a preset threshold, the tasks in each task queue are adjusted.

[0060] At least one of the above technical solutions adopted in the embodiments of this specification can achieve the following beneficial effects:

[0061] This method breaks through the limitations of static scheduling with fixed priorities in traditional task pools by introducing a dynamic weight feedback mechanism, and resolves the core contradiction of "mismatch between preset priorities and dynamic business scenarios." While fixed priority settings can initially reflect business logic (such as assigning queue weights by task type), they are unable to detect load fluctuations during system runtime (such as resource crowding caused by a sudden influx of traffic into a high-priority queue). Real-time load parameter thresholds trigger priority adjustments, essentially inferring resource allocation imbalances from load signals (for example, a high-priority queue continuously occupies the CPU due to a backlog of tasks, while medium- and low-priority queues are unable to initiate critical tasks due to insufficient resources). Dynamic task queue adjustment decouples system load from business needs and remaps them. If high load is caused by a surge in tasks in a high-priority queue, its resource quota is temporarily increased and the priority of non-urgent queues is downgraded to avoid global performance degradation caused by overload of a single queue. If load anomalies arise from resource fragmentation caused by multiple queues competing for resources, queue weights are restructured based on task characteristics (such as I / O-intensive versus compute-intensive) to optimize resource utilization topology. This results in a flexible priority strategy that enables the task pool to ensure core business responsiveness in emergency scenarios (for example, prioritizing payment transaction queues) while maintaining overall system resilience by dynamically downgrading non-critical tasks (such as asynchronous log write queues), achieving a real-time balance between business value and resource efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the following briefly introduces the drawings required for the embodiments or the description of the prior art. Obviously, the drawings described below are only some of the embodiments described in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without inventive work. In the drawings:

[0063] Figure 1 A flowchart of a task pool priority adjustment method provided in one or more embodiments of this specification;

[0064] Figure 2 A schematic diagram of the structure of a task pool priority adjustment device provided in one or more embodiments of this specification;

[0065] Figure 3 A schematic diagram of the structure of a task pool priority adjustment device provided in one or more embodiments of this specification. DETAILED DESCRIPTION

[0066] The embodiments of this specification provide a method, apparatus, device, and medium for adjusting task pool priority.

[0067] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this specification without creative work should fall within the scope of protection of this specification.

[0068] Figure 1 This is a flowchart of a task pool priority adjustment method provided in one or more embodiments of this specification. The process can be executed by a specified system. Certain input parameters or intermediate results in the process allow manual intervention and adjustment to help improve accuracy.

[0069] The method steps of the embodiment of this specification are as follows:

[0070] S101 , defining the priority of each task queue in a task pool according to business requirements and task characteristics, wherein the task queue includes multiple tasks.

[0071] In this embodiment, tasks can be divided into core services (such as payment transactions), basic services (such as inventory synchronization), and auxiliary tasks (such as log writing) based on their types. The response delay tolerance and resource consumption characteristics (I / O intensive / computation intensive) of each type of task are clearly defined.

[0072] For the initial weight allocation, the high-priority queue is allocated 50% of the CPU and memory quota for processing non-delayable tasks such as payment confirmation and real-time risk control. The medium-priority queue is allocated 30% of the resources for time-sensitive tasks such as order status synchronization and cache updates. The low-priority queue is allocated 20% of the resources for handling batch asynchronous tasks such as log archiving and data analysis.

[0073] At the same time, a maximum task backlog threshold can be set for each queue (for example, a high-priority queue with a backlog of more than 1,000 tasks triggers an alert) to prevent resource crowding caused by unreasonable initial design.

[0074] S102 : Invoking tasks in each task queue in the task pool based on a preset task scheduling algorithm.

[0075] In the embodiment of this description, a dynamic weighted polling algorithm can be used. In the initial stage, tasks from each queue are polled and pulled according to the weight ratio (5:3:2) defined in S101. A minimum guaranteed quota is set, for example, at least 3 medium-priority tasks are executed in every 10 scheduling to avoid complete starvation of low-priority tasks. An independent thread pool (such as a fixed 8 threads) is allocated to the high-priority queue to ensure immediate response of core tasks. The medium and low priority queues share an elastic thread pool, and the initial number of threads is dynamically calculated based on the total system resources (such as 30% of the total number of threads).

[0076] When a single task execution times out (such as a payment task that takes more than 2 seconds to complete), the queue scheduling is automatically suspended and an alarm is triggered to prevent the fault from spreading.

[0077] S103: Acquire real-time load parameters of the designated system.

[0078] In this illustrative embodiment, the monitoring indicator dimensions may include resource class, queue status class, and business class.

[0079] Resource categories include CPU usage (core business container group), memory usage (JVM heap memory), and disk IO wait time.

[0080] The queue status category includes the number of pending tasks in each queue, the average waiting time, and the task abandonment rate.

[0081] Business categories include payment transaction success rate and risk inspection rule matching delay.

[0082] The data aggregation strategy can use a sliding time window (60-second window, 10-second step) to calculate the average CPU usage and filter out instantaneous jitter. Quantile statistics (P95 / P99) are performed on the queue backlog to identify long-tail outliers.

[0083] Threshold dynamic calibration may include a baseline threshold and a dynamic threshold.

[0084] The baseline threshold can be set as a static threshold based on historical peak load (such as CPU>85% for 1 minute).

[0085] Dynamic thresholds can predict the load in the next 5 minutes through machine learning models and automatically adjust the trigger sensitivity.

[0086] S104: If the real-time load parameter exceeds a preset threshold, the tasks in each task queue are adjusted.

[0087] In this embodiment, the following implementation scheme can be adopted:

[0088] 1. Single queue overload response:

[0089] Vertical scaling: When the payment queue backlog exceeds the threshold, its CPU quota is temporarily increased from 50% to 70%, and the log queue quota is simultaneously reduced to 5%.

[0090] Horizontal diversion: Tasks in the queue that exceed the processing capacity are marked as "degradable" and forwarded to the backup cluster or limited and discarded (such as payment requests from non-VIP users).

[0091] 2. Multi-queue competition optimization:

[0092] Resource topology reorganization: Identify I / O-intensive queues (such as log writing) and compute-intensive queues (such as risk control model inference) and bind them to different physical resources (such as SSD disk groups and GPU cards).

[0093] Defragmentation: When memory fragmentation causes the low-priority queue to fail to start, the cache occupied by non-core tasks (such as temporary preview image data) is forcibly released.

[0094] Policy implementation and rollback:

[0095] Adjustment commands are issued in real time via hot updates from the configuration center, with an effective period of less than 5 seconds. A 10-minute observation period is set. If the load does not return to normal, a second adjustment is triggered. If core indicators deteriorate after adjustment, the system automatically rolls back to the previous configuration version.

[0096] It should be noted that this method breaks through the limitations of static scheduling with fixed priorities in traditional task pools by introducing a dynamic weight feedback mechanism, and solves the core contradiction of "mismatch between preset priorities and dynamic business scenarios". While fixed priority settings can initially reflect business logic (such as assigning queue weights by task type), they are unable to detect load fluctuations during system runtime (such as resource crowding caused by a sudden influx of traffic into a high-priority queue). Real-time load parameter thresholds trigger priority adjustments, essentially inferring resource allocation imbalances from load signals (for example, a high-priority queue continuously occupies the CPU due to a backlog of tasks, while medium- and low-priority queues are unable to initiate critical tasks due to insufficient resources). Dynamic task queue adjustment decouples system load from business needs and remaps them. If high load is caused by a surge in tasks in a high-priority queue, its resource quota is temporarily increased and the priority of non-urgent queues is downgraded to avoid global performance degradation caused by overload of a single queue. If load anomalies arise from resource fragmentation caused by multiple queues competing for resources, queue weights are restructured based on task characteristics (such as I / O-intensive versus compute-intensive) to optimize resource utilization topology. This results in a flexible priority strategy that enables the task pool to ensure core business responsiveness in emergency scenarios (for example, prioritizing payment transaction queues) while maintaining overall system resilience by dynamically downgrading non-critical tasks (such as asynchronous log write queues), achieving a real-time balance between business value and resource efficiency.

[0097] Furthermore, when a new task is added to the task pool, the new task is placed in a corresponding task queue according to the priority of the new task.

[0098] In this embodiment, the following implementation scheme can be adopted:

[0099] 1. Task priority classification and labeling

[0100] Classification standard definition:

[0101] Business dimension: The tasks are divided into different levels according to their associated business value (e.g. core payment tasks are P0, inventory query is P1, log cleaning is P2).

[0102] Task characteristic dimensions: Mark the task type with real-time characteristics (e.g., "strong real-time" requires a response within 50ms), resource requirements (e.g., "high memory usage" requires more than 2GB of memory to be reserved), and dependencies (e.g., "depends on risk control results" requires pre-execution).

[0103] Dynamic label generation:

[0104] When a task is submitted, the business rule engine automatically parses the task metadata (such as API interface identifier and user level), combines it with the system's real-time indicators (such as the current queue backlog), and generates a priority label (such as P0+ strong real-time).

[0105] If a task does not explicitly define a priority, a default level is inferred based on historical execution records (such as the average time taken by similar tasks) (for example, long-running tasks are automatically downgraded to P2).

[0106] 2. Multi-level queue matching and queue entry control

[0107] Queue mapping rules:

[0108] Exact match: The priority tag strictly corresponds to the preset queue (for example, P0 tasks only enter the high-priority queue).

[0109] Elastic downgrade: When the backlog of the target queue exceeds the threshold (for example, the backlog of the high-priority queue is >500), the new task is automatically downgraded to the next-level queue and marked as "preemptible" (it can be migrated back first when sufficient resources are available).

[0110] Queue admission pre-check:

[0111] Before joining the queue, check the remaining resource quota of the target queue (such as the number of threads and memory remaining). If the resources are insufficient, trigger dynamic weight adjustment (see step 4 linkage).

[0112] Pre-reject low-priority tasks: When the overall system load exceeds 80%, P2 task submission is directly rejected and a "system busy" prompt is returned.

[0113] 3. Queue Weight Linkage and Resource Pre-allocation

[0114] Dynamic weight calculation:

[0115] According to the distribution density of the new task priority label (such as 10 consecutive P0 tasks entering the queue), the initial weight base of the corresponding queue is increased in real time (such as from 50% to 65%).

[0116] Weight adjustment triggers resource pre-allocation: redundant resources are reserved for high-priority queues (such as allocating two idle threads in advance) to ensure that subsequent tasks do not need to wait for resource initialization.

[0117] Queue isolation enhancements:

[0118] Configure an exclusive resource pool (such as an independent connection pool and disk IO channel) for the P0 queue to prevent medium and low priority tasks from competing for physical resources.

[0119] Enable resource borrowing restrictions for P1 / P2 queues to prohibit cross-queue preemption of CPU time slices (for example, the P2 queue can occupy a maximum of 20% of the shared thread pool).

[0120] 4. Exception handling and feedback loop

[0121] Enqueue conflict resolution:

[0122] If a task cannot be enqueued because the queue is full, inter-queue task migration is initiated: tasks marked as "interruptible" in low-priority queues are suspended to release resources for high-priority tasks.

[0123] Add a resume flag to the migration task to ensure automatic resumption after resource recovery.

[0124] Feedback optimization mechanism:

[0125] Record the deviation between the actual execution time of the task and the expected SLA, and dynamically modify the priority label rules (for example, a timed task automatically lowers the initial priority of similar tasks).

[0126] Through offline analysis of statistical task classification error rates, the matching logic of the business rule engine is regularly updated.

[0127] 5. Hierarchical current limiting and load balancing

[0128] Priority-aware current limiting:

[0129] Enable token bucket current limiting for the P0 queue and adjust the token generation rate according to the system load (for example, 100 tokens are issued per second when the load is 70%, and reduced to 50 tokens per second when the load is 90%).

[0130] Implement hard threshold current limiting on the P2 queue to directly limit the maximum number of concurrent tasks (for example, a maximum of 200 tasks are allowed to queue simultaneously).

[0131] Load balancing across queues:

[0132] When the weight of a queue is continuously too high (for example, the weight of the P0 queue is >70% for more than 5 minutes), some non-core subtasks will be automatically split to the backup queue (for example, the risk control verification of the payment task will be split to the P1 queue for asynchronous execution).

[0133] It should be noted that this solution solves the problems of rigid resource allocation and delayed priority response caused by "static queue division" in traditional task pools through a dynamic classification mechanism when tasks are queued. New tasks are queued by priority, directly anchoring their characteristics to business objectives (such as real-time and criticality), avoiding scheduling conflicts caused by the mixing of high- and low-priority tasks in a unified queue (such as low-priority, long-running tasks blocking high-priority, urgent tasks). Combined with dynamic queue weight adjustment (such as queue resource reallocation when load exceeds a threshold), priority-based queuing forms a two-tiered control system. Horizontally, tasks are categorized and assigned to corresponding queues using priority labels, naturally isolating task flows of varying value densities and reducing scheduler decision complexity. Vertically, when system load fluctuates, dynamic adjustment of queue weights can allocate resources in a targeted manner (such as temporarily increasing thread quotas in high-priority queues), ensuring that critical task processing is not delayed due to fixed queue resources. This mechanism is particularly critical in bursty traffic scenarios. The continuous enqueuing of new high-priority tasks triggers an adaptive increase in queue weights, creating a resource-preemptive response that avoids the backlog of urgent tasks caused by static queue resource allocation. Simultaneously, resource reduction in low-priority queues inhibits the submission of non-core tasks, achieving business-value-oriented load shaving.

[0134] Furthermore, the preset threshold is a dynamic threshold. If the real-time load parameter exceeds the preset threshold, when adjusting the tasks in each task queue, the periodic load data of the specified system within the historical time window can be collected; Fourier transform analysis can be performed on the load data to identify the main frequency fluctuation characteristics of the load in the specified system; an exponential smoothing prediction model is constructed based on the main frequency fluctuation characteristics to dynamically generate the load threshold interval for future time segments; when the real-time load parameter exceeds the load threshold interval, the tasks in each task queue are adjusted.

[0135] In this embodiment, the following implementation scheme can be adopted:

[0136] 1. Periodic load data collection

[0137] Data collection scope:

[0138] Time span: Rollingly collects load data for the last 30 days and stores it at minute granularity (such as CPU usage, memory usage, and queue backlog).

[0139] Feature dimension: Distinguish between weekday and holiday data and mark peak business hours.

[0140] Data preprocessing: Perform sliding window smoothing on outliers (e.g., removing instantaneous spikes within a 3-minute window) to eliminate occasional interference. Segment the data by natural cycles (e.g., hourly or daily) to construct a time series dataset.

[0141] 2. Identification of main frequency fluctuation characteristics

[0142] Spectrum Analysis Implementation:

[0143] Fourier transform parameter configuration: Set the fundamental frequency unit to the hourly level to identify daily periodic fluctuations; set the sub-band to the minute level to capture sudden pulses (such as second-level task peaks). Extract the first three main frequency components (such as the 24-hour period, 12-hour period, and 5-minute pulse) and quantize their amplitude and phase.

[0144] Feature visualization verification: Generate a spectrum heat map and manually verify whether the main frequency matches the business scenario (for example, the CPU usage peak at 10:00 every day corresponds to the order payment tide).

[0145] Signature library update: Automatically recalculate the main frequency component every week to dynamically adapt to changes in business patterns (such as seasonal traffic migration).

[0146] 3. Dynamic threshold interval generation

[0147] Prediction model construction:

[0148] Multi-period fusion modeling: The dominant frequency component (e.g., a 24-hour period) obtained from Fourier analysis is used as the trend term, and minute-level pulses as the residual term, which are then fed into an exponential smoothing model. Separate models are trained for weekdays and holidays to avoid pattern confusion.

[0149] Threshold interval calculation: Predict the load average for the next hour and generate dynamic upper and lower bounds based on confidence (e.g., the threshold is increased by 15% during peak periods and decreased by 10% during trough periods). Temporary thresholds are set for sudden spikes (e.g., the instantaneous CPU threshold is increased to 95%).

[0150] Threshold release mechanism: Dynamic thresholds are pushed to each node through the configuration center, and the effective time error is controlled within 10 seconds.

[0151] 4. Super interval adaptive adjustment

[0152] Adjust the strategy layer:

[0153] Tolerance for periodic fluctuations: When the real-time load fluctuates within the threshold range (such as the CPU naturally rising to 80% during the day), only logs are recorded without triggering adjustments, thus avoiding resource fluctuations.

[0154] Abnormal load response: upper limit exceeded (such as CPU>90% and lasting for 2 minutes):

[0155] Start queue demotion: Compress the thread quota of low-priority tasks (such as log writing) to 5%, and tilt resources to high-priority queues.

[0156] Triggering horizontal expansion: Predicting load duration based on the prediction model, expand the container instance capacity in advance (e.g., if the peak is predicted to last for 1 hour, double the instance capacity).

[0157] Lower bound breach (e.g. CPU < 30% for more than 10 minutes):

[0158] Resource recycling: Release idle resources to a shared pool for on-demand use by non-critical tasks (such as offline computing).

[0159] Queue preheating: Preload high-priority task dependencies (such as risk control rule cache) during low-load periods to reduce cold start delays during peak periods.

[0160] Feedback calibration mechanism: records the system recovery efficiency after the threshold is triggered (for example, the CPU falls back to the threshold within 5 minutes after the downgrade operation) and dynamically adjusts the width of the model confidence interval.

[0161] It should be noted that this solution solves the problem of "misjudgment of resource oscillation" caused by the traditional fixed threshold mechanism ignoring the periodic law of load through dynamic threshold interval prediction and main frequency feature driven adjustment. Fixed threshold presets are difficult to adapt to the inherent periodic fluctuations of system load (such as alternation of daytime peaks and nighttime low peaks), and are prone to trigger invalid queue adjustments when the load fluctuates naturally, causing "pseudo-overload" losses caused by repeated expansion and contraction of resource allocation; Fourier transform identifies the main frequency characteristics to extract the periodic law of load data (such as traffic peaks in hours or task pulses in seconds), revealing the steady-state fluctuation pattern and sudden abnormal characteristics of the system load, and providing a spectral dimension basis for the dynamic threshold; the exponential smoothing prediction model predicts future load trends based on historical main frequency characteristics, and generates dynamic threshold intervals (such as the threshold during the peak period is shifted upward, The trough threshold is lowered) so that the threshold setting resonates with the natural cycle of the load; the out-of-interval dynamic adjustment is only triggered when the load deviates from the predicted fluctuation pattern (such as sudden traffic breaking through the peak threshold or abnormal low load causing idle resources), accurately distinguishing between "periodic normal load" and "real abnormal load", and avoiding excessive response to regular fluctuations; thus, the task queue adjustment is upgraded from "stress-based passive response" to "cycle-aware active adaptation", which not only reduces the resource fragmentation loss caused by invalid scheduling, but also can quickly isolate risk queues under real abnormal loads, thereby improving the system's anti-interference ability and resource utilization continuity.

[0162] Furthermore, when adjusting the tasks in each task queue, the task chains with dependent relationships can be detected in real time in each task queue to generate a task dependency graph; the priority attenuation coefficient of each dependency level is dynamically calculated based on the degree of deviation from the load threshold interval; and the tasks in each task queue are adjusted based on the priority attenuation coefficient.

[0163] In this embodiment, the following implementation scheme can be adopted:

[0164] 1. Real-time construction of task dependency graph

[0165] Dependency resolution:

[0166] Metadata tagging: It enforces the declaration of dependencies (such as parent task ID and parallel branch ID) when submitting tasks, and automatically associates cross-service task nodes through the service registry (such as the order creation task depends on the inventory locking service).

[0167] Runtime dynamic tracing: Use distributed link tracing (such as OpenTelemetry) to capture task execution paths and update dependencies in real time (e.g., detecting that a payment task is blocked due to a risk control service delay). For implicitly associated tasks with undeclared dependencies, call chain analysis automatically infers the dependency hierarchy (e.g., a log cleaning task depends on the completion of batch writes to the database).

[0168] Graph generation and visualization: Task nodes and dependency edges are stored based on a graph database (such as Neo4j), and the topology structure is refreshed every 5 seconds.

[0169] Identify critical path tasks: Calculate the longest execution path of the task chain (such as the entire process from order creation to logistics delivery) and mark the final tasks without redundant dependencies (such as final payment confirmation).

[0170] 2. Dynamic attenuation coefficient layered calculation

[0171] Load deviation assessment:

[0172] Quantification of threshold offsets: The difference between the real-time load and the dynamic threshold is converted to a normalized offset value (e.g., CPU usage exceeding the upper bound by 20% is recorded as +0.2, while CPU usage falling below the lower bound by 10% is recorded as -0.1). Response modes are divided by the direction of the offset (positive overload / negative underload).

[0173] Layered decay strategy:

[0174] Critical path task: When the deviation value is greater than 0, the priority remains unchanged; when the deviation value is less than 0, a small attenuation (such as a coefficient of 0.9) is allowed to release redundant resources.

[0175] Non-critical path tasks: When the deviation value is greater than 0, exponential decay is applied (for example, the priority is reduced to 75% of the previous level every 5 minutes); when the deviation value is less than 0, the original priority is restored.

[0176] Parallel branch tasks: Dynamically adjust based on subtask redundancy. If there are multiple equivalent branches (such as three-party payment channels that can back up each other), linear attenuation (such as a coefficient of 0.6) is applied to inactive branch tasks.

[0177] Coefficient validation mechanism: The attenuation coefficient is sent to the task queue in real time through the priority weight table, and the task scheduler pulls tasks according to the latest weight.

[0178] 3. Dynamic adjustment of task queue

[0179] Critical path assurance:

[0180] Preemptive resource allocation: When a critical path task is downgraded due to a decay factor (e.g., during periods of low system load), a priority callback is automatically triggered to ensure it always receives a minimum guaranteed resource allocation (e.g., at least 20% of the CPU quota). Exclusive thread groups are allocated to critical path tasks, preventing non-critical tasks from preempting their execution resources.

[0181] Non-mission critical suppression:

[0182] Gradual degradation: For tasks whose decay coefficient falls below a threshold (e.g., <0.5), resource recycling is initiated: the occupied cache and database connections are released to a common pool. If a task has not been executed for three consecutive scheduling cycles, it is marked as interruptible, allowing the system to forcibly suspend it or migrate it to a lower-priority queue.

[0183] Dependency-aware interruption:

[0184] Before interrupting a non-critical task, check its dependency impact: If the interruption will not block the critical path (such as redundant tasks in a parallel branch), execute it immediately; otherwise, enter the resource waiting state and record the blocked link.

[0185] Elastic recovery mechanism: When the load returns to the threshold range, non-critical task resources are gradually returned according to the recovery speed of the attenuation coefficient (for example, for every 0.1 decrease in the deviation value, the coefficient increases by 15%).

[0186] It should be noted that this solution solves the contradiction between "static priority allocation" and "task dependency chain resource deadlock" in traditional task scheduling through a dependency-aware dynamic priority decay mechanism. When dealing with task chains with dependencies, fixed-priority scheduling ignores the hierarchical dependency characteristics, which can easily lead to insufficient resource preemption of predecessor tasks (such as low-priority subtasks blocking high-priority parent tasks), forming dependency-conducting congestion; task dependency graph construction locates critical path tasks (such as end-level tasks without additional dependencies) by real-time analysis of task chain hierarchical relationships (such as parent-child tasks, parallel branch tasks), revealing the key blocking points of task execution; dynamic calculation of priority decay coefficient converts the degree of deviation from the load threshold interval into a priority adjustment weight: when the load far exceeds the high threshold, non-critical paths are prioritized. It applies exponential decay to critical path tasks (such as non-essential tasks in parallel branches) to quickly release resources to supply critical paths; when the load is lower than the threshold range, the decay coefficient is restored to activate the parallel processing of non-critical tasks, thereby improving the overall throughput efficiency; this mechanism forms a dependency-sensitive resource rush capability under sudden high loads: it gives priority to guaranteeing the execution of critical path tasks, cuts off invalid resource consumption in the dependency chain (such as low-priority tasks waiting in loops), and makes the completion time of complex dependent task flows no longer affected by loosely coupled tasks. It is especially suitable for the end-to-end timeliness guarantee of cross-node task scheduling under the microservice architecture.

[0187] Furthermore, when adjusting the tasks in each task queue, long-period tasks in each task queue whose execution time exceeds a preset time can be identified in real time; an execution feature matrix of the long-period tasks is constructed, and the execution feature matrix includes CPU occupancy, memory increment and I / O request frequency; based on the correlation between the real-time load parameters and the execution feature matrix, the long-period tasks are classified to obtain classification results; and a resource block pre-allocation strategy is implemented for tasks of the same type according to the classification results.

[0188] In this embodiment, the following implementation scheme can be adopted:

[0189] 1. Real-time identification of long-term tasks

[0190] Dynamic threshold setting:

[0191] Baseline threshold calibration: Based on the historical task execution time distribution (such as P95 time), set the initial recognition threshold (for example, a task that runs continuously for more than 30 minutes is considered a long-term task).

[0192] Adaptive adjustment: When the degree of system resource fragmentation (such as memory fragmentation rate > 40%) or the average queuing delay of short tasks (such as > 500ms) increases, the threshold is automatically lowered (such as adjusted to 20 minutes) to expand the scope of long task recognition.

[0193] Task Status Tracking: Each task is labeled with a timeline, recording the start time, elapsed execution time, and cumulative resource consumption (e.g., CPU seconds, peak memory usage). A resumable counter is enabled for paused / resumed tasks, counting only the actual execution time (excluding interrupt waiting periods).

[0194] 2. Perform feature matrix construction

[0195] Multi-dimensional indicator collection:

[0196] CPU usage: Collect the average value within the sliding window (such as 5-second granularity) and the peak duration ratio (such as >80% usage for 1 minute).

[0197] Memory delta: Compares the memory usage before and after the task is started, distinguishing between resident memory (such as JVM heap memory) and temporary allocations (such as file cache).

[0198] I / O request frequency: counts the number of read and write operations and the average response latency (for example, a disk IOPS greater than 1000 times / second is marked as high I / O load).

[0199] Feature quantization: Normalize metrics (e.g., convert CPU usage to a range of 0-1) to eliminate the impact of hardware differences. Construct a dynamic weight vector to dynamically adjust feature weights based on current system bottlenecks (e.g., increase the memory increment weight to 0.7 when memory is low).

[0200] 3. Dynamic classification of load association

[0201] Classification strategy matching:

[0202] Latency-sensitive: When CPU usage is greater than 85%, long tasks with high CPU usage (e.g., CPU weight greater than 0.6 in the feature matrix) are classified as such and require isolated computing resources.

[0203] Space-compact: When the memory fragmentation rate is greater than 50%, high memory increment tasks (such as single task memory usage > 2GB) are classified and contiguous memory blocks need to be pre-allocated.

[0204] I / O intensive: When the disk IO wait time is greater than 100ms, high I / O frequency tasks (such as IOPS > 800) are classified and need to be bound to a dedicated storage channel.

[0205] Edge scenario processing: For mixed tasks (such as those with high CPU and I / O requirements), primary feature determination is enabled, and the classification corresponding to the most scarce resource in the current system is selected (for example, CPU saturation is classified as latency-sensitive). Conflict detection is performed on the classification results. If a task meets multiple classification conditions simultaneously, it is processed based on priority (latency-sensitive > space-intensive > I / O-intensive).

[0206] 4. Resource block pre-allocation strategy

[0207] Typed resource allocation:

[0208] Latency-sensitive tasks: Pre-allocate exclusive CPU cores (e.g., allocate two physical cores from an elastic resource pool) and prevent other tasks from preempting them. Set a hard limit on the execution time slice (e.g., check progress every 30 minutes). Tasks exceeding the limit will automatically release resources and be demoted to a lower queue.

[0209] Compact space: pre-allocate continuous physical memory blocks (such as 4GB alignment) and mark them as "non-swappable" to prevent paging.

[0210] Enable memory preheating to preload the datasets required for the task (such as database index cache).

[0211] I / O intensive: Bind a dedicated disk queue (such as an NVMe SSD channel) and set the highest I / O priority (such as the RT level of the LinuxCFQ scheduler).

[0212] Pre-allocate large page cache (such as 1GB large page memory) to reduce the fragmentation overhead of small block IO requests.

[0213] Resource recovery mechanism: After a task is completed, a resource release signal is triggered immediately, and pre-allocated resources are returned to the public pool. Automatic resource inspection is enabled for abnormally terminated tasks (such as forced kills), and residual resources are recovered within a maximum of 5 minutes.

[0214] It should be noted that this solution solves the problem of rigid resource allocation and local performance collapse caused by "blindness of resource occupancy of long-cycle tasks" in traditional task scheduling through a resource pre-allocation mechanism driven by long-cycle task characteristics. Long-cycle task identification focuses on task types that have a continuous impact on system load (such as data analysis batch processing and large-scale file transcoding), to avoid obscuring the efficient scheduling window of short tasks due to their long execution cycle and unpredictable resource occupancy; execution feature matrix construction converts the resource consumption mode of tasks (such as CPU intensive, memory resident or I / O blocking) into quantifiable indicators, revealing the implicit occupancy level and fluctuation pattern of system resources by long-cycle tasks; real-time load association classification dynamically adjusts the classification strategy based on the current system status. For example, when the CPU load is saturated, long tasks with high CPU occupancy are classified as "delay sensitive", and independent computing units are pre-allocated first to isolate resource competition. When memory fragmentation is severe, long tasks with high memory requirements are classified as "space-compact" and continuous memory blocks are pre-allocated to reduce paging overhead. The resource block pre-allocation strategy reserves resources in batches based on the characteristics of similar tasks, forming the shortest matching path between resource supply and task demand, avoiding the additional overhead caused by repeated resource application and release during the execution of long-term tasks, and reducing the queuing delay of short tasks by avoiding resource competition. As a result, the system can dynamically cut the resource pool in mixed load scenarios (such as concurrent real-time interactive tasks and long-term tasks), achieving the dual goals of isolated resource supply for long tasks and low-latency response for short tasks, breaking the vicious cycle of "long-tail tasks dragging down the real-time performance of the system."

[0215] Furthermore, the resource block pre-allocation strategy may specifically include: dividing a hot data buffer in a memory allocation unit, establishing a mapping relationship between task type and buffer address; monitoring the frequency of cross-page table access during task execution in real time, and injecting the feature matrix according to time slices; generating an iterative task type classifier based on the updated feature matrix, and reconstructing the mapping relationship between task type and buffer address; when a continuous address access pattern is detected, locating the target buffer according to the reconstructed mapping relationship; dynamically expanding the physical page frame mapping range of the target buffer to an adjacent memory block, and triggering an I / O batch merge operation based on the current cross-page table access frequency threshold.

[0216] In this embodiment, the following implementation scheme can be adopted:

[0217] 1. Hot data buffer division and initial mapping

[0218] Dynamic buffer partitioning: Predict memory access patterns based on task types (such as database transaction processing and image rendering) and create independent hot zones in physical memory (for example, reserving a 2GB buffer for high-concurrency query tasks). A mapping table is established between task type and hot zone addresses, with the initial mapping based on historical access patterns (for example, log analysis tasks are mapped to large page memory by default).

[0219] Elastic adjustment of hot zone capacity: Dynamically scale hot zone size based on real-time task load (e.g., when transaction processing tasks surge, the hot zone expands from 2GB to 4GB), releasing redundant memory to the cold data pool.

[0220] 2. Real-time monitoring and feature injection of cross-page table access

[0221] Access pattern capture: A page table jump counter is embedded in the MMU (memory management unit) to count the number of cross-page accesses within a single task time slice (e.g., sampling every 10ms). The spatial distribution characteristics of cross-page accesses (e.g., sequential access ratio, random access dispersion) are recorded.

[0222] Feature matrix update: Indicators such as cross-page frequency and access dispersion are injected into the feature matrix according to time slices (such as 100ms) and marked as spatiotemporal continuity weights (such as 0-1 interval values).

[0223] 3. Task classifier iteration and mapping relationship reconstruction

[0224] Dynamic classifier training: Based on the spatiotemporal continuity weights in the feature matrix, online machine learning (such as incremental K-means) is used to update the task classification labels (such as "sequential intensive" and "random fragmentation").

[0225] Redirect hot zone mapping based on classification results: For sequentially intensive tasks, their hot zones are moved to memory blocks with continuous physical addresses (e.g., 0x1000-0x5000). For randomly fragmented tasks, hash mapping is used to disperse them to multiple non-contiguous hot zones to reduce cross-page conflicts.

[0226] Mapping validation mechanism: The task memory view is refreshed in real time through the kernel-level page table remapping interface, with latency controlled at the microsecond level.

[0227] 4. Continuous access detection and physical page frame extension

[0228] Continuity determination: When a single task continuously accesses an address range exceeding 50% of the current hot zone (e.g., 2.1MB of continuous access is detected when the hot zone size is 4MB), a page frame extension request is triggered. The availability of adjacent memory blocks is checked, with priority given to idle page frames that are continuous with the physical address of the current hot zone (e.g., 0x5000-0x6000).

[0229] Dynamic expansion execution: Append adjacent page frames to the target hot zone through the memory block merging interface, and update the page table mapping (for example, the hot zone range becomes 0x1000-0x6000 after expansion). Enable the prefetch strategy for the expansion area to preload data pages that may be accessed later (such as the next frame image cache).

[0230] 5. I / O batch merge triggering and execution

[0231] Merge condition determination: When the frequency of cross-page table accesses exceeds a threshold (e.g., a single task crosses pages >1000 times per second) and the hot zone still cannot meet continuity requirements after expansion, I / O merging is triggered. The physical address distribution of cross-page accesses is analyzed to generate a sequence of continuous sector requests (e.g., merging reads and writes from 0x1000-0x2000 and 0x2000-0x3000 into a single operation from 0x1000-0x3000).

[0232] Merge strategy execution: The DMA engine transfers merged data blocks in batches, reducing the number of protocol interactions with the SSD controller (for example, increasing the NVMe command queue depth from 32 to 128). A timeout mechanism is implemented for merge operations: if the latency of a single merge I / O exceeds 50ms, it is automatically split into sub-batches for execution.

[0233] It should be noted that this solution solves the problems of memory locality degradation and I / O efficiency degradation caused by "static paging strategy" and "task access characteristics mismatch" in traditional memory management through a dynamic paging optimization mechanism driven by memory access patterns. The dynamic mapping of hot data buffers strongly associates task types with physical addresses, builds the spatiotemporal continuity of "memory access hotspots" based on real-time access frequency, breaks the randomness of traditional fixed page frame allocation, and reduces TLB misses and memory addressing fragmentation caused by cross-page table jumps; cross-page table access monitoring and feature iteration continuously correct the task classification logic by capturing access patterns within the time slice (such as burst intensive reads or intermittent writes), so that the buffer mapping relationship dynamically adapts to the memory behavior migration during the task execution phase (such as the transition from sequential access to random access), avoiding resource mismatches caused by task phase deviations in static classifiers; continuous access mode triggers page frame extension based on real-time access continuity detection, actively expanding adjacent physical page frames to form continuous memory blocks. , converges access actions that originally spanned multiple discontinuous pages into a local continuous space, significantly reducing the frequency of page fault interrupts and memory bus contention; the I / O batch merging strategy aggregates scattered I / O requests into batch operations (such as merging adjacent sector reads and writes) when the cross-page access frequency exceeds the threshold, and reduces the storage medium's seek latency and protocol interaction overhead by strengthening the access space locality, so that the I / O throughput efficiency and memory access behavior are coordinated and optimized; thereby constructing a memory-storage collaborative acceleration channel, and under the premise of ensuring the security of task memory isolation, through dynamic topology adjustment of physical page frames and intelligent adaptation of I / O scheduling, resolves the "ant colony effect" of long-tail task memory access, and improves the end-to-end execution consistency of data-intensive tasks in high-concurrency scenarios.

[0234] Furthermore, when calling the tasks in each task queue based on a preset task scheduling algorithm in the task pool, the tasks in each task queue may be called based on a priority preemption algorithm in the task pool.

[0235] In this embodiment, the following implementation scheme can be adopted:

[0236] 1. Priority preemption trigger mechanism

[0237] Preemption threshold setting:

[0238] Dynamic sensitivity adjustment: Dynamically set the preemption trigger threshold based on real-time load status (such as the backlog of the high-priority queue) (for example, when the backlog of the high-priority queue exceeds 50 tasks, any low-priority task is allowed to be preempted).

[0239] Task value density judgment: The business rule engine analyzes task metadata (such as user VIP level and transaction amount) and marks high-value tasks that require forced preemption (such as transaction requests with payment amounts greater than 100,000 yuan).

[0240] Preemption condition detection: When a new task is added to the high-priority queue, it immediately checks whether the currently executing low-priority task meets the interruptibility conditions (such as not entering the atomic operation stage and not holding lock resources).

[0241] 2. Preemptive process execution and control

[0242] Resource preemption operation:

[0243] Execution state preservation: Take a context snapshot (such as register status and stack pointer) of the low-priority task, store it in a persistent queue (such as Redis), and mark it as a "resumable task".

[0244] Forced resource release: Immediately reclaim the CPU time slices and memory bandwidth occupied by low-priority tasks, and release the non-critical locks they hold (such as log file handles).

[0245] High-priority task injection: inserts preemption-triggered high-priority tasks to the front of the execution queue, allocates exclusive computing resources (such as reserving 2 CPU cores), and ensures zero-wait startup.

[0246] 3. Isolation and rollback of preempted task resources

[0247] Resource isolation strategy:

[0248] Memory page locking: Memory pages modified by low-priority tasks are marked as "dirty pages" to prevent high-priority tasks from overwriting them (such as through isolation with write-protection bits).

[0249] I / O operation interception: Apply traffic shaping (such as limiting the speed to 10% of the bandwidth) to ongoing low-priority I / O requests (such as batch log writing) to prioritize the I / O channels of high-priority tasks.

[0250] Rollback safety guarantee: If a high-priority task fails to execute, a state rollback is automatically triggered: the low-priority task context is restored from the snapshot and the basic resource quota is reallocated (such as 50% CPU).

[0251] 4. Resource recovery and resuming

[0252] Resource release monitoring:

[0253] Subscription to high-priority task completion events: Real-time notification of resource release signals via message queues (such as Kafka) triggers the resumption of low-priority tasks.

[0254] Resume condition check: Check the integrity of low-priority task snapshots (such as CRC verification) and the availability of dependent resources (such as database connection pool margin).

[0255] Task resuming execution: Resumes task execution from the snapshot point and dynamically reduces its resource usage limit (such as reducing the CPU quota from 30% to 15%) to avoid secondary preemption.

[0256] 5. Preemptive effect monitoring and feedback optimization

[0257] Core indicator monitoring:

[0258] High-priority task response delay: Statistics P99 time from preemption trigger to task completion (target <100ms).

[0259] Low-priority task retransmission loss rate: Calculates the proportion of repeated calculations caused by preemption (such as the data coverage rate when resuming log tasks).

[0260] Dynamic policy tuning: Through the reinforcement learning model, the preemption threshold sensitivity and resource quota allocation ratio are dynamically adjusted according to historical preemption records (such as success rate and number of rollbacks).

[0261] It should be noted that this solution solves the problem of high-priority task response delay and low-priority task resource idling caused by "non-preemptive scheduling" in the traditional task pool through the dynamic intervention mechanism of the priority preemptive algorithm. Although static priority scheduling presets task queue priorities, it lacks preemption capabilities. High-priority tasks must wait for currently executing low-priority tasks to complete, resulting in urgent tasks (such as real-time transaction requests) being blocked by non-critical tasks (such as log backups), leading to priority inversion delays. The priority preemption algorithm empowers high-priority tasks to interrupt the execution of low-priority tasks. By instantly preempting CPU resources, high-value tasks are inserted at the forefront of the execution flow, eliminating inter-queue wait chains and strictly aligning task response timeliness with business value density. This mechanism is particularly critical in sudden high-load scenarios. When the system is flooded with high-priority tasks, preemptive scheduling quickly clears the high-priority queue, resulting in a steep curve in task processing timeliness and avoiding avalanche-like delays in critical business operations caused by queue backlogs. At the same time, preempted low-priority tasks enter a recoverable state and resume execution after resources are released, preventing duplicate computation and resource waste caused by forced termination. This creates a business-value-oriented elastic preemption channel that ensures instantaneous response for high-priority tasks while maintaining resource recoverability for low-priority tasks, achieving a dual leap in system throughput efficiency and business value realization capabilities.

[0262] It should be noted that the technical problems solved by the present invention mainly include task scheduling and allocation, concurrency control, resource management, exception handling and performance optimization. Specifically, they include the following aspects:

[0263] 1. Task Scheduling and Allocation: The task pool needs to implement a task scheduling and allocation mechanism to ensure that tasks are processed according to the predetermined order and priority. This involves technical issues such as task queue management, task priority determination, and task allocation algorithm design.

[0264] 2. Concurrency Control: The task pool needs to limit the number of tasks that can be executed simultaneously to avoid excessive concurrent execution leading to insufficient system resources or performance degradation. This may involve technical issues such as thread pool design and management, and task execution synchronization mechanisms.

[0265] 3. Resource Management: The task pool needs to manage the allocation and release of system resources to ensure that the resources required during task execution are properly utilized and released. This may involve technical issues such as memory management and database connection pool design.

[0266] 4. Exception handling: The task pool needs to capture and handle exceptions during task execution, such as task failure and timeout. This may involve technical issues such as the design of exception handling mechanisms, error logging, and alerting.

[0267] 5. Performance Optimization: The task pool needs to consider how to improve the efficiency and performance of task execution. This involves technical issues such as parallel processing of tasks, optimization of task scheduling algorithms, and rational utilization of resources.

[0268] It should be noted that task pooling is a mechanism for managing and scheduling tasks, and it is widely used in computer science and software engineering. The background of task pooling can be traced back to the development of concurrent programming and multithreading. In traditional single-threaded programming, tasks are typically executed sequentially, with one task completing before the next. However, with the advancement of computer processing power and the prevalence of multi-core processors, executing multiple tasks simultaneously has become a more efficient approach. Task pooling has emerged as a response to this need. It can assign multiple tasks to multiple threads for simultaneous execution, thereby improving system concurrency and execution efficiency. The background of task pooling is also related to system resource management and task scheduling. In a complex system, there may be a large number of tasks requiring execution, and these tasks may have varying priorities and dependencies. By using task pools, the system can better manage and schedule these tasks, ensuring that they are processed according to the predetermined order and priority, avoiding resource waste and task execution disruptions. Furthermore, task pooling is also related to exception handling and system stability. During task execution, various exceptions may occur, such as task failures and timeouts. Task pooling can capture and handle these exceptions, thereby improving the system's fault tolerance and stability. In general, the background of task pool technology can be traced back to the development of concurrent programming and multi-threading technology. It solves problems in task execution concurrency, resource management, task scheduling and exception handling, and improves the efficiency and stability of the system.

[0269] The existing technical solutions are as follows:

[0270] 1. Thread pool: A thread pool is a common task pool implementation. It maintains a set of pre-created threads and uses a task queue to manage pending tasks. The thread pool can dynamically adjust the number of threads as needed, enabling task scheduling and concurrent execution.

[0271] 2. Message Queue: A message queue is a technical solution for asynchronous task processing. It places tasks into a queue, from which consumers retrieve them for processing. Message queues can implement asynchronous task execution, decoupling, and peak load shaving.

[0272] 3. Distributed Task Scheduling Framework: A distributed task scheduling framework is a technical solution for task scheduling and execution in a distributed environment. It can distribute tasks across multiple machines and provide features such as task scheduling, monitoring, and fault recovery.

[0273] The solutions of the embodiments of this specification are as follows:

[0274] The task pool priority technology solution is a mechanism for managing and scheduling tasks, which can reasonably schedule tasks according to their priorities. The following is a detailed explanation of the task pool priority technology solution:

[0275] 1. Definition of task priority:

[0276] First, you need to define the priority of the task. This can be determined based on business needs and task characteristics. Task priorities are represented by numbers from 0 to 9 to indicate different priority levels.

[0277] The priority of a task can be determined based on factors such as its urgency, importance, business needs, etc. to ensure that tasks are processed according to the predetermined priority.

[0278] 2. Task queue management:

[0279] In the task pool, multiple task queues need to be maintained, each queue corresponds to a priority.

[0280] When a new task is added to the task pool, it is placed in the corresponding task queue according to its priority.

[0281] The task queue can use first-in-first-out (FIFO) or other suitable scheduling algorithms to manage the execution order of tasks.

[0282] 3. Task scheduling algorithm:

[0283] In the task pool, a suitable task scheduling algorithm needs to be designed to ensure that high-priority tasks are executed first.

[0284] A common task scheduling algorithm is the priority preemptive algorithm, that is, when a high-priority task arrives, the currently executing low-priority task is suspended and CPU resources are allocated to the high-priority task.

[0285] You can use a priority queue or other data structure to store tasks to be executed and schedule them according to their priority.

[0286] 4. Dynamic priority adjustment:

[0287] In some cases, the priority of tasks may need to be adjusted dynamically, such as based on factors such as system load and user demand.

[0288] Mechanisms can be designed to monitor system status and task execution, and dynamically adjust task priorities based on real-time conditions to adapt to different scenarios and needs.

[0289] 5. Monitoring and management interface:

[0290] The task pool priority technical solution should also provide monitoring and management interfaces to enable real-time viewing of the task pool status and performance indicators.

[0291] It can provide information such as the length of the task queue, the priority distribution of tasks, and the execution status of tasks to facilitate task monitoring and management.

[0292] The key point of the invention of the task pool is to solve the problem of task scheduling and concurrent execution, and improve the efficiency and performance of the system. The key points of the task pool include the following aspects:

[0293] 1. Task Scheduling Algorithm: Design an efficient task scheduling algorithm to ensure that tasks are processed according to the predetermined order and priority. This may involve managing task queues, determining task priorities, and designing task allocation algorithms.

[0294] 2. Concurrency Control Mechanism: Implement appropriate concurrency control mechanisms to limit the number of tasks that can be executed simultaneously, preventing excessive concurrent execution from leading to insufficient system resources or performance degradation. This may involve the design and management of thread pools, as well as synchronization mechanisms for task execution.

[0295] 3. Resource management strategy: Effectively manage the allocation and release of system resources to ensure that the resources required during task execution are properly utilized and released. This may involve memory management, file handle management, database connection pool design, etc.

[0296] 4. Exception handling mechanism: Capture and handle exceptions during task execution, such as task failure, timeout, etc. This may involve the design of exception handling mechanisms, error logging, and alerting.

[0297] The protection points of the task pool mainly include the following aspects:

[0298] 1. Algorithms and Strategies: The task scheduling algorithm and concurrency control mechanism are the core of the task pool. Their design and implementation details need to be protected to ensure the efficiency and stability of the task pool.

[0299] 2. Data security: The task pool may involve the processing of sensitive data, such as task parameters and results. Data security needs to be protected to prevent data leakage or tampering.

[0300] 3. Exception handling: The exception handling mechanism is an important part of the task pool. The exception handling logic and alarm mechanism need to be protected to ensure the fault tolerance and stability of the system.

[0301] 4. Performance optimization: The performance optimization strategy of the task pool may involve optimization and adjustment of the underlying system, and its core ideas and technical details need to be protected.

[0302] The key points of the invention and the points to be protected of the task pool can be further refined and adjusted according to specific application scenarios and needs.

[0303] Compared with thread pools, message queues, and distributed task scheduling frameworks, task pool technology has the following advantages:

[0304] 1. Flexibility: Task pooling technology can be customized and adjusted based on specific needs and system conditions, flexibly adapting to different task processing scenarios. Tasks can be scheduled and managed based on factors such as task type, priority, and dependencies.

[0305] 2. Resource Management: Task pooling technology can better manage the allocation and release of system resources. It can limit the number of tasks that can be executed simultaneously, preventing excessive simultaneous execution from leading to insufficient system resources or performance degradation. Furthermore, task pooling can manage the utilization of system resources, ensuring that resources required during task execution are properly utilized and released.

[0306] 3. Exception Handling: Task pooling technology can capture and handle exceptions during task execution. It can define exception handling mechanisms, such as how to handle exceptions like task failure and timeouts. This exception handling mechanism improves the system's fault tolerance and stability.

[0307] 4. System Performance: Task pooling technology can improve task execution efficiency and overall system performance. It can execute multiple tasks concurrently, fully leveraging the parallelism of multi-core processors. Furthermore, the task pool can schedule tasks based on their priorities and scheduling algorithms, ensuring that high-priority tasks are prioritized, improving system responsiveness and efficiency.

[0308] 5. Scalability: Task pool technology can be expanded and customized based on system requirements. It can dynamically adjust the size of the task pool and resource allocation based on changes in task load to adapt to different system environments and business needs. Furthermore, task pool technology can be combined with other technical solutions, such as thread pools, message queues, and distributed task scheduling frameworks, to further enhance system scalability and flexibility.

[0309] In summary, task pool technology offers greater flexibility, resource management capabilities, exception handling capabilities, system performance, and scalability than thread pools, message queues, and distributed task scheduling frameworks. In terms of task scheduling and management, task pool technology offers more customization and optimization options to better meet the needs of different systems.

[0310] Figure 2 A structural diagram of a task pool priority adjustment device provided in one or more embodiments of this specification includes: a definition unit 201, a calling unit 202, an acquisition unit 203 and an adjustment unit 204.

[0311] A definition unit 201 defines the priority of each task queue in the task pool according to business requirements and task characteristics, wherein the task queue includes multiple tasks;

[0312] The calling unit 202 calls the tasks in each task queue in the task pool based on a preset task scheduling algorithm;

[0313] An acquiring unit 203 acquires real-time load parameters of the designated system;

[0314] The adjusting unit 204 adjusts the tasks in each task queue if the real-time load parameter exceeds a preset threshold.

[0315] Figure 3 A schematic diagram of a task pool priority adjustment device provided for one or more embodiments of this specification includes:

[0316] at least one processor; and,

[0317] a memory communicatively connected to the at least one processor; wherein,

[0318] The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to:

[0319] Defining the priority of each task queue in the task pool according to business requirements and task characteristics, wherein the task queue includes multiple tasks;

[0320] In the task pool, tasks in each task queue are called based on a preset task scheduling algorithm;

[0321] Obtaining real-time load parameters of the specified system;

[0322] If the real-time load parameter exceeds a preset threshold, the tasks in each task queue are adjusted.

[0323] One or more embodiments of this specification provide a non-volatile computer storage medium storing computer-executable instructions. When executed by a computer, the computer-executable instructions can achieve:

[0324] Defining the priority of each task queue in the task pool according to business requirements and task characteristics, wherein the task queue includes multiple tasks;

[0325] In the task pool, tasks in each task queue are called based on a preset task scheduling algorithm;

[0326] Obtaining real-time load parameters of the specified system;

[0327] If the real-time load parameter exceeds a preset threshold, the tasks in each task queue are adjusted.

[0328] The various embodiments in this specification are described in a progressive manner. Similar portions between the various embodiments can be referenced to each other, and each embodiment focuses on the differences from the other embodiments. In particular, the device, apparatus, and non-volatile computer storage medium embodiments are generally similar to the method embodiments, so their descriptions are relatively simplified. For relevant details, refer to the descriptions of the method embodiments.

[0329] The various embodiments in this specification are described in a progressive manner. Similar parts between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences from other embodiments. In particular, the device embodiments are generally similar to the method embodiments, so the description is relatively simple. For relevant parts, refer to the description of the method embodiments.

[0330] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0331] In the embodiments provided in this application, it should be understood that the disclosed devices / network equipment and methods can be implemented in other ways. For example, the device / network equipment embodiments described above are merely illustrative. For example, the division of the modules or units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0332] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0333] In addition, the functional units in the various embodiments of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above units may be implemented in the form of hardware or software.

[0334] If the integrated module / unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application implements all or part of the process in the above-mentioned embodiment method, and can also be completed by instructing the relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium, and when the computer program is executed by the processor, it can implement the steps of the above-mentioned various method embodiments. Among them, the computer program includes computer program code, and the computer program code can be in source code form, object code form, executable file or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium. It should be noted that the content contained in the computer-readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0335] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A task pool priority adjustment method, characterized in that: The method is applied to a specified system and includes: Defining the priority of each task queue in the task pool according to business requirements and task characteristics, wherein the task queue includes multiple tasks; In the task pool, tasks in each task queue are called based on a preset task scheduling algorithm; Obtaining real-time load parameters of the specified system; If the real-time load parameter exceeds a preset threshold, the tasks in each task queue are adjusted.

2. The method according to claim 1, characterized in that The method further comprises: When a new task is added to the task pool, the new task is placed in a corresponding task queue according to the priority of the new task.

3. The method according to claim 1, characterized in that The preset threshold is a dynamic threshold. If the real-time load parameter exceeds the preset threshold, the tasks in each task queue are adjusted, including: Collecting periodic load data of the designated system within a historical time window; Performing Fourier transform analysis on the load data to identify the main frequency fluctuation characteristics of the load in the designated system; An exponential smoothing prediction model is constructed based on the main frequency fluctuation characteristics to dynamically generate load threshold intervals for future time segments; When the real-time load parameter exceeds the load threshold range, the tasks in each task queue are adjusted.

4. The method according to claim 3, characterized in that The adjusting of tasks in each task queue includes: Detect task chains with dependencies in each task queue in real time and generate a task dependency graph; Dynamically calculating the priority attenuation coefficient of each dependent layer according to the degree of deviation from the load threshold interval; The tasks in each task queue are adjusted based on the priority decay coefficient.

5. The method according to claim 1, characterized in that The adjusting of tasks in each task queue includes: Real-time identification of long-term tasks in each task queue that have an execution time exceeding the preset duration; Constructing an execution feature matrix of the long-term task, wherein the execution feature matrix includes CPU occupancy, memory increment, and I / O request frequency; Classifying the long-period tasks based on the correlation between the real-time load parameter and the execution feature matrix to obtain a classification result; A resource block pre-allocation strategy is performed on tasks of the same type according to the classification result.

6. The method according to claim 5, characterized in that The resource block pre-allocation strategy includes: Divide the hot data buffer in the memory allocation unit and establish a mapping relationship between task type and buffer address; Real-time monitoring of the frequency of cross-page table accesses during task execution, and injection of the feature matrix according to time slices; Generate an iterative task type classifier based on the updated feature matrix and reconstruct the mapping relationship between task type and buffer address; When a continuous address access pattern is detected, the target buffer is located according to the reconstructed mapping relationship; The physical page frame mapping range of the target buffer is dynamically extended to the adjacent memory block, and an I / O batch merge operation is triggered according to a current cross-page table access frequency threshold.

7. The method according to claim 1, characterized in that The calling of tasks in each task queue based on a preset task scheduling algorithm in the task pool includes: In the task pool, tasks in each task queue are called based on a priority preemption algorithm.

8. A task pool priority adjustment device, characterized in that: Applicable to specified systems, including: A definition unit, which defines the priority of each task queue in the task pool according to business requirements and task characteristics, wherein the task queue includes multiple tasks; A calling unit, which calls tasks in each task queue in the task pool based on a preset task scheduling algorithm; An acquiring unit, configured to acquire real-time load parameters of the designated system; The adjustment unit adjusts the tasks in each task queue if the real-time load parameter exceeds a preset threshold.

9. A task pool priority adjustment device, characterized in that: Applicable to specified systems, including: at least one processor; and, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to: Defining the priority of each task queue in the task pool according to business requirements and task characteristics, wherein the task queue includes multiple tasks; In the task pool, tasks in each task queue are called based on a preset task scheduling algorithm; Obtaining real-time load parameters of the specified system; If the real-time load parameter exceeds a preset threshold, the tasks in each task queue are adjusted.

10. A non-volatile computer storage medium, characterized in that Applied to a specified system, storing computer-executable instructions that, when executed by a computer, can achieve: Defining the priority of each task queue in the task pool according to business requirements and task characteristics, wherein the task queue includes multiple tasks; In the task pool, tasks in each task queue are called based on a preset task scheduling algorithm; Obtaining real-time load parameters of the specified system; If the real-time load parameter exceeds a preset threshold, the tasks in each task queue are adjusted.

Images