Server multi-core computing processor load optimization test method, device and equipment and medium

Abstract

The invention relates to the technical field of server testing, in particular to a server multi-core computing processor load optimization testing method, device and equipment and a medium, and the method comprises the following steps: automatically identifying hardware configuration information of a server; generating a multi-dimensional pressure test plan based on the hardware configuration information; executing the test plan, and monitoring the load rate, the memory bandwidth, the cache hit rate and the I / O performance index of each CPU core in real time; dynamically adjusting a task allocation strategy based on a set load difference threshold to realize task dynamic optimization, and if the difference between the maximum core load rate and the minimum core load rate is monitored to exceed the threshold, triggering a task migration operation; system performance data are collected again, performance indexes before and after optimization are compared and analyzed, and system performance bottlenecks are recognized; and automatically generating a performance test report. The utilization rate and the overall task throughput of the multi-core processor are improved, and the problem that a static task allocation strategy is difficult to adapt to dynamic load changes is solved.

Description

Technical Field

[0001] This application relates to the field of server testing technology, specifically to a processor load optimization testing method, apparatus, equipment, and medium for multi-core server computing. Background Technology

[0002] ARM64 architecture servers have seen increasingly widespread application in high-performance computing, cloud computing, and big data processing in recent years, with significant advantages including high multi-core integration, excellent energy efficiency, and strong horizontal scalability. With advancements in chip manufacturing processes, a single ARM64 processor can integrate dozens or even hundreds of computing cores, providing a powerful hardware foundation for high-concurrency task processing. However, the dramatic increase in the number of cores has also significantly increased the complexity of system task scheduling and load distribution. When handling large-scale parallel computing tasks or mixed workloads, the rationality of the task allocation strategy directly determines the extent to which the overall system performance is realized. Uneven task distribution can lead to some computing cores being overloaded for extended periods, while other cores remain idle or lightly loaded. This load imbalance will cause a decrease in overall system throughput and a prolonged task response time, thus failing to fully utilize the potential performance of the ARM64 server's multi-core architecture.

[0003] Currently, mainstream operating systems (such as Linux) typically employ general-purpose scheduling algorithms like the Completely Fair Scheduler (CFS) to achieve load balancing across multiple cores. ARM64 multi-core processors often feature complex cache hierarchy structures (such as L1 / L2 / L3 caches) and Non-Uniform Memory Access (NUMA) architectures. Especially in multi-processor servers, memory access latency across NUMA nodes is significantly higher than intra-node access latency. When deciding on task migration, general-purpose schedulers often lack sufficient consideration for cache affinity and NUMA affinity, easily leading to frequent cache misses and remote memory accesses. In high-concurrency computing and mixed-load scenarios, this can introduce additional performance overhead, creating new performance bottlenecks.

[0004] Therefore, existing performance testing tools mostly focus on collecting performance metrics from a single dimension, and cannot dynamically perceive architectural characteristics and implement targeted load adjustments during the testing process, making it difficult to effectively verify and optimize the performance of different task scheduling strategies in real complex scenarios. Summary of the Invention

[0005] To address the aforementioned issues, this invention provides a method, apparatus, device, and medium for optimizing processor load in multi-core server computing.

[0006] In a first aspect, the present invention provides a processor load optimization testing method based on server multi-core computing. The method is executed through an automated testing platform, forming a closed-loop process encompassing testing, optimization, and verification, and includes the following steps: S1. Automatically identify the server's hardware configuration information, including the number of CPU cores, cache hierarchy, and CPU topology. S2. Based on the hardware configuration information, generate a multi-dimensional stress test plan covering the CPU, memory, and I / O subsystems. The test plan includes test tasks simulating compute-intensive, I / O-intensive, and mixed loads. S3. Execute the test tasks in the test plan and monitor the load rate, memory bandwidth, cache hit rate and I / O performance indicators of each CPU core in real time. S4. Based on the real-time monitored load rate of each core, dynamically adjust the task allocation strategy according to the set load difference threshold to achieve dynamic task optimization. If the difference between the maximum core load rate and the minimum core load rate exceeds the threshold, trigger the task migration operation to migrate the tasks on the core with a load rate greater than the first threshold to the core with a load rate less than the second threshold, so as to achieve load balancing among multiple cores. S5. After performing dynamic optimization in S4, re-collect system performance data, compare and analyze the performance indicators before and after optimization, and identify system performance bottlenecks. S6. Automatically generate a performance test report, which includes a load distribution chart, performance metric statistics, and system optimization suggestions based on the analysis in S5.

[0007] As a further definition of the inventive technical solution, step S1 includes: S11. By parsing the / proc / cpuinfo file under the Linux system, obtain the identifier, physical core ID and physical package ID of each logical core, and calculate the total number of physical CPU cores and the total number of logical CPU cores. S12. By parsing the files in the directory / sys / devices / system / cpu / cpuX / cache / indexY / , where X is the CPU number and Y is the cache level index, the size, type, and shared topology of each cache level are obtained. S13. Obtain the number of nodes in the non-uniform memory access architecture, the list of CPU cores in each node, and the node memory distribution information by parsing the / sys / devices / system / node / directory or by using the numactl --hardware command. S14. Integrate the information obtained from S11-S13 to construct a complete hardware topology diagram that reflects the relationships between physical packaging, cores, threads, cache sharing, and NUMA node affiliation.

[0008] The information acquisition method used is the standard interface of the Linux system. The method is reliable and universal, avoiding the limitations caused by relying on specific hardware tools and ensuring the accuracy of the recognition results.

[0009] As a further definition of the inventive technical solution, step S2 includes: S21. Generate a CPU stress test plan; including: Generate a computationally intensive task and bind it to a specified CPU core to run, for testing single-core peak performance; Generate a set of computationally intensive tasks and bind them to a set of cores that share the same level of cache, as determined by the topology, to run on, in order to test the efficiency of collaborative computing within the cache-shared domain; Generate parallel computing tasks equal to the total number of logical CPU cores, bringing all cores to a preset high-load state, in order to test the overall parallel computing throughput of the system. S22. Generate a memory bandwidth test plan; including: Generate tasks that perform large-scale sequential memory read and write operations to test the bandwidth of sequential memory access; Generate tasks that perform large-scale random memory read and write operations to test memory random access latency and bandwidth; Multiple concurrent memory access tasks are generated and distributed to different nodes according to the NUMA node topology to run, in order to test the performance of concurrent memory access across NUMA nodes; S23. Generate an I / O stress test plan; including: Generate tasks that perform sequential read / write of large files and random read / write of small files to test disk read / write throughput and IOPS; Generate network packet sending and receiving tasks to test network bandwidth and communication latency.

[0010] S24. Based on the test objectives, combine the different types of test tasks generated in S21 to S23 and execute them concurrently to simulate real mixed load scenarios.

[0011] By designing CPU tests at different levels, including single-core, cache-domain multi-core, and all-core tests, as well as memory tests considering NUMA nodes, we can accurately evaluate the performance of multi-core servers such as ARM64 under specific topologies, revealing architecture-related bottlenecks that are difficult to detect with general testing. By flexibly combining different types of basic test tasks, we can highly simulate mixed load scenarios in real-world business operations, making the test results more valuable.

[0012] As a further definition of the inventive technical solution, step S3 includes: S31. Call the operating system interface or use containerization technology to create an independent execution environment for each test task generated in S21-S23 to ensure that the test tasks do not interfere with each other; execute the various tasks in S24 concurrently. S32. During the execution of the test task, the following performance metrics are collected in parallel using a periodic sampling method: Calculate the time utilization of each logical core within the sampling period by reading the / proc / stat file or using the psutil library; The system-level and NUMA node-level memory read / write bandwidth can be obtained by reading the / proc / meminfo file and calculating the changes in active memory pages within a specific interval, or by using the perf performance counter tool. By reading the hardware event counters provided by the perf performance counter tool, the number of accesses and misses of each level of cache can be obtained, and the cache hit rate can be calculated. By reading the / proc / diskstats and / proc / net / dev files, the read / write throughput, IOPS, and receive / transmit throughput of the network interface are calculated for the disk device. S33. Add a unified timestamp to all performance metrics data collected in each sampling period, and associate the monitoring data with the type and intensity of the currently executing test task to form a structured performance log with time context.

[0013] By creating independent execution environments for each task, mutual interference between test tasks is avoided, ensuring that the collected performance data accurately reflects the system state under specific loads. Parallel sampling using standard interfaces and performance tools provided by the operating system enables comprehensive acquisition of key system metrics with minimal performance overhead. Timestamp alignment and task association create structured logs with complete context, allowing subsequent analysis to accurately correlate performance changes with specific test activities, significantly improving the accuracy of bottleneck identification.

[0014] As a further limitation of the invention's technical solution, S4 dynamically adjusts the task allocation strategy based on a set load difference threshold, specifically including the following steps: S41. In each monitoring sampling period, calculate the absolute difference between the maximum core load rate and the minimum core load rate among all logical cores; when the absolute difference continues to exceed the preset load difference threshold for N consecutive sampling periods, the system is determined to be in a state of unbalanced load and a task migration operation is triggered. S42. Cores with a load rate higher than the first threshold are identified as source cores for tasks to be migrated out; the first threshold is the sum of the system average load rate and the preset offset; From cores with a load rate lower than the second threshold, target cores are selected based on proximity, with the following priority order: The core shares the last-level cache with the source core; The core that resides within the same NUMA node as the source core; The remaining cores on the other NUMA nodes; The second threshold is equal to the overall average load rate of the system during the current sampling period; S43. For the selected source core and target core, migrate one or more specified test tasks currently running on the source core in user space from the source core to the target core. S44. Within M sampling periods after the task migration operation is completed, continuously monitor the absolute difference; if the absolute difference drops below the load difference threshold, the optimization is deemed effective; otherwise, record the optimization failure and re-execute steps S41 to S43 in the next period.

[0015] By employing a criterion of exceeding a threshold for N consecutive cycles, false triggers caused by instantaneous load fluctuations are effectively avoided. Quantifying high / low loads into thresholds related to the system's average load reduces performance degradation during migration. Through a post-migration effect verification mechanism, the system can self-evaluate the effectiveness of optimization actions and provide feedback for subsequent decisions.

[0016] As a further definition of the inventive technical solution, step S5 includes: S51. One sampling period before the task migration operation is triggered in S41, record a baseline snapshot of the system performance indicators; after the task migration is completed and the system is running stably, record an optimized snapshot of the system performance indicators for K consecutive sampling periods; the performance indicators include at least the load rate of each CPU core, the overall system throughput, and the average task latency. S52. Compare the mean of the baseline snapshot and the optimized snapshot, and calculate the change in key performance indicators, including: Calculate the standard deviation of the load rate between cores before and after optimization. A decrease in the standard deviation indicates an improvement in load balance. Calculate the rate of change of system throughput; Calculate the average task delay rate of change; S53. Based on the calculation results of step S52, and combined with the resource indicators monitored in S3, bottlenecks are located: If the load balancing improves and the positive throughput change rate of the system is greater than the third threshold, then the task dynamic optimization of S4 is deemed effective for the current test scenario, and the previous bottleneck was mainly the unbalanced task scheduling. If the load is balanced but the system throughput change rate is within the fourth threshold range, and the cache hit rate is less than the fifth threshold, then the system is determined to have a cache locality problem, and task migration has caused too many cache invalidations. If the load is balanced but the rate of change of the system's positive throughput is less than the sixth threshold, and there is an increase in memory latency of NUMA nodes, then it is determined that task migration has introduced performance loss of cross-NUMA node memory access. If the system CPU load is balanced and the utilization rate is higher than the set value, but the overall throughput is still lower than the preset value, then based on the I / O monitoring data, it is determined that the system bottleneck is disk I / O or network bandwidth.

[0017] By analyzing the relationships between various metrics such as load balancing, throughput, cache hit rate, and NUMA latency, it is possible to accurately distinguish whether performance bottlenecks stem from uneven scheduling, cache invalidation, cross-NUMA access, or I / O limitations, providing a much deeper insight than simple monitoring.

[0018] As a further definition of the inventive technical solution, step S6 includes: S61. Based on time series data, generate a curve of the load rate of each CPU core changing over time, and clearly mark the time point of S4's task migration operation, the box plot comparing the core load distribution before and after optimization, and the Sankey plot of system resource utilization in the graph. S62. Summarize the statistical values ​​of key performance indicators in tabular form, and highlight the load balance improvement value, system throughput change rate, and average task latency change rate calculated in S52 in the table. S63. Based on the bottleneck identification and analysis conclusions of step S53, match and generate optimization suggestions in natural language description from the predefined rule base; S64. Automatically assembles visual charts, statistical tables, and optimization suggestion text into a structured report document, and supports exporting to PDF or HTML format.

[0019] By using a variety of charts such as line graphs, box plots, and Sankey diagrams, complex performance data and multi-dimensional relationships are presented in an intuitive form, making it easy to quickly understand system behavior and analyze performance issues.

[0020] Secondly, the present invention also provides a processor load optimization testing device based on server multi-core computing, the device comprising: The environment initialization module is used to automatically identify the server's hardware configuration information, including the number of CPU cores, cache hierarchy, and CPU topology. The test plan generation module is used to generate a multi-dimensional stress test plan covering the CPU, memory and I / O subsystems based on the hardware configuration information. The test plan includes test tasks simulating compute-intensive, I / O-intensive and mixed loads. The task execution and monitoring module is used to execute the test tasks in the test plan and monitor the load rate, memory bandwidth, cache hit rate and I / O performance indicators of each CPU core in real time. The dynamic optimization scheduling module is used to dynamically adjust the task allocation strategy based on the load rate of each core monitored in real time and a set load difference threshold to achieve dynamic task optimization. If the difference between the maximum core load rate and the minimum core load rate exceeds the threshold, a task migration operation is triggered to migrate the tasks on the core with a load rate greater than the first threshold to the core with a load rate less than the second threshold, so as to achieve load balancing among multiple cores. The data analysis and bottleneck identification module is used to re-collect system performance data after the dynamic optimization scheduling module performs dynamic optimization, compare and analyze the performance indicators before and after optimization, and identify system performance bottlenecks. The report generation module is used to automatically generate performance test reports, which include load distribution charts, performance indicator statistics, and system optimization suggestions based on the analysis conclusions of the data analysis and bottleneck identification module.

[0021] Thirdly, the present invention also provides an electronic device, the electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; the memory storing computer program instructions executable by the at least one processor, the computer program instructions being executed by the at least one processor to enable the at least one processor to perform the processor load optimization test method for server multi-core computing as described in the first aspect.

[0022] Fourthly, the present invention also provides a non-transitory computer-readable storage medium that stores computer instructions that cause the computer to execute the processor load optimization test method for server multi-core computing as described in the first aspect.

[0023] As can be seen from the above technical solutions, this application has the following advantages: It links environment identification, test generation, monitoring, optimization, and report generation into a closed loop, significantly reducing manual intervention, improving testing efficiency and accuracy, and avoiding subjective errors. By covering the CPU, memory, and I / O subsystems with a test plan, it can comprehensively and synchronously evaluate the overall server performance, promptly identify performance constraints between different subsystems, and avoid the limitations of single-dimensional testing. Through a monitoring-judgment-migration mechanism, it can proactively and in real-time correct load imbalances, thereby effectively improving the utilization of multi-core processors and overall task throughput, solving the problem that static task allocation strategies are difficult to adapt to dynamic load changes.

[0024] After optimization, data is re-collected and analyzed, which can quantitatively verify the effectiveness of the optimization measures and accurately locate system bottlenecks, providing reliable data support and clear optimization directions for subsequent system tuning. Attached Figure Description

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

[0026] Figure 1 This is a flowchart illustrating the method provided in an embodiment of the present invention.

[0027] Figure 2 A block diagram of the apparatus provided in an embodiment of the present invention. Detailed Implementation

[0028] To make the purpose, features, and advantages of this application more apparent and understandable, specific embodiments and accompanying drawings will be used to clearly and completely describe the technical solution protected by this application. Obviously, the embodiments described below are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0029] Unless otherwise defined, all technical and scientific terms used in this application have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used in this application and in the specification of this invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0030] like Figure 1As shown, this embodiment of the invention provides a processor load optimization testing method based on server multi-core computing. The method is executed through an automated testing platform, forming a closed-loop process that includes testing, optimization, and verification, and includes the following steps: S1. Automatically identify the server's hardware configuration information, including the number of CPU cores, cache hierarchy, and CPU topology. This step is implemented through the hardware information acquisition module of the automated testing platform. The acquisition module obtains hardware information by calling system interfaces and parsing system files, specifically including the number of CPU cores (physical cores and logical cores), cache hierarchy (L1, L2, L3 cache size and sharing relationship), and CPU topology (NUMA node distribution and inter-core connection relationship). After the acquisition is completed, a structured hardware configuration report is generated as the basis for the subsequent test plan generation.

[0031] S2. Based on the hardware configuration information, generate a multi-dimensional stress test plan covering the CPU, memory, and I / O subsystems. The test plan includes test tasks simulating compute-intensive, I / O-intensive, and mixed loads. Based on the hardware configuration information obtained from S1, a customized test plan is automatically generated, including: CPU testing section: Generate computing tasks of appropriate scale based on the number of cores; Memory testing section: Memory access tests are designed based on memory capacity and NUMA architecture; I / O testing section: Generate I / O test tasks based on storage device type and network configuration; Load types include: Computation-intensive tasks: such as matrix operations and cryptographic computations; I / O intensive: such as file reading and writing, network transmission, etc.; Hybrid: A combination of the two types of tasks mentioned above.

[0032] S3. Execute the test tasks in the test plan and monitor the load rate, memory bandwidth, cache hit rate and I / O performance indicators of each CPU core in real time. According to the test plan, various test tasks are scheduled and executed. The monitoring module collects performance data in real time through various monitoring tools and interfaces: CPU core load rate: collected once per second; Memory bandwidth: includes read bandwidth and write bandwidth; Cache hit rate: The hit rate of each level of cache; I / O performance metrics include disk IOPS, network throughput, etc. All monitoring data is timestamped for easy analysis later.

[0033] S4. Based on the real-time monitored load rate of each core, dynamically adjust the task allocation strategy according to the set load difference threshold to achieve dynamic task optimization. If the difference between the maximum core load rate and the minimum core load rate exceeds the threshold, trigger the task migration operation to migrate the tasks on the core with a load rate greater than the first threshold to the core with a load rate less than the second threshold, so as to achieve load balancing among multiple cores. Continuously analyze monitoring data, calculate core load differences, and preset load difference thresholds (configurable, default is 30%). When a load difference exceeds the threshold, trigger task migration. The first threshold is set to 70% by default (for core components with excessive load); The second threshold is set to 30% by default (for core components with excessively low load). Task migration is achieved through system calls, ensuring that the migration process has minimal impact on testing.

[0034] S5. After performing dynamic optimization in S4, re-collect system performance data, compare and analyze the performance indicators before and after optimization, and identify system performance bottlenecks. By comparing performance data before and after optimization, the analysis indicators include system throughput, response time, resource utilization, etc., and by statistical analysis, performance bottlenecks such as CPU overload, insufficient memory bandwidth, I / O bottlenecks are identified, and a bottleneck analysis report is generated to provide a basis for optimization suggestions.

[0035] S6. Automatically generate a performance test report, which includes a load distribution chart, performance metric statistics, and system optimization suggestions based on the analysis in S5.

[0036] It integrates all test data and analysis results to generate various visualization charts that intuitively display load distribution and performance changes, provide detailed performance metric statistics, generate targeted system optimization suggestions based on S5 analysis results, and support export in both PDF and HTML formats to meet the needs of different scenarios.

[0037] In some embodiments, step S1 includes: S11. By parsing the / proc / cpuinfo file under the Linux system, obtain the identifier, physical core ID and physical package ID of each logical core, and calculate the total number of physical CPU cores and the total number of logical CPU cores. Open and parse the / proc / cpuinfo file in the Linux system; Extract the processor field (logical core identifier) ​​for each processor. Extract the physical id field (physical core ID); Extract the CPU cores field (the number of logical cores per physical core). Extract the siblings field (the total number of logical cores in each physical package). The total number of physical CPU cores is determined by counting the number of different physical IDs; The total number of logical CPU cores can be determined by counting the number of processor fields.

[0038] S12. By parsing the files in the directory / sys / devices / system / cpu / cpuX / cache / indexY / , where X is the CPU number and Y is the cache level index, the size, type, and shared topology of each cache level are obtained. Traverse the directory / sys / devices / system / cpu / cpuX / cache / indexY / , where X is the CPU number and Y is the cache level (0 is usually L1, 1 is L2, 2 is L3, etc.). Read the size file in each cache directory to get the cache size; Read the type file to obtain the cache type (such as Data, Instruction, or Unified). Read the shared_cpu_list file to obtain the list of CPU cores sharing this cache; Record the associativity and coherency_line_size of each cache.

[0039] S13. Obtain the number of nodes in the non-uniform memory access architecture, the list of CPU cores in each node, and the node memory distribution information by parsing the / sys / devices / system / node / directory or by using the numactl --hardware command. Parse the node information under the / sys / devices / system / node / directory; Each nodeX directory represents a NUMA node; Read the nodeX / cpu_list file to obtain the list of CPU cores contained in the node; Read the nodeX / meminfo file to obtain the node's memory information (total memory, free memory, etc.). The obtained information can be verified by calling the numactl --hardware command.

[0040] S14. Integrate the information obtained from S11-S13 to construct a complete hardware topology diagram that reflects the relationships between physical packaging, cores, threads, cache sharing, and NUMA node affiliation.

[0041] Integrate all information obtained from S11-S13 and establish data relationships; Establish the hierarchical relationship between physical encapsulation, physical core, and logical core; Record the cache sharing relationships between the cores; Clearly define the NUMA node and memory distribution for each core; Use a graphical library (such as Graphviz) to generate a visual topology diagram; Stored as structured data (such as JSON format) for use in generating subsequent test plans.

[0042] Topology example: { "physical_packages": [ { "id": 0, "physical_cores": [ { "id": 0, "logical_cores": [0, 1], "l2_cache": {"size": "256KB", "shared_with": [0, 1]}, "numa_node": 0 } ], "l3_cache": {"size": "16MB", "shared_with": [0, 1, 2, 3]} } ] } In some embodiments, step S2 includes: S21. Generate a CPU stress test plan, including: Single-core peak performance test: Generate computationally intensive tasks, such as high-precision floating-point operations or complex encryption algorithms; Use the taskset command to bind a task to a specific CPU core: taskset -c0. / cpu_benchmark --mode single; The test duration is set to 60 seconds by default, but it is configurable. The number of operations per second is recorded as a performance metric.

[0043] Cache shared domain collaborative computing test: Based on the cache sharing relationship obtained from S14, identify the core groups that share the same L3 cache; Generate a set of tightly coupled computational tasks (such as parallel matrix multiplication) for each core group. Use tasksets to bind tasks to different cores within the group; The test task was designed to require frequent data exchange in order to evaluate cache sharing efficiency; Compare the differences in collaborative computing performance within the same group and between different groups.

[0044] Overall system parallel computing throughput test: Generate parallel computing tasks equal to the total number of logical CPU cores; Each task performs an independent computational task (such as Monte Carlo simulation); Use a thread pool or process pool to manage all tasks; Monitor and record the duration for all cores to reach 80%-90% load. Overall computing throughput of the computing system (e.g., total number of operations per second).

[0045] S22. Generate a memory bandwidth test plan, including: Memory sequential access bandwidth test: Generate test tasks that perform large-scale contiguous memory block reads and writes; Allocate a contiguous memory block with a size of 1 / 4 of the system memory (to avoid the impact of caching); Perform sequential read and write operations and record the transmission rate; Test using different data block sizes (e.g., 4KB, 64KB, 1MB); The example implementation can be based on the STREAM benchmark suite.

[0046] Memory random access test: Generate memory read / write tasks with random address access patterns; Use a pseudo-random number generator to generate memory access addresses; Measure average access latency and random access bandwidth; Test different working set sizes (from less than L3 cache to more than physical memory); Record the relationship between cache miss rate and working set size.

[0047] Cross-NUMA node memory concurrent access test: Based on the NUMA node information obtained from S13, assign test tasks to each node; The design task accesses local node memory and remote node memory; Test memory performance under different concurrency levels; Record the latency and bandwidth differences between local and remote access; Evaluate the impact of NUMA architecture on memory performance.

[0048] S23. Generate an I / O stress test plan, including: Disk performance test: Large file sequential read / write test: Use the dd command or a custom program to generate a test file of several GB; dd if= / dev / zero of=testfile bs=1G count=4 oflag=direct Small file random read / write test: Create thousands of small files (e.g., 4KB) and perform random read / write operations; Use the fio tool to perform more complex I / O pattern tests: fio--name=randwrite--rw=randwrite--direct=1--size=1G--bs=4k Record disk throughput (MB / s) and IOPS (I / O operations per second).

[0049] Network performance testing: Perform network tests between the test server and the auxiliary server; Use the iperf3 tool to test network bandwidth: Use ping and traceroute to test network latency and routing; Test performance at different packet sizes (64B, 1KB, 10KB); Test network performance in single-connection and multi-connection scenarios.

[0050] S24. Based on the test objectives, combine the different types of test tasks generated in S21 to S23 and execute them concurrently to simulate real mixed load scenarios.

[0051] Select the appropriate task combination based on the preset test objectives (such as simulating a database server, web server, etc.); Database server simulation: 70% CPU computing tasks + 20% memory access + 10% disk I / O; Web server simulation: 30% CPU computation + 20% memory access + 50% network I / O; Use a task scheduler to control the concurrent execution of different types of tasks; Dynamically adjust the proportion of various tasks and observe the system's performance under different load combinations; Record the changes in system response time and throughput under mixed loads.

[0052] In some embodiments, step S3 includes: S31. Call the operating system interface or use containerization technology to create an independent execution environment for each test task generated in S21-S23 to ensure that the test tasks do not interfere with each other; execute the various tasks in S24 concurrently. Regarding the implementation methods of containerization technology: Use Docker to create a separate container for each test task; Allocate isolated resources (CPU, memory, I / O quota) to each container. Define the dependencies of a multi-container testing environment using Docker Compose.

[0053] Regarding the implementation method of the operating system interface: Use cgroups technology to limit the resource usage of each task; Process isolation is achieved through namespaces; Use chroot to create a separate file system view for each task.

[0054] Example cgroups configuration: bash mkdir / sys / fs / cgroup / cpu / test1 echo100000> / sys / fs / cgroup / cpu / test1 / cpu.cfs_quota_us echo <pid>> / sys / fs / cgroup / cpu / test1 / tasks Concurrent execution of tasks: Use a task scheduler (such as Python's concurrent.futures) to manage task execution; The number of concurrent tasks is dynamically adjusted based on the number of system cores and the test plan; Implement task execution status monitoring and handle abnormal task termination; Record the start time, end time, and execution status of each task.

[0055] S32. During the execution of the test task, the following performance metrics are collected in parallel using a periodic sampling method: CPU core utilization data collection: Periodically read the / proc / stat file to obtain time statistics for each CPU core; The sampling period is 1 second by default, but it is configurable. Alternatively, you can use the cpu_percent(percpu=True) method from the psutil library.

[0056] Memory bandwidth acquisition: Read the / proc / meminfo file and calculate the changes in MemFree, Buffers, and Cached over a specific time interval; Use the perf tool to monitor memory events: perfstat -emem_load_retired.l3_hit,mem_load_retired.l3_miss -p <pid> For NUMA node-level monitoring, use the numastat tool; Record memory read / write bandwidth (MB / s) and page fault rate.

[0057] Cache hit rate calculation: Use the perf tool to collect cached events: bash perf stat-eL1-dcache-loads,L1-dcache-load-misses-p <pid> perf stat-eLLC-loads,LLC-load-misses-p <pid> Calculation method:

[0058] Record the hit rates of L1, L2, and L3 caches respectively.

[0059] I / O performance metrics collection: Disk performance: Parse the / proc / diskstats file to calculate the number of sectors read and written per second and the number of I / O operations;

[0060] IOPS = Number of read / write operations / Sampling interval Network performance: Parse the / proc / net / dev file to calculate the number of bytes sent and received and the number of data packets on the network interface;

[0061] Network packet rate = number of packets / sampling interval Alternatively, tools such as iostat and iftop can be used to assist in data collection.

[0062] S33. Add a unified timestamp to all performance metrics data collected in each sampling period, and associate the monitoring data with the type and intensity of the currently executing test task to form a structured performance log with time context.

[0063] Timestamp generation: Use a high-precision clock (such as Python's time.time_ns()) to generate a timestamp for each record.

[0064] Data association method: Assign a unique identifier to each test task; Associate monitoring data with task identifiers; Record the type, intensity, and resource allocation of the current task; Log storage: A round-robin log method is used to avoid individual files becoming too large; It supports real-time writing to databases (such as InfluxDB and Prometheus), facilitating real-time monitoring and subsequent analysis.

[0065] In some embodiments, step S4 dynamically adjusts the task allocation strategy based on a set load difference threshold, specifically including the following steps: S41. In each monitoring sampling period, calculate the absolute difference between the maximum core load rate and the minimum core load rate among all logical cores; when the absolute difference continues to exceed the preset load difference threshold for N consecutive sampling periods, the system is determined to be in a state of unbalanced load and a task migration operation is triggered; wherein, the load difference threshold ranges from 10% to 30%, and the number of consecutive periods (N) ranges from 2 to 5. Load rate calculation: Based on the CPU utilization data collected by S32, calculate the load rate of each logical core; Load difference calculation: In each monitoring sampling period (default 1 second), calculate the absolute difference between the maximum load rate and the minimum load rate of all logical cores; Load difference threshold: The default setting is 30%, which can be adjusted via the configuration file; Continuous sampling period determination: The default value of N is 3, which means that when the load difference is detected to exceed the threshold for 3 consecutive sampling periods, the system is determined to be in an unbalanced load state. Triggering mechanism: Once a load imbalance is detected, a task migration operation is immediately triggered; Example: If in an 8-core system, the core load rates are 90%, 85%, 80%, 10%, 15%, 20%, 25%, and 30%, respectively, the maximum difference is 80%, which exceeds the 30% threshold.

[0066] S42. Cores with a load rate higher than the first threshold are identified as source cores for tasks to be migrated out; the first threshold is the sum of the system average load rate and the preset offset; From cores with a load rate lower than the second threshold, target cores are selected based on proximity, with the following priority order: The core shares the last-level cache with the source core; The core that resides within the same NUMA node as the source core; The remaining cores on the other NUMA nodes; The second threshold is equal to the overall average load rate of the system during the current sampling period; Source core identified: Calculate the current system average load rate: the arithmetic mean of the load rates of all cores; First threshold = System average load rate + Preset offset The default offset is 20%.

[0067] Cores with a load rate higher than the first threshold are marked as source cores for tasks to be migrated out; Example: The system average load rate is 50%, the first threshold is 70%, and all cores with a load rate > 70% will be used as source cores.

[0068] Core Target Selection: Second threshold = Current system average load rate; Select the target core from the cores whose load rate is less than the second threshold; Sort by proximity (to reduce cache invalidation and NUMA access overhead): The core shares the last-level cache with the source core; The core that resides within the same NUMA node as the source core; Cores on other NUMA nodes; If there are multiple target cores that meet the criteria, the core with the lowest load rate should be selected first.

[0069] Core selection example: The source core is CPU0 (load rate 85%), the core sharing its L3 cache is CPU1, the cores on the same NUMA node are CPU0-3, and the system average load rate is 50%. The cores with a load rate of <50% are CPU4 (40%), CPU5 (35%), and CPU6 (20%). Target core priority: First check if there are cores with shared L3 cache and load rate <50%. If not, check the same NUMA nodes, and finally select other nodes.

[0070] S43. For the selected source core and target core, migrate one or more specified test tasks currently running on the source core in user space from the source core to the target core. Task selection: Analyze all test tasks running on the source core and prioritize portable user-space tasks. Select the tasks to migrate based on task priority, execution progress, and resource requirements; Typically, one or two tasks are selected for migration to avoid excessive migration affecting system stability. Migration implementation method: Use the taskset command: taskset -cp <target kernel ID><process ID>; Alternatively, cgroups technology can be used to move the process ID from the source core's cgroup to the target core's cgroup. For thread-level migration, use the pthread_setaffinity_np function; Migration process monitoring: Record the start and end times of the task migration; Monitor changes in task response time during the migration process; Ensure that the task migration does not lead to data loss or consistency issues; S44. Within M sampling periods after the task migration operation is completed, continuously monitor the absolute difference; if the absolute difference drops below the load difference threshold, the optimization is deemed effective; otherwise, record the optimization failure and re-execute steps S41 to S43 in the next period.

[0071] In some embodiments, step S5 includes: S51. One sampling period before the task migration operation is triggered in S41, record a baseline snapshot of the system performance indicators; after the task migration is completed and the system is running stably, record an optimized snapshot of the system performance indicators for K consecutive sampling periods; the performance indicators include at least the load rate of each CPU core, the overall system throughput, and the average task latency. Baseline snapshot acquisition: Data is collected within a complete sampling period prior to the S41 triggering the task migration operation; Ensure the data includes a complete task execution cycle; The data collected includes the load rate of each CPU core, the overall system throughput, and the average latency of each task. The average value of each indicator within this period is used as the baseline value.

[0072] Optimized snapshot collection: After the task migration is complete, wait for the system to stabilize (default 2 sampling periods); Continuously collect performance data for K sampling periods (K defaults to 5); Calculate the average value over these K periods as the optimized value; Ensure the system load remains stable and free from other interference factors during the data collection process.

[0073] Key performance indicator definition: CPU core load percentage: the percentage of each core's utilization; Overall system throughput: the number of tasks completed or the amount of data processed per unit of time; Average task latency: The average time from task submission to completion; Cache hit rate: The percentage of cache hits at each level; Memory access latency: The average latency of memory read and write operations; I / O performance: Disk and network throughput and latency.

[0074] S52. Compare the mean of the baseline snapshot and the optimized snapshot, and calculate the change in key performance indicators, including: Calculate the standard deviation of the load rate between cores before and after optimization. A decrease in the standard deviation indicates an improvement in load balance. Calculate the rate of change of system throughput: ; Calculate the average task latency change rate: ; Analysis example: Before optimization, the load standard deviation was 25; after optimization, it was 10, resulting in a 60% improvement in load balance. Before optimization, the throughput was 100 tasks / second; after optimization, it was 120 tasks / second, an improvement of 20%. The average latency was 50ms before optimization and 40ms after optimization, a reduction of 20%.

[0075] S53. Based on the calculation results of step S52, and combined with the resource indicators monitored in S3, bottlenecks are located: If the load balancing improves and the positive throughput change rate of the system is greater than the third threshold, then the task dynamic optimization of S4 is deemed effective for the current test scenario, and the previous bottleneck was mainly the unbalanced task scheduling. If the load is balanced but the system throughput change rate is within the fourth threshold range, and the cache hit rate is less than the fifth threshold, then the system is determined to have a cache locality problem, and task migration has caused too many cache invalidations. If the load is balanced but the rate of change of the system's positive throughput is less than the sixth threshold, and there is an increase in memory latency of NUMA nodes, then it is determined that task migration has introduced performance loss of cross-NUMA node memory access. If the system CPU load is balanced and the utilization rate is higher than the set value, but the overall throughput is still lower than the preset value, then based on the I / O monitoring data, it is determined that the system bottleneck is disk I / O or network bandwidth.

[0076] Task scheduling imbalance determination: The third threshold is set to 5% by default. When the load balancing is improved and the positive throughput change rate of the system is >5%, the previous bottleneck was mainly the unbalanced task scheduling, and optimization is effective. Determining the locality of cache problem: The fourth threshold range is ±3%, and the fifth threshold defaults to 70%. When the load is balanced but the system throughput change rate is within ±3%, and the cache hit rate is <70%, there is a cache locality problem, and task migration causes too many caches to fail. Typical manifestation: L3 cache hit rate drops significantly (>10%).

[0077] Determining the overhead of cross-NUMA node access: The sixth threshold is 3% by default. When the load is balanced but the positive throughput change rate of the system is <3%, and the memory latency of NUMA nodes increases, task migration introduces performance loss of cross-NUMA node memory access, the proportion of remote memory access increases, and memory latency increases by >20%.

[0078] I / O bottleneck identification: When the CPU load is balanced and the utilization rate is >70% (configurable), but the overall throughput is still lower than the preset value, combined with I / O monitoring data, if the disk IOPS is close to the maximum value or the network bandwidth reaches the limit, it is determined that the system bottleneck is disk I / O or network bandwidth.

[0079] Bottleneck analysis report example: Bottleneck analysis results: 1. Load balancing improved: 60% 2. System throughput change: +15% (>5%) 3. Cache hit rate change: -2% (still >70%) 4. NUMA memory latency change: +5% Conclusion: This optimization is effective, solves the problem of unbalanced task scheduling, and does not introduce significant side effects.

[0080] In some embodiments, step S6 includes: S61. Based on time series data, generate a curve of the load rate of each CPU core changing over time, and clearly mark the time point of S4's task migration operation, the box plot comparing the core load distribution before and after optimization, and the Sankey plot of system resource utilization in the graph. CPU core load rate over time curve: Use Matplotlib or Plotly to plot line graphs, with the x-axis representing time and the y-axis representing load rate (%). Each core has its own curve, distinguished by different colors. Use vertical dashed lines to clearly mark the time points of task migration operations in the graph.

[0081] Box plot comparing core load distribution before and after optimization: The left side shows the load distribution of all cores before optimization, and the right side shows the load distribution after optimization. The box displays the interquartile range, the center line represents the median, and the whisker lines represent the data range, intuitively showing the concentration and balance of the load distribution.

[0082] Sankey diagram of system resource utilization: To display the utilization rates of resources such as CPU, memory, disk I / O, and network, and to compare them before and after optimization, showing the changes in resource utilization efficiency, Plotly's Sankey chart can be used.

[0083] S62. Summarize the statistical values ​​of key performance indicators in tabular form, and highlight the load balance improvement value, system throughput change rate, and average task latency change rate calculated in S52 in the table. The table content includes: The values ​​before optimization, the values ​​after optimization, the amount of change, and the rate of change for each performance indicator; Key metrics: average CPU utilization, load standard deviation, system throughput, average latency, etc. Cache and memory related metrics: cache hit rate at each level, memory bandwidth, etc.; I / O related metrics: disk IOPS, network throughput, etc.

[0084] Data highlighted: Use green to highlight positive changes (such as increased throughput); Use red to highlight negative changes (such as increased delay); The load balancing improvement, system throughput change rate, and average task latency change rate are highlighted.

[0085] S63. Based on the bottleneck identification and analysis conclusions of step S53, match and generate optimization suggestions in natural language description from the predefined rule base; The rule base contains at least the following mapping relationships: If the bottleneck is determined to be mainly due to uneven task scheduling, the following recommendation is generated: It is recommended to enable or optimize a NUMA- and cache-aware load balancing strategy at the operating system level.

[0086] If a cache locality problem is identified, the following suggestion is generated: The current task migration strategy may cause cache invalidation. It is recommended to adjust the load balancing threshold or optimize the task granularity to improve cache affinity.

[0087] If cross-NUMA node access overhead is detected, the following suggestion is generated: Cross-NUMA node memory access may become a bottleneck. It is recommended to try binding the task group to run within the same NUMA node.

[0088] If the bottleneck is determined to be disk I / O or network bandwidth, the following suggestion is generated: The system bottleneck may be located in the I / O subsystem. It is recommended to check the performance of storage devices or network configuration.

[0089] S64. Automatically assembles visual charts, statistical tables, and optimization suggestion text into a structured report document, and supports exporting to PDF or HTML format.

[0090] like Figure 2 As shown, this embodiment of the invention also provides a processor load optimization testing device based on server multi-core computing, the device comprising: The environment initialization module is used to automatically identify the server's hardware configuration information, including the number of CPU cores, cache hierarchy, and CPU topology. The test plan generation module is used to generate a multi-dimensional stress test plan covering the CPU, memory and I / O subsystems based on the hardware configuration information. The test plan includes test tasks simulating compute-intensive, I / O-intensive and mixed loads. The task execution and monitoring module is used to execute the test tasks in the test plan and monitor the load rate, memory bandwidth, cache hit rate and I / O performance indicators of each CPU core in real time. The dynamic optimization scheduling module is used to dynamically adjust the task allocation strategy based on the load rate of each core monitored in real time and a set load difference threshold to achieve dynamic task optimization. If the difference between the maximum core load rate and the minimum core load rate exceeds the threshold, a task migration operation is triggered to migrate the tasks on the core with a load rate greater than the first threshold to the core with a load rate less than the second threshold, so as to achieve load balancing among multiple cores. The data analysis and bottleneck identification module is used to re-collect system performance data after the dynamic optimization scheduling module performs dynamic optimization, compare and analyze the performance indicators before and after optimization, and identify system performance bottlenecks. The report generation module is used to automatically generate performance test reports, which include load distribution charts, performance indicator statistics, and system optimization suggestions based on the analysis conclusions of the data analysis and bottleneck identification module.

[0091] In some embodiments, the environment initialization module specifically includes: The CPU information parsing unit is used to obtain the identifier, physical core ID, and physical package ID of each logical core by parsing the / proc / cpuinfo file under the Linux system, and to calculate the total number of physical CPU cores and the total number of logical CPU cores. The cache information extraction unit is used to obtain the size, type, and shared topology of each cache level by parsing the files in the directory / sys / devices / system / cpu / cpuX / cache / indexY / , where X is the CPU number and Y is the cache level index. The NUMA topology identification unit is used to obtain the number of non-uniform memory access architecture nodes, the list of CPU cores contained in each node, and the node memory distribution information by parsing the / sys / devices / system / node / directory information or using the numactl --hardware command; The topology construction unit is used to integrate the information obtained by the CPU information parsing unit, cache information extraction unit and NUMA topology identification unit to construct a complete hardware topology diagram that reflects the physical packaging, the relationship between cores and threads, the cache sharing relationship and the NUMA node affiliation relationship.

[0092] In some embodiments, the dynamic optimization scheduling module specifically includes: The load determination unit is used to calculate the absolute difference between the maximum and minimum load rates of all logical cores in each monitoring sampling period. When the absolute difference exceeds the preset load difference threshold for N consecutive sampling periods, the system is determined to be in an unbalanced load state, and a task migration operation is triggered. The core selection unit is used to identify cores with a load rate higher than a first threshold as the source cores of the task to be migrated out, where the first threshold is the sum of the system average load rate and a preset offset; and to select target cores from cores with a load rate lower than a second threshold according to the proximity principle, where the second threshold is the overall average load rate of the system in the current sampling period; the priority order of the proximity principle is: cores that share the last level cache with the source core, cores that are in the same NUMA node as the source core, and cores on other NUMA nodes; The task migration execution unit is used to migrate one or more specified test tasks running on the source core and in user space to the target core, for the selected source core and target core. The optimization verification unit is used to continuously monitor the absolute difference within M sampling periods after the task migration operation is completed; if the absolute difference drops below the load difference threshold, the optimization is determined to be effective; otherwise, the optimization is recorded as ineffective.

[0093] The device runs on an ARM64 architecture server.

[0094] In some embodiments, the device is integrated into an automated testing platform, which also includes a user interface for configuring test parameters and displaying generated test reports.

[0095] This invention also provides an electronic device, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, communication interface, and memory communicate with each other via the communication bus. The communication bus can be used for information transmission between the electronic device and sensors. The processor can call logical instructions in the memory to execute the following methods: S1, automatically identify the server's hardware configuration information, including the number of CPU cores, cache hierarchy, and CPU topology; S2, based on the hardware configuration information, generate a multi-dimensional stress test plan covering the CPU, memory, and I / O subsystems, the test plan including test tasks simulating compute-intensive, I / O-intensive, and mixed loads; S3, execute the test tasks in the test plan and monitor the load rate, memory bandwidth, cache hit rate, and I / O performance indicators of each CPU core in real time; S4, based on the real-time monitored load rate of each CPU core, ... Dynamic task allocation strategy is dynamically adjusted based on the set load difference threshold to achieve dynamic task optimization. If the difference between the maximum core load rate and the minimum core load rate exceeds the threshold, a task migration operation is triggered to migrate tasks on cores with load rates greater than the first threshold to cores with load rates less than the second threshold, so as to achieve load balancing among multiple cores; S5. After performing dynamic optimization in S4, system performance data is re-collected, and the performance indicators before and after optimization are compared and analyzed to identify system performance bottlenecks; S6. A performance test report is automatically generated, which includes a load allocation chart, performance indicator statistics, and system optimization suggestions based on the analysis in S5.

[0096] Furthermore, the logical instructions in the aforementioned memory can be implemented as software functional units and sold or used as independent products, and can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0097] This invention provides a non-transitory computer-readable storage medium storing computer instructions that cause a computer to execute the method provided in the above-described method embodiments. For example, the instructions include: S1, automatically identifying server hardware configuration information, including the number of CPU cores, cache hierarchy, and CPU topology; S2, based on the hardware configuration information, generating a multi-dimensional stress test plan covering the CPU, memory, and I / O subsystems, the test plan including test tasks simulating compute-intensive, I / O-intensive, and mixed loads; S3, executing the test tasks in the test plan and monitoring the load rate, memory bandwidth, cache hit rate, and I / O performance of each CPU core in real time. S4. Based on the real-time monitored CPU core load rate, dynamically adjust the task allocation strategy according to the set load difference threshold to achieve dynamic task optimization. If the difference between the maximum core load rate and the minimum core load rate exceeds the threshold, trigger the task migration operation to migrate tasks on cores with load rates greater than the first threshold to cores with load rates less than the second threshold, so as to achieve load balancing among multiple cores; S5. After performing dynamic optimization in S4, re-collect system performance data, compare and analyze the performance indicators before and after optimization, and identify system performance bottlenecks; S6. Automatically generate a performance test report, which includes a load allocation chart, performance indicator statistics, and system optimization suggestions based on the analysis in S5.

[0098] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.< / pid> < / pid> < / pid> < / pid>

Claims

1. A method for optimizing processor load in multi-core server computing, characterized in that, The method is executed through an automated testing platform, forming a closed-loop process that includes testing, optimization, and verification, and includes the following steps: S1. Automatically identify the server's hardware configuration information, including the number of CPU cores, cache hierarchy, and CPU topology. S2. Based on the hardware configuration information, generate a multi-dimensional stress test plan covering the CPU, memory, and I / O subsystems. The test plan includes test tasks simulating compute-intensive, I / O-intensive, and mixed loads. S3. Execute the test tasks in the test plan and monitor the load rate, memory bandwidth, cache hit rate and I / O performance indicators of each CPU core in real time. S4. Based on the real-time monitoring of the load rate of each CPU core, dynamically adjust the task allocation strategy according to the set load difference threshold to achieve dynamic task optimization. If the difference between the maximum core load rate and the minimum core load rate exceeds the threshold, trigger the task migration operation to migrate the tasks on the core with a load rate greater than the first threshold to the core with a load rate less than the second threshold, so as to achieve load balancing among multiple cores. S5. After performing dynamic optimization in S4, re-collect system performance data, compare and analyze the performance indicators before and after optimization, and identify system performance bottlenecks. S6. Automatically generate a performance test report, which includes a load distribution chart, performance metric statistics, and system optimization suggestions based on the analysis in S5.

2. The processor load optimization test method for server multi-core computing according to claim 1, characterized in that, The steps in S1 include: S11. By parsing the / proc / cpuinfo file under the Linux system, obtain the identifier, physical core ID and physical package ID of each logical core, and calculate the total number of physical CPU cores and the total number of logical CPU cores. S12. By parsing the files in the directory / sys / devices / system / cpu / cpuX / cache / indexY / , where X is the CPU number and Y is the cache level index, the size, type, and shared topology of each cache level are obtained. S13. Obtain the number of nodes in the non-uniform memory access architecture, the list of CPU cores in each node, and the node memory distribution information by parsing the / sys / devices / system / node / directory or by using the numactl --hardware command. S14. Integrate the information obtained from S11-S13 to construct a complete hardware topology diagram that reflects the relationships between physical packaging, cores, threads, cache sharing, and NUMA node affiliation.

3. The processor load optimization test method for server multi-core computing according to claim 2, characterized in that, The steps in S2 include: S21. Generate a CPU stress test plan; including: Generate a computationally intensive task and bind it to a specified CPU core to run, for testing single-core peak performance; Generate a set of computationally intensive tasks and bind them to a set of cores that share the same level of cache, as determined by the topology, to run on, in order to test the efficiency of collaborative computing within the cache-shared domain; Generate parallel computing tasks equal to the total number of logical CPU cores, bringing all cores to a preset high-load state, in order to test the overall parallel computing throughput of the system. S22. Generate a memory bandwidth test plan; including: Generate tasks that perform large-scale sequential memory read and write operations to test the bandwidth of sequential memory access; Generate tasks that perform large-scale random memory read and write operations to test memory random access latency and bandwidth; Multiple concurrent memory access tasks are generated and distributed to different nodes according to the NUMA node topology to run, in order to test the performance of concurrent memory access across NUMA nodes; S23. Generate an I / O stress test plan; including: Generate tasks that perform sequential read / write of large files and random read / write of small files to test disk read / write throughput and IOPS; Generate network packet sending and receiving tasks to test network bandwidth and communication latency; S24. Based on the test objectives, combine the different types of test tasks generated in S21 to S23 and execute them concurrently to simulate real mixed load scenarios.

4. The processor load optimization test method for server multi-core computing according to claim 3, characterized in that, The steps in S3 include: S31. Call the operating system interface or use containerization technology to create an independent execution environment for each test task generated in S21-S23 to ensure that the test tasks do not interfere with each other; execute the various tasks in S24 concurrently. S32. During the execution of the test task, the following performance metrics are collected in parallel using a periodic sampling method: Calculate the time utilization of each logical core within the sampling period by reading the / proc / stat file or using the psutil library; The system-level and NUMA node-level memory read / write bandwidth can be obtained by reading the / proc / meminfo file and calculating the changes in active memory pages within a specific interval, or by using the perf performance counter tool. By reading the hardware event counters provided by the perf performance counter tool, the number of accesses and misses of each level of cache can be obtained, and the cache hit rate can be calculated. By reading the / proc / diskstats and / proc / net / dev files, the read / write throughput, IOPS, and receive / transmit throughput of the network interface are calculated for the disk device. S33. Add a unified timestamp to all performance metrics data collected in each sampling period, and associate the monitoring data with the type and intensity of the currently executing test task to form a structured performance log with time context.

5. The processor load optimization test method for server multi-core computing according to claim 3, characterized in that, S4 dynamically adjusts the task allocation strategy based on a set load difference threshold, specifically including the following steps: S41. In each monitoring sampling period, calculate the absolute difference between the maximum core load rate and the minimum core load rate among all logical cores; when the absolute difference continues to exceed the preset load difference threshold for N consecutive sampling periods, the system is determined to be in a state of unbalanced load and a task migration operation is triggered. S42. Cores with a load rate higher than the first threshold are identified as source cores for tasks to be migrated out; the first threshold is the sum of the system average load rate and the preset offset; From cores with a load rate lower than the second threshold, target cores are selected based on proximity, with the following priority order: The core shares the last-level cache with the source core; The core that resides within the same NUMA node as the source core; The remaining cores on the other NUMA nodes; The second threshold is equal to the overall average load rate of the system during the current sampling period; S43. For the selected source core and target core, migrate one or more specified test tasks currently running on the source core in user space from the source core to the target core. S44. Within M sampling periods after the task migration operation is completed, continuously monitor the absolute difference; if the absolute difference drops below the load difference threshold, the optimization is deemed effective; otherwise, record the optimization failure and re-execute steps S41 to S43 in the next period.

6. The processor load optimization test method for server multi-core computing according to claim 5, characterized in that, The steps in S5 include: S51. One sampling period before the task migration operation is triggered in S41, record a baseline snapshot of the system performance indicators; after the task migration is completed and the system is running stably, record an optimized snapshot of the system performance indicators for K consecutive sampling periods; the performance indicators include at least the load rate of each CPU core, the overall system throughput, and the average task latency. S52. Compare the mean of the baseline snapshot and the optimized snapshot, and calculate the change in key performance indicators, including: Calculate the standard deviation of the load rate between cores before and after optimization. A decrease in the standard deviation indicates an improvement in load balance. Calculate the rate of change of system throughput; Calculate the average task delay rate of change; S53. Based on the calculation results of step S52, and combined with the resource indicators monitored in S3, bottlenecks are located: If the load balancing improves and the positive throughput change rate of the system is greater than the third threshold, then the task dynamic optimization of S4 is deemed effective for the current test scenario, and the previous bottleneck was mainly the unbalanced task scheduling. If the load is balanced but the system throughput change rate is within the fourth threshold range, and the cache hit rate is less than the fifth threshold, then the system is determined to have a cache locality problem, and task migration has caused too many cache invalidations. If the load is balanced but the rate of change of the system's positive throughput is less than the sixth threshold, and there is an increase in memory latency of NUMA nodes, then it is determined that task migration has introduced performance loss of cross-NUMA node memory access. If the system CPU load is balanced and the utilization rate is higher than the set value, but the overall throughput is still lower than the preset value, then based on the I / O monitoring data, it is determined that the system bottleneck is disk I / O or network bandwidth.

7. The processor load optimization test method for server multi-core computing according to claim 6, characterized in that, The steps in S6 include: S61. Based on time series data, generate a curve of the load rate of each CPU core changing over time, and clearly mark the time point of S4's task migration operation, the box plot comparing the core load distribution before and after optimization, and the Sankey plot of system resource utilization in the graph. S62. Summarize the statistical values ​​of key performance indicators in tabular form, and highlight the load balance improvement value, system throughput change rate, and average task latency change rate calculated in S52 in the table. S63. Based on the bottleneck identification and analysis conclusions of step S53, match and generate optimization suggestions in natural language description from the predefined rule base; S64. Automatically assembles visual charts, statistical tables, and optimization suggestion text into a structured report document, and supports exporting to PDF or HTML format.

8. A processor load optimization testing device for multi-core server computing, characterized in that, The device includes: The environment initialization module is used to automatically identify the server's hardware configuration information, including the number of CPU cores, cache hierarchy, and CPU topology. The test plan generation module is used to generate a multi-dimensional stress test plan covering the CPU, memory and I / O subsystems based on the hardware configuration information. The test plan includes test tasks simulating compute-intensive, I / O-intensive and mixed loads. The task execution and monitoring module is used to execute the test tasks in the test plan and monitor the load rate, memory bandwidth, cache hit rate and I / O performance indicators of each CPU core in real time. The dynamic optimization scheduling module is used to dynamically adjust the task allocation strategy based on the load rate of each core monitored in real time and a set load difference threshold to achieve dynamic task optimization. If the difference between the maximum core load rate and the minimum core load rate exceeds the threshold, a task migration operation is triggered to migrate the tasks on the core with a load rate greater than the first threshold to the core with a load rate less than the second threshold, so as to achieve load balancing among multiple cores. The data analysis and bottleneck identification module is used to re-collect system performance data after the dynamic optimization scheduling module performs dynamic optimization, compare and analyze the performance indicators before and after optimization, and identify system performance bottlenecks. The report generation module is used to automatically generate performance test reports, which include load distribution charts, performance indicator statistics, and system optimization suggestions based on the analysis conclusions of the data analysis and bottleneck identification module.

9. An electronic device, characterized in that, The electronic device includes: at least one processor; and a memory communicatively connected to the at least one processor; the memory stores computer program instructions executable by the at least one processor, the computer program instructions being executed by the at least one processor to enable the at least one processor to perform the processor load optimization test method for server multi-core computing as described in any one of claims 1 to 7.

10. A non-transitory computer-readable storage medium, characterized in that, The non-transitory computer-readable storage medium stores computer instructions that cause the computer to perform the processor load optimization test method for server multi-core computing as described in any one of claims 1 to 7.

Images