A credit balance-based multi-user computing cluster fair share CPU resource allocation method and system

Abstract

The application relates to a credit balance-based multi-user computing cluster fair share CPU resource allocation method and system, which comprises the following steps: reading user and department configurations, normalizing to calculate the static weight of each user; triggering credit settlement when a job event occurs; for each user in the time interval from the last event time to the current time, calculating a credit increment, applying exponential decay to the historical credit balance, combining the credit increment to obtain an updated credit balance and performing persistent storage; when a job is dequeued, mapping the credit balance of each active user into a multiplicative adjustment factor through a bounded monotonic function to obtain an adjusted effective weight, calculating the expected core number of the user in proportion to the adjusted effective weight; and checking the expected core number based on a dispatch threshold. The application can realize long-term fairness in a multi-user competition scene without preemption or dynamic adjustment of running jobs, and can maintain high resource utilization.

Description

Technical Field

[0001] This invention relates to the field of high-performance computing cluster resource scheduling technology, and to a method and system for allocating fair share CPU resources in a multi-user computing cluster based on credit balance. In particular, it relates to a method and system for allocating fair share CPU resources in a multi-user computing cluster based on credit balance for high-performance computing (HPC) clusters and multi-user workstations. Background Technology

[0002] In high-performance computing clusters and multi-user shared workstation environments, multiple users share limited CPU core resources, and the fairness of resource allocation directly affects system throughput and user experience.

[0003] In multi-user workstations and some internal computing clusters, a common resource management approach is to statically allocate system CPU cores according to the hierarchical weight of the currently logged-in user (department share × user share), with each logged-in user receiving a fixed upper limit on the number of available cores. User login or logout triggers a recalculation of the share. This approach has significant drawbacks: 1) Login immediately occupies a share, leading to wasted idle time: Users who haven't submitted any jobs but remain logged in continuously occupy a share, resulting in a decrease in the number of available cores for active users and low resource utilization; 2) No historical correction capability: Users who submit jobs sequentially receive the same static number of cores, failing to compensate for historical share discrepancies caused by queuing.

[0004] Another approach decomposes the job into a large number of fine-grained, independent computational tasks. The scheduler dynamically allocates worker nodes on a task-by-task basis, achieving near real-time fair reallocation when multiple jobs compete. Because scheduling is done on a task-by-task basis, this approach can allocate cores in near real-time according to share when multiple jobs are concurrent, maintaining high cluster utilization. However, this approach has strict prerequisites: 1) The job must be decomposable: The job must be able to be broken down into a large number of independent, fine-grained tasks (each task can be scheduled and executed independently). If the computation program requests and binds all computational threads at once at process startup, it cannot dynamically adjust the number of cores during runtime, thus failing to meet this prerequisite; 2) It is not suitable for non-preemptible, monolithic jobs: For jobs that exclusively occupy all allocated cores at startup and cannot be dynamically scaled during runtime (such as scientific computing programs that need to initialize large shared memory data structures at process startup), once the job starts, the number of cores it occupies is fixed until completion. The scheduler cannot reclaim allocated cores by reissuing task allocation instructions, therefore the dynamic reallocation mechanism of this approach fails in such scenarios. Summary of the Invention

[0005] Neither of the above two schemes can simultaneously meet the following three requirements: (A) no modification to the job program is required; (B) long-term fairness among multiple users can still be achieved under the constraints of non-preemptive jobs and fixed number of cores; (C) quantitative compensation is provided for historical allocation deviations (over-allocation of cores due to first-come, first-served principle), so that the long-term cumulative core time allocation tends to the static share ratio of each user. In response to this problem, this invention provides a method and system for fair share CPU resource allocation of multi-user computing clusters based on credit balance, specifically providing a method and system for fair share CPU resource allocation of multi-user computing clusters based on credit balance for high-performance computing clusters and multi-user workstations.

[0006] This invention uses the integral of the deviation between the fair share ratio and the actual allocation ratio over time as a credit balance. Combining an exponential decay mechanism and bounded monotonic function modulation, it dynamically adjusts the effective weight of each user at each job scheduling event: users historically under-allocated resources are compensated in subsequent scheduling, while users over-allocated resources are suppressed. Simultaneously, a dispatch threshold mechanism is introduced to prevent non-preemptible jobs from starting with excessively low core counts. This method achieves long-term fairness and maintains high resource utilization in multi-user competition scenarios without preemption or dynamic adjustment of running jobs.

[0007] The first aspect of this invention provides a method for fair allocation of CPU resources in a multi-user computing cluster based on credit balance, comprising the following steps: S1. Read user and department configurations, and calculate the static weight of each user using normalization. S2. Credit settlement is triggered when a job event occurs. Between two adjacent job events, the active user set and the number of cores allocated to each user remain unchanged. S3. For each active user within the time interval from the previous event to the current event, calculate the credit increment, apply exponential decay to the historical credit balance, combine the credit increment to obtain the updated credit balance, and persist it. S4. When a task is dequeued, the credit balance of each active user is mapped to a multiplicative adjustment factor using a bounded monotonic function. The static weights are then corrected using the adjustment factor to obtain the adjusted effective weights. The expected number of cores for that user is calculated proportionally based on the adjusted effective weights. S5. Verify the expected number of cores based on the dispatch threshold; if the number of idle cores meets the minimum core requirement, allocate resources to the job and record the actual number of allocated cores; otherwise, the job remains in the queue waiting until the condition is met or the job is canceled.

[0008] Furthermore, "user" refers to any individual who can submit a job, and in this invention, all users belong to a department; "active user" refers to a user who currently has at least one job prepared, queued, or running.

[0009] Furthermore, the number of idle cores is the number of CPU cores that are currently not occupied by jobs, which is obtained in real time by the cluster scheduling system; the number of idle cores increases when a job completes and releases CPU resources; and the number of idle cores decreases when a job is allocated CPU resources.

[0010] Furthermore, in step S1, the static weights are updated when user or department configurations change, and remain unchanged during scheduling operations; the static weights of each user are calculated using a two-level normalization method based on the department-user hierarchy. in, Indicates user, Indicates the department the user belongs to; For users The static weight represents the user's preset resource allocation weight within the entire cluster; For users The share represents the share value that user has configured within their own department; This represents the sum of the user shares within the same department, specifically the total share values ​​configured for all users within that department. For the department The share represents the department share configured across the entire cluster for the user's department. The sum of the shares of all departments represents the total share value of all departments in the cluster.

[0011] Further, in step S2, the job events include job enqueue events (when a user submits a job, the job enters the scheduling waiting queue and is in a queued state to be run), job dequeue events (when the scheduler removes the job from the waiting queue, allocates computing resources, and the job switches from the queued state to the running state), and job termination events (when a job is completed normally, canceled, or fails to run, the job stops running and releases CPU resources); the job termination events include job completion, job cancellation, and job failure; the active user set is a list of users who have jobs in queue, ready, or running; the number of cores allocated to a user is the number of CPU cores that each user currently actually has and is being used by jobs.

[0012] Further, in step S3, calculating the credit increment includes: calculating the user's fair share ratio and the user's actual allocation ratio, and obtaining the credit increment based on the fair share ratio and the user's actual allocation ratio.

[0013] Furthermore, the credit increment is calculated according to the following formula: calculate: in, For credit increment; For fair share ratio; The actual allocation ratio for users; The actual number of CPU cores allocated to the user; This represents the total number of CPU cores in the entire cluster. The time interval between two consecutive job events; The static weight for all active users; when 0 indicates that the user receives less resources than their fair share, generating positive credit increments for subsequent compensation; when 0 indicates that the user actually receives more resources than their fair share, resulting in a negative credit increment to serve as a punishment and deterrent; when only one active user exclusively uses all CPU cores, The deviation is 0, and no special branching is required.

[0014] Furthermore, in step S3, applying an exponential decay to the historical credit balance, combining it with the credit increment to obtain the updated credit balance, and persistently storing it includes the following steps: Before accumulating credit increments, apply an exponential decay to the existing historical credit balance: in, The remaining credit balance after depreciation; The historical credit balance before the decline; The decay rate per hour (taken as 0.01); The time interval between two consecutive job events; If the attenuation rate is taken into account in the previous credit increment, the credit increment is calculated according to the following formula. calculate: in, For credit increment; For fair share ratio; The actual allocation ratio for users; The decay rate per hour; The event interval between two consecutive operation times; because Therefore, when the attenuation rate When the value is relatively small, the formula With formula The differences are minor, and in practical applications, they can be determined according to... The value of the formula determines which calculation formula to use. The decreased credit balance is then added to the credit increment to obtain the updated credit balance: ; The updated credit balance will be persistently stored along with a timestamp; and When the scheduling service restarts, it uses the stored timestamps to lazily calculate the exponential decay and restore the user's credit status.

[0015] Furthermore, the aforementioned Configuration: Increasing the size makes the system more sensitive to recent behavior and accelerates historical forgetting; Reducing the size allows historical records to be retained longer, making it suitable for scenarios with higher long-term fairness requirements.

[0016] Furthermore, in step S4, the bounded monotonic function is any one of the following: the tanh function, the generalized sigmoid function, or the piecewise linear truncation function.

[0017] Furthermore, the bounded monotonic function is the Sigmoid function. At that time, its upper and lower limits , Independent configuration to achieve asymmetric reward / penalty magnitudes, shape parameters Adjusting the asymmetry of the saturation rates on both sides, center offset By neutral conditions Confirmed; when the bounded monotonic function is a piecewise linear truncation function. The computational cost is lower. All three exhibit equivalent steady-state behavior; the only difference lies in the smoothness at the boundaries.

[0018] Further, in step S4, when the job is dequeued, the credit balance of each active user is mapped to a multiplicative adjustment factor through a bounded monotonic function. The static weights are then corrected using the adjustment factor to obtain the adjusted effective weights. The expected number of cores for the user is calculated proportionally using the adjusted effective weights, including the following steps: Input the user's credit balance into a bounded monotonic function to obtain intermediate variables. ; When the bounded monotonic function is the tanh function, according to Calculate the multiplication adjustment factor for each branch if it is greater than or equal to 0 or less than 0. : Where k is the sensitivity coefficient; The user's current credit balance (taken as 0.5); in, To adjust the upper and lower limits of the factor; Adjustment factor to upper limit when for positive credit Smooth convergence achieves resource compensation; When the credit rating is negative, the adjustment factor should be lowered to the lower limit. Smooth convergence, implementing occupancy penalty; The adjusted effective weights are obtained by correcting the static weights using adjustment factors: in, For effective weights; and The user's expected number of cores is calculated proportionally using the adjusted effective weights: in, The desired number of cores; The effective weight for all active users; The total number of CPU cores that can be allocated to the cluster.

[0019] Furthermore, the initial credit value for new users: the default initial value is 0 (a fair starting point); it can also be initialized based on the department's average credit value to adapt to different compensation strategies. The initial credit value for new users is... The initial value of .

[0020] Furthermore, in step S5, verifying the expected number of cores based on the distribution threshold includes the following steps: Minimum core count required: in, This is the minimum core count requirement; The distribution threshold ratio is set to 0.5. like Then, jobs will be allocated without exceeding the number of available cores. Each core is recorded, and the actual number of cores allocated is recorded. For subsequent credit settlement; and Otherwise, the job remains at the head of the queue, and the scheduler re-verifies it at fixed time intervals until the conditions are met or the user cancels it.

[0021] Furthermore, the aforementioned Configuration: When the threshold approaches 0, it degenerates into no threshold protection; When the number of cores approaches 1, the system requires all expected cores to be obtained before it can be started, which increases the waiting time accordingly.

[0022] A second aspect of the present invention provides a fair share CPU resource allocation system for a multi-user computing cluster based on credit balance, for implementing the above method, the system comprising: The static share module is configured to load user and department configurations, normalize them at the department and user levels, calculate and cache the static weight of users; The credit management module is configured to respond to job events and complete credit increment calculation, credit balance index decay credit settlement processing; The scheduling decision module is configured to calculate the credit adjustment factor, effective weight, and expected number of cores when a job is dequeued, and to continue distributing the threshold for verification; and The persistence module is configured to store user credit balances and timestamps, enabling data persistence and supporting lazy recovery of credit status after service restart.

[0023] This invention defines resource contention participants based on their active job status (Pending, InProgress, Preparing) rather than their login status, and maintains a credit balance for each user. The credit balance is mathematically defined as the integral of the deviation between the fair share ratio and the actual allocation ratio over time, measured in ratio-hours, and is independent of the number of machine cores. In the engineering implementation of cluster scheduling, a discrete-time slice summation method is used to approximate the numerical integral: within each settlement time interval... Calculate the deviation value internally, and then... Multiply by the length of the time interval to obtain the credit increment. Regarding credit balance This credit increment is continuously accumulated, thus effectively performing an integral calculation. Each time a scheduling event occurs: first, press... (Right now Settle the credit of the previous interval and apply exponential decay; when the job is dequeued, map the credit balance to a multiplicative adjustment factor through a bounded monotonic function, modulate the user's static weight, and then allocate the number of cores proportionally; finally, check the number of idle cores with the distribution threshold to decide whether the job should start immediately or continue to wait.

[0024] The overall scheduling process is as follows: job event (enqueue / dequeue / complete / cancel) → credit settlement (attenuation + deviation integral) → credit adjustment core number calculation → dispatch threshold verification → start job and record the actual number of cores allocated.

[0025] This invention has at least the following beneficial effects: 1) A deviation integral credit mechanism based on ratio-hours: Credit is defined as the fair share ratio minus the integral of the actual allocation ratio over time, which can be positive or negative, supporting both positive compensation for under-allocated users and negative suppression for over-allocated users; and since both ratios are dimensionless, the same set of formulas and parameters applies to machines of any core size without recalibration; 2) Applying exponential decay to the credit balance itself: smoothing out the impact of historical unfairness and avoiding permanent interference from long-term records with current scheduling; decay uses a lazy compensation method, facilitating persistence and service restart recovery; 3) Mapping credit to a multiplicative adjustment factor of static weights through a bounded monotonic function, directly affecting core allocation: adjustment factor Centered on 1, Internal bidirectional smooth saturation, with independent configurable upper and lower limits; the modulated effective weights, after normalization, directly determine the number of cores allocated to each user; 4) Distribution threshold oriented towards non-preemptive constraints: only when the number of idle cores is not less than the expected number of cores. The program is only allowed to start when the number of cores is doubled, to avoid the program starting with too few cores and running at low speed throughout. Detailed Implementation

[0026] In this invention, the various embodiments are merely intended to illustrate the solutions of the invention and should not be construed as limiting.

[0027] In this invention, unless otherwise specified, the quantifiers “a” and “one” do not exclude scenarios involving multiple elements.

[0028] It should also be noted that, in the embodiments of the present invention, only a portion of the parts or components may be shown for clarity and simplicity. However, those skilled in the art will understand that, under the teachings of the present invention, the required parts or components can be added as needed for specific scenarios.

[0029] It should also be noted that within the scope of this invention, the terms "same", "equal", and "equal to" do not mean that the two values ​​are absolutely equal, but allow for a certain reasonable error. In other words, the terms also cover "substantially the same", "substantially equal", and "substantially equal to".

[0030] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0031] Furthermore, the embodiments of the present invention describe the process steps in a specific order. However, this is only for the convenience of distinguishing each step, and is not a limitation on the order of each step. In different embodiments of the present invention, the order of each step can be adjusted according to the process.

[0032] The following embodiments provide a method for fair allocation of CPU resources in a multi-user computing cluster based on credit balance, including the following stages and steps: Phase 1: Static Share Initialization S1. Retrieve user and department configurations from the database, and calculate the static weight of each user according to the two-level normalization of department and user: in, Indicates user, Indicates the department the user belongs to; For users The static weight represents the user's preset resource allocation weight within the entire cluster; For users The share represents the share value that user has configured within their own department; This represents the sum of the user shares within the same department, specifically the total share values ​​configured for all users within that department. For the department The share represents the department share configured across the entire cluster for the user's department. The sum of the shares of all departments represents the total share value of all departments in the cluster; the static weight is only updated when the user or department configuration changes, and remains unchanged during the scheduling operation.

[0033] Phase Two: Event-Driven Credit Settlement S2. Credit settlement is triggered when a job enqueueing event, a job dequeueing event (start of execution), or a job ending event (job completion, job cancellation, job failure) occurs. Between two adjacent job events, the active user set and the number of cores allocated to each user remain unchanged. Therefore, the fair ratio and the actual ratio are constant within the interval, and the deviation integral is exactly equal to the area of ​​a single rectangle, requiring no numerical integration. The job event includes the active user set, which is a list of users who have queued, ready, or running jobs. The number of cores allocated to each user is the number of CPU cores that each user currently actually has and is being used by jobs.

[0034] S3. For each active user within the time interval ([previous event time, current time]) from the previous event time to the current event time, calculate the user's fair share ratio and the user's actual allocation ratio, and obtain the credit increment based on the fair share ratio and the user's actual allocation ratio. The credit increment is calculated according to the following formula. calculate: in, For credit increment; For fair share ratio; The actual allocation ratio for users; The actual number of CPU cores allocated to the user; This represents the total number of CPU cores in the entire cluster. The time interval between two consecutive job events; The static weight for all active users; when 0 indicates that the user receives less resources than their fair share, generating positive credit increments for subsequent compensation; when A deviation of 0 indicates that the user actually receives more resources than their fair share, resulting in a negative credit increment to mitigate the penalty. A positive deviation means the user receives fewer resources than their fair share (accumulated compensation), while a negative deviation means they receive more than their fair share (accumulated penalty). When only one active user exclusively controls all CPU cores... The deviation is equal to 0, requiring no special branching; an exponential decay is applied to the historical credit balance, and the updated credit balance is obtained by combining it with the credit increment and persistently stored. Before accumulating credit increments, apply an exponential decay to the existing historical credit balance: in, The remaining credit balance after depreciation; The historical credit balance before the decline; The decay rate per hour (taken as 0.01); The time interval between two consecutive job events; If the attenuation rate is taken into account, the credit increment is calculated according to the following formula. calculate: in, For credit increment; For fair share ratio; The actual allocation ratio for users; The decay rate per hour; The event interval between two consecutive operation times; because Therefore, when the attenuation rate When the value is relatively small, the formula With formula The differences are minor, and in practical applications, they can be determined according to... The value of the formula determines which calculation formula to use. The decreased credit balance is then added to the credit increment to obtain the updated credit balance: ; The updated credit balance will be persistently stored along with a timestamp; and When the scheduling service restarts, the user's credit status is restored by lazily calculating the exponential decay based on the stored timestamps; the decay ensures that the impact of historical deviations fades over time. The settled credit balance (decayed balance + Δcredit) along with the updated timestamps is persisted to the database; after the service restarts, the user can be restored simply by lazily calculating the decay based on the stored timestamps, without requiring an additional recovery process.

[0035] Phase 3: Credit Adjustment Allocation S4. When a task is dequeued, the credit balance of each active user is mapped to a multiplication adjustment factor using a bounded monotonic function: Input the user's credit balance into a bounded monotonic function to obtain intermediate variables. ; When a bounded monotonic function is a tanh function, according to Calculate the multiplication adjustment factor for each branch if it is greater than or equal to 0 or less than 0. : Where k is the sensitivity coefficient; The user's current credit balance (taken as 0.5); in, To adjust the upper and lower limits of the factor, they are configured independently (this implementation takes...). =1.5、 =0.6, meaning the effective weight is 60%~150% of the static share), which can achieve asymmetric reward and punishment. When credit is zero... The allocation degenerates into a purely static share ratio; When the credit rating is positive, the adjustment factor is moved to the upper limit. Smooth convergence achieves resource compensation; When the credit rating is negative, the adjustment factor should be lowered to the lower limit. Smooth convergence, implementing occupancy penalty; The adjusted effective weights are obtained by correcting the static weights using adjustment factors: in, Effective weights; The user's expected number of cores is calculated proportionally using the adjusted effective weights: The user's expected number of cores is calculated proportionally using the adjusted effective weights: in, The desired number of cores; The effective weight for all active users; The total number of CPU cores that can be allocated to the cluster. The result is constrained by... Within the range. Initial credit value for new users: The default initial value is 0 (fair starting point); it can also be initialized based on the department's average credit value to adapt to different compensation strategies. The initial credit value for new users is... The initial value of .

[0036] Phase 4: Distribution Threshold Verification and Actual Allocation Records S5. Before starting the job, check the number of idle cores and verify the expected number of cores based on the dispatch threshold: Minimum core count required: in, This is the minimum core count requirement; The distribution threshold ratio is set to 0.5. like Then, jobs will be allocated without exceeding the number of available cores. Each core is recorded, and the actual number of cores allocated is recorded. For subsequent credit settlement; and Otherwise, the job remains at the head of the queue, and the scheduler re-verifies at fixed time intervals until the conditions are met or the user cancels. This mechanism ensures that non-preemptible jobs receive at least θ times the expected number of cores each time they start, avoiding long-term low-speed operation with very few cores; at the same time, since the actual allocated number of cores (not the expected number of cores) is recorded, users who are compressed and started due to insufficient cores will automatically receive subsequent compensation in the credit dimension.

[0037] In some embodiments, Configuration: Increasing the size makes the system more sensitive to recent behavior and accelerates historical forgetting; Reducing the size allows historical records to be retained longer, making it suitable for scenarios with higher long-term fairness requirements.

[0038] In some embodiments, Configuration: When the threshold approaches 0, it degenerates into no threshold protection; When the number of cores approaches 1, the system requires all expected cores to be obtained before it can be started, which increases the waiting time accordingly.

[0039] In some embodiments, the bounded monotonic function can also be replaced by either the generalized Sigmoid function or the piecewise linear truncation function: A bounded monotonic function is the Sigmoid function. At that time, its upper and lower limits , Independent configuration to achieve asymmetric reward / penalty magnitudes, shape parameters Adjusting the asymmetry of the saturation rates on both sides, center offset By neutral conditions Determined; when a bounded monotonic function is a piecewise linear truncation function The computational cost is lower. All three exhibit equivalent steady-state behavior; the only difference lies in the smoothness at the boundaries.

[0040] This embodiment also provides a fair share CPU resource allocation system for a multi-user computing cluster based on credit balance, used to implement the above method. The system includes: The static share module is configured to load user and department configurations, normalize them at the department and user levels, calculate and cache the static weight of users; The credit management module is configured to respond to job events and complete credit increment calculation, credit balance exponential decay credit settlement processing (maintaining the credit balance of each user, and performing event-driven deviation integration and exponential decay). The scheduling decision module is configured to calculate the credit adjustment factor, effective weight, and expected number of cores when a job is dequeued, and to continue distributing the threshold for verification; and The persistence module is configured to store user credit balances and timestamps, enabling data persistence and supporting lazy recovery of credit status after service restart.

[0041] While some embodiments of the present invention have been described in this application, those skilled in the art will understand that these embodiments are merely illustrative. Numerous variations, alternatives, and improvements will arise in those skilled in the art under the teachings of this invention without departing from its scope. The appended claims are intended to define the scope of the invention and thereby cover methods and structures within the scope of the claims themselves and their equivalents.

Claims

1. A method for allocating fair share CPU resources in a multi-user computing cluster based on credit balance, characterized in that, Includes the following steps: S1. Read user and department configurations, and calculate the static weight of each user using normalization. S2. Credit settlement is triggered when a job event occurs. Between two adjacent job events, the active user set and the number of cores allocated to each user remain unchanged. S3. For each user within the time interval from the previous event to the current event, calculate the credit increment, apply exponential decay to the historical credit balance, combine the credit increment to obtain the updated credit balance, and persist it. S4. When the job is dispatched, the credit balance of each active user is mapped to a multiplication adjustment factor through a bounded monotonic function. The static weight is corrected using the adjustment factor to obtain the adjusted effective weight. The expected number of cores for the user is calculated proportionally based on the adjusted effective weight. as well as S5. Verify the expected number of cores based on the dispatch threshold; if the number of idle cores meets the minimum core requirement, allocate resources to the job and record the actual number of allocated cores; otherwise, the job remains in the queue waiting until the condition is met or the job is canceled.

2. The method for fair share CPU resource allocation in a multi-user computing cluster based on credit balance as described in claim 1, characterized in that, In step S1, the static weights are updated when user or department configurations change and remain unchanged during scheduling operations; the static weights for each user are calculated using a two-level normalization method based on the department-user hierarchy. in, Indicates user, Indicates the department the user belongs to; For users The static weight represents the user's preset resource allocation weight within the entire cluster; For users The share represents the share value that user has configured within their own department; This represents the sum of the user shares within the same department, specifically the total share values ​​configured for all users within that department. For the department The share represents the department share configured across the entire cluster for the user's department. The sum of the shares of all departments represents the total share value of all departments in the cluster.

3. The method for fair share CPU resource allocation in a multi-user computing cluster based on credit balance according to claim 1, characterized in that, In step S2, the job events include job enqueue events, job dequeue events, and job end events; the job end events include job completion, job cancellation, and job failure; the active user set is a list of users who have jobs in queue, ready, or running; the number of cores allocated to each user is the number of CPU cores that each user currently has and is being used by jobs.

4. The method for fair share CPU resource allocation in a multi-user computing cluster based on credit balance according to claim 1, characterized in that, In step S3, calculating the credit increment includes: calculating the user's fair share ratio and the user's actual allocation ratio, and obtaining the credit increment based on the fair share ratio and the user's actual allocation ratio.

5. The method for fair share CPU resource allocation in a multi-user computing cluster based on credit balance according to claim 1, characterized in that, The credit increment is calculated according to the following formula: calculate: in, For credit increment; For fair share ratio; The actual allocation ratio for users; The actual number of CPU cores allocated to the user; This represents the total number of CPU cores in the entire cluster. The time interval between two consecutive job events; The static weight for all active users; when 0 indicates that the user receives less resources than their fair share, generating positive credit increments for subsequent compensation; when 0 indicates that the user actually obtains more resources than the fair share, resulting in a negative credit increment to achieve punishment and suppression; when only one active user monopolizes all CPU cores, the deviation is equal to 0, and no branch processing is required.

6. The method for fair share CPU resource allocation in a multi-user computing cluster based on credit balance according to claim 1, characterized in that, In step S3, applying an exponential decay to the historical credit balance and combining it with the credit increment to obtain the updated credit balance and persistently storing it includes the following steps: Before accumulating credit increments, apply an exponential decay to the existing historical credit balance: in, The remaining credit balance after depreciation; The historical credit balance before the decline; The decay rate per hour; The time interval between two consecutive job events; If the attenuation rate is taken into account, the credit increment is calculated according to the following formula. calculate: in, For credit increment; For fair share ratio; The actual allocation ratio for users; The decay rate per hour; The event interval between two consecutive operation times; The decreased credit balance is then added to the credit increment to obtain the updated credit balance: ； The updated credit balance will be persistently stored along with a timestamp; and When the scheduling service restarts, it uses the stored timestamps to lazily calculate the exponential decay and restore the user's credit status.

7. The method for fair share CPU resource allocation in a multi-user computing cluster based on credit balance according to claim 1, characterized in that, In step S4, the bounded monotonic function is any one of the following: tanh function, generalized sigmoid function, or piecewise linear truncation function.

8. The method for fair share CPU resource allocation in a multi-user computing cluster based on credit balance according to claim 7, characterized in that, In step S4, when a job is dequeued, the credit balance of each active user is mapped to a multiplicative adjustment factor using a bounded monotonic function. The static weights are then corrected using the adjustment factor to obtain the adjusted effective weights. The expected number of cores for the user is calculated proportionally using the adjusted effective weights, including the following steps: Input the user's credit balance into a bounded monotonic function to obtain intermediate variables. ; When the bounded monotonic function is the tanh function, according to Calculate the multiplication adjustment factor for each branch if it is greater than or equal to 0 or less than 0. : Where k is the sensitivity coefficient; This refers to the user's current credit balance. in, To adjust the upper and lower limits of the factor; Adjustment factor to upper limit when for positive credit Smooth approach; When the credit rating is negative, the adjustment factor should be lowered to the lower limit. Smooth approach; The adjusted effective weights are obtained by correcting the static weights using adjustment factors: in, For effective weights; and The user's expected number of cores is calculated proportionally using the adjusted effective weights: in, The desired number of cores; The effective weight for all active users; The total number of CPU cores that can be allocated to the cluster.

9. The method for fair share CPU resource allocation in a multi-user computing cluster based on credit balance according to claim 1, characterized in that, Step S5, verifying the expected number of cores based on the distribution threshold, includes the following steps: Minimum core count required: in, This is the minimum core count requirement; This is the distribution threshold ratio; like Then, jobs will be allocated without exceeding the number of available cores. Each core is recorded, and the actual number of cores allocated is recorded. For subsequent credit settlement; and Otherwise, the job remains at the head of the queue, and the scheduler re-verifies it at fixed time intervals until the conditions are met or the user cancels it.

10. A fair share CPU resource allocation system for a multi-user computing cluster based on credit balance, characterized in that, The system for implementing the method according to any one of claims 1-9, the system comprising: The static share module is configured to load user and department configurations, normalize them at the department and user levels, calculate and cache the static weight of users; The credit management module is configured to respond to job events and complete credit increment calculation, credit balance index decay credit settlement processing; The scheduling decision module is configured to calculate the credit adjustment factor, effective weight, and expected number of cores when a job is dequeued, and to continue distributing the threshold for verification; and The persistence module is configured to store user credit balances and timestamps to achieve data persistence.

Images